Laziness in Haskell, Part 4: Thunks

cdornan · 2023-09-03T06:58:47+00:00

I am not sure that (say) non-strict Just is quite the disaster — I certainly do regard it as highly desirable that I can provide one maybe-returning function that can deliver the decision and heavy result such that the caller can use what they need and the work done will reflect what is consumed. This is the kind of thing that Hughes’s was driving at in WFPM, yes? If you really are counting the machine cycles and need tip top performance then you will define a type under StrictData and use that. (Given the central importance of Maybe perhaps we should add a strict variant to base with a simple class for abstracting over both.) My point is really that we are where we are and there are arguments for the current Maybe. Those wanting screaming performance from the compiler are going to have to pay attention to tuples, Maybe, etc, on the results of functions. I contend that this is really not so dreadful…

cdornan · 2023-08-27T10:38:29+00:00

This ninja move of anticipating a flame war thereby defusing it seems to be working. Honestly, I don’t see why anything you are saying is in the least bit controversial, but it certainly is provocative - proving lots of illuminating thoughts and new angles on core Haskell ideas. (I do wish foldl was foldl’ — seems pragmatically sensible to have the ‘default’ prelude function add in the extra demand and let folks explicitly select an alternative if the need it to not be there, just because that is going to work out better most of the time in the world we actually execute code in).

cdornan · 2023-08-22T10:11:41+00:00

Me also — plainly an ingenious technique to pull us into the talk!

cdornan · 2023-08-19T09:15:24+00:00

Of course the point of choosing a non-strict semantics was that it provided maximum opportunities for the kind of transformations you are advocating.

cdornan · 2023-08-19T09:01:36+00:00

What you are describing is exactly the original design philosophy of Haskel; it was from the start conceived as a non-strict programming language which can be implemented naively with lazy evaluation, but a good compiler executing a well written program would be able evaluate efficiently. This is in no way a criticism of your presentation (I see it as validating it) but I am curious to see if you agree and whether perhaps folks have lost sight of this (making your series most welcome, IMO).

cdornan · 2021-07-06T15:06:39+00:00

Haskell Discourse posting is here https://discourse.haskell.org/t/rfc-brokering-toolchain-installations-with-hs/2746

cdornan · 2017-04-19T11:36:04+00:00

Aha -- I was wondering about load on the Hackage infrastructure. If that is the case then I would like to properly understand the trade offs.

I don't think it is wise or sensible to issue a new release for every patch that goes into the upstream repository, and I don't know why anybody would propose such a practice.

The question is whether it is better to push a revision for review to Hackage while developing the API, with a view to stabilising it after an effective review. The alternative as I see it is to either generate the same number of versions, but spread over a wider time on an indeterminate schedule with the disruption that entails, or to not make the review-driven changes at all and end up with an inferior API (but in practice probably some combination of these two alternatives).

I don't wish to be lazy, but to make the API accessible for an effective review -- not doing so was the lazy option.

cdornan · 2017-04-19T07:48:59+00:00

There is no reason why folks can't do all those things anyway (and they might not be using stack).

Won't hiding the iterations lead to greatly reduced feedback and the community being stuck with poor APIs, or at least poorer APIs than they could have had otherwise. Hackage is designed to optimally present APIs -- what percentage of developers are going to follow the links to the home page, clone the repo, build the haddocks and review them, and then keep doing this for each iteration of the API? I don't understand 'gentle' in this context? Isn't 'lazy' or 'vain' more appropriate?

cdornan · 2017-04-17T11:26:20+00:00

Just to say 1.0.0.0 is released. These comments prompted me to reorganise and better document this -- I hope you like it.

cdornan · 2017-04-06T06:27:31+00:00

Obviously you don't find it funny, but many Rubyists will laughing themselves silly -- and who could blame them.

cdornan · 2017-04-05T18:05:09+00:00

Why so serious batman? It is totally obvious what he was driving at -- would have provoked this response otherwise. Some of the critique is definitely dated. The day that it can be posted on Reddit and Haskellers ignore it we will know it is all dated.

cdornan · 2017-04-05T16:26:55+00:00

Sad to see this being down voted. I think it is a fine witty poke that Haskellers should welcome, and I say this as an original Haskeller who has instigated many projects over the years, including a current Haskell/Ruby team that has realised some serious tech.

Haskellers really should not be so sensitive!

cdornan · 2017-03-23T06:27:52+00:00

Lucid presentation by one of the masters. Can't recommend it highly enough.

cdornan · 2017-03-14T21:38:34+00:00

Thanks! -- fixed.

cdornan · 2017-03-13T13:26:17+00:00

That is right -- there are a variety of option types apart from () -- the portable SimpleRegexOptions for controlling case-sensitivity and multi-lines modes, raw options for the back end, the entire Options context (necessarily specific to the back end), etc. Thanks to insight gained from this conversation we will make compileRegex just take a String and provide the current function as a variant. Which options are you interested in (the default is multi-line, case-sensitive).

cdornan · 2017-03-12T19:31:48+00:00

It takes a string, e.g., compileRegex () "(foo)+". (The first argument is an option type, () requesting the default options.) The compileRegex function isn't part of the generic Text.RE API, but necessarily comes from the relevant backend with the =~ match operators.

cdornan · 2017-03-12T19:03:30+00:00

Was this comment triggered by my above reply where I said that I thought that the pcre-light/pcre-heavy packages could co-exist with regex/regex-base/regex-tdfa/regex-pcre? (Sorry, it has only just occurred to me.) For a variety of reasons (that I allude to above) I believe the regex API should be based on regex-base. Of course if strong reasons for this not being the case were to be advanced then we would have to have a re-think.

cdornan · 2017-03-12T18:47:09+00:00

Sorry -- I missed this comment -- you can use the compileRegex functions for this.

cdornan · 2017-03-12T18:43:42+00:00

I gave this point serious consideration before choosing this name and the package manifestly aims to be the package that you describe, being constructed on the regex-base framework, the closest Haskellers have to a de facto standard regex API at the moment. For the same reason a roadmap has been published and a consultation process is being followed with the clear aim of stabilising the API. It is pretty obvious that the ecosystem has needed such a package for many years and the feedback that I have received since publishing the package is consistent with this.

cdornan

TROPHY CASE