So how did you learn this? I tried looking at the core language a few times but it never helped me in any way.
I am aware that there are a bunch of articles I could read, say Implementing lazy functional languages on stock hardware: The spineless tagless G-machine by Simon @simonpj. Is this how you learned and would suggest one to?
Is there a way to write straight in the STG language and have GHC run it? This would allow for a writing of a tutorial, where you do something and spectacularly stuff happens. It would be much better to start with than theory. I like me a tutorial.
Right now, I am afraid to say, this STG code does not show anything to me at all. I do think this is a good advice, I only need to find a way to follow it.
I guess mostly through osmosis – hearing things like “in STG let directly corresponds to allocation and case to evaluation” – and lots of experimentation, seeing which programs produce which STG code.
I did not learn it from SPJ’s paper. I think it is a decent academic description, but rather abstract and presenting all the details straight away. Instead I think it would be better to have a tutorial that builds up from a simpler language to the full STG machine in several steps. Perhaps I could try to write something like that if I can find the time.
Thoroughly bad idea. (What you quote is at best misleading.) What’s more, O.P. is asking whether something has changed wrt FlexibleContexts – or at least why the User Guide seems to have changed. See my answer above: AFAICT, there’s been no change in behaviour; there’s been some ‘rationalisation’ of the structure of the Guide.
Whoa! 30 years ago the pre-eminent compiler was Hugs. GHC was playing catch-up. And the restrictions on Contexts were entirely sensible for a wholly new thing: TypeClasses/Instances/therefore Contexts were the innovation in Haskell; no other language (functional or otherwise) had anything like them.
I several times above mentioned FlexibleInstances. Those weren’t allowed as at 1990 because they’d lead to OverlappingInstances. And everybody was highly nervous about that (rightly so). If you don’t have FlexibleInstances, you don’t need FlexibleContexts.
Overlapping Instances – especially combined with other extensions like MultiParamTypeClasses and FunctionalDependencies are a nest of vipers. That’s why FlexibleInstances (and therefore Contexts) were kept out of Haskell 1998 although both main compilers already supported them; and still kept out of H2010.
Note that the Prelude doesn’t “need” FlexibleInstances nor Contexts. So it’s not like omitting them is cramping your Haskell style.
I feel some apology and gentle encouragement is due to O.P. This thread has rapidly veered away from learning about extensions into areas no newbie or even intermediate Haskeller needs to understand.
I suggest those who want to talk about type inference and STG/core/dumps split all that stuff on to a train-spotters thread.
I am not sure if your intention is to correct a possible factual error in what I said, or to add more information, or something else… This is all history for me: I have not been writing any Haskell back then. So, I may be wrong in the range of dates — but what you are saying seems to corroborate what I said. I cannot really tell what emotions the «whoa» should convey, since this interjection is outside of my cultural context.
I should be glad to do so but I reckon it requires moderatorial powers.
I thought so as well until I tried to implement the extension, got very confused, and discovered this issue. It’s a flaming trashcan. Or put otherwise, it’s exhibit B as to why you can’t just keep piling extension upon extension to a 25 year old language standard. Exhibit A is the the Prelude of course.
To be frank, is there any commonly used extension that will break your code in a way it’s never been broken before? Have you ever contemplated “should I really turn on extension X, or can I get away without it”? The only extension I’ve ever had problems with was PolyKinds. I have never personally had code review rejected because “I turned on some questionable extension”. I never had to defend a usage of any extension.
As OP is “relatively new to Haskell” and asked about “how others approach learning language extensions”, I’d definitely advise just turning on what the compiler suggest you to turn on, and learn via examples. Reasoning about how a specific extension/optimization changes the way GHC optimizes/executes your program (actually, reasoning about most things GHC does) is waaaay above the entry level, and not many people are able to do so. And every now and then, we see contrived examples of unwanted GHC behaviours popping up. So I’d say, turn things on, have fun, and don’t think much about details (yet!).
Sorry but this is terrible advice. You need to understand why your code doesn’t compile without the suggested extension. If you don’t, it’s more likely that your code is wrong than you just forgot to enable an extension. For example, one common GHC suggestion nowadays is to enable AllowAmbiguousTypes, but that would usually be a mistake.
But OP will know why his code doesn’t compile, GHC usually prints a rationale behind why a particular extension is needed.
Btw, best learning is learning by mistake. If I turn on a bad extension and get a different error, I’d roll back and read more. This is a learning process. Experimenting. No reason to be correct first try all the time. I don’t know why people seem to be so strict about stuff that should naturally come with trial-and-error experience.
I think the AllowAmbigousTypes note could just use some extra qualifiers - no need to throw it out. Because it is a useful pointer if you’re actually writing code like that (ime, many Haskellers naturally end up wanting it for certain things).
But an extra pointer saying “if you don’t want this, it’s probably some other issue” would be a nice addition.
Just no. This is more terrible advice. As this thread (esp @blamario) is pointing out, GHC’s habit of (attempting to) document each extension as if it’s orthogonal to the others gives a newbie no support when they get into deep water. Especially when GHC’s message suggests switching on a further extension. Note what’s bad about AllowAmbiguousTypes is there’s no new syntax enabled: if you intended to use (say) MultiParamTypeClasses you at least need to declare a class with multiple params before GHC suggests that extension.
Rather than “roll back and read more” a lot of newbies will conclude Haskell is too hard and abandon the language. And frankly GHC is too hard. Haskell 2010 + a small set of extensions isn’t; and I wish there were a way for a newbie to say: please don’t go suggesting exotic extensions.
"… and abandon the language. "
BTW O.P. seems to have fallen silent on this thread. I hope they’re not scared off already.
I didn’t say that extension was ‘easy’; merely easier than what’s to come.
“flaming trashcan” is being too harsh. Thank you for being pernickety on that ticket, but I don’t think that should put off a newbie.
Although GHC treats extensions as orthogonal AFAP, educationally we should present them as building on each other: first FlexibleContexts; then FlexibleInstances; then MPTCs; etc. (Which corresponds roughly to the order they arrived. FlexibleContexts before 1998; KindSignatures 2007.)
Switching on KindSignatures is definitely not newbie level. Switching that on without FlexibleInstances is downright pathological. I suppose the documentation should get it right, but that’s not justification for the-sky-is-falling.
