4 ms·

To reply to both of your respondents at once, > Of course, each language extension changes the syntax and/or semantics of the language, so in order to "learn H

by tome 6y ago

To reply to both of your respondents at once, > Of course, each language extension changes the syntax and/or semantics of the language, so in order to "learn Haskell" I'd have to learn one or more flavors/styles of it – and there doesn't seem to be one standard set of language extensions that are commonly used > It seems like every Haskell project makes use of a different subset of 10 to 20 language extensions, each of which requires some deep knowledge of type theory to understand how it affects the language. These comments are both pretty off the mark. It's unhelpful to think of language extensions (the most commonly-used ones at least) as extending the language. It's more that there is one overall Haskell language and the absence of a particular language extension disables a particular feature. The language is, by and large, more coherent with language extensions turned on, not less coherent.

elbear 6y ago
Maybe it's more coherent, but the fact that, after learning the language, you discover that you have 20 more extensions to learn feels like a never-ending quest. I think that's what the previous commentators mean. If the language is more coherent with the extensions, they should enable them by default.
- pyrale 6y ago
  Most haskell programmers I know don't know or use all extensions, and do just fine without them. I personally don't know most of them, and I've been doing haskell professionally for years now. Once in a while, I will need to do a specific thing and will google up stuff, and the thing I'll write will remain contained in a couple files, and callers won't have to know about it. It is absolutely not a prerequisite to know all extensions to earn one's living doing Haskell, just like one doesn't have to know the JVM or the dozens of design patterns inside and out to program in Java.
  - rattray 6y ago
    > It is absolutely not a prerequisite to know all extensions Which ones are a prerequisite? OverloadedStrings? TemplateHaskell? How many others? If the answers to that list were enabled by default in the language, and most Haskellers agreed on them, there really wouldn't be much complaint – you'd reach for these fancy macros when you need them, like you say, and that'd be that. A newcomer wouldn't know that some of them are required reading and others aren't and not know which is which.
    - tome 6y ago
      Learn them when you come across them, like any other language feature. It's as simple as that. That they are enabled via an extension is really just a historical quirk of the language having been originally defined by a standard.
    - pyrale 6y ago
      I have never touched template haskell. OverloadedStrings is one of the few extensions you'll see everywhere, but there's nothing to remember about it. It's really the kind of thing you'll understand in 10s and find obvious forever after. > If the answers to that list were enabled by default in the language, and most Haskellers agreed on them, there really wouldn't be much complaint Here is the thing: just moving all the extensions into the language and removing the pragma would basically mean there would still be the same amount of things in the language, but with no convenient way to know what's used in a specific file, and it would be hard to research that topic which you don't know. Extensions are great in that they force devs to label files with searchable names for the concepts they use in the code. > A newcomer wouldn't know that some of them are required reading and others aren't and not know which is which. A newcomer, just like a seasoned haskeller, shouldn't bother learning new extensions if they're not about to use them. That's the way to go forward.
    - dllthomas 6y ago
      I like TemplateHaskell, but it's very much a "turn it on where you need it" thing. On the other side, ScopedTypeVariables is the way the language should have always worked, and should probably just be enabled globally. OverloadedStrings is a trivial syntactic convenience, where every use of a string literal is replaced by (fromString "the string literal"). This makes code substantially more readable when you are wanting literal values of (typically) Text. The downside is that the compiler can't always know what type fromString is expected to return, so you sometimes need to add more type annotations, which gets messy again. I don't care much which way it's set at a project level - I toggle it per file if the project default is too much of a pain locally.
- tome 6y ago
  > If the language is more coherent with the extensions, they should enable them by default. The main reason that they are not enabled by default is that Haskell has a standard. It's like gcc having -std=c++11, except the opposite way around.
rattray 6y ago
> there is one overall Haskell language and the absence of a particular language extension disables a particular feature. The language is, by and large, more coherent with language extensions turned on Right, that's exactly it! Almost nobody uses Haskell without un-disabling many features; in doing so, they discover "Real Haskell" and leave behind the less-coherent "Plain Haskell". However, there is no central understanding (that I've ever seen) of what "Real Haskell" is. Everyone defines their own. Beauty being in the eye of the beholder, it's thus no wonder that wizened Haskellers come back from the wilderness speaking of a thing of magnificence – for the Haskell they have seen is a Haskell they wrought. They found the extensions that suited them, and unlocked the "Real Haskell" of their dreams. But for a new adventurer setting out, there is no one charted path to Nirvana; only swirling rumors, each as different as the next. Perhaps all travelers agree that a good bit of String is necessary to carry along, but it ends there. This isn't to say that Haskell fails – there are many who love it, and its curiosities inspire much exploration in plainer realms – but.... well, you can see that it wouldn't be appealing to someone who wants to understand a system instead of playing a choose-your-own-adventure mystery game ;)
- tome 6y ago
  This is a tale that people like to weave. I can only imagine that they haven't used Haskell much, or at least my experience is completely different. Sometimes I try to do something that seems sensible. The compiler says "you can't do this, you need to turn on -XExtension". I do so. The end. It's really not terribly mysterious or complicated.
  - rattray 6y ago
    Hmm, ok. Yeah that really doesn't sound so bad.
  - dllthomas 6y ago
    > I do so. The end. Ehh... except the times it thinks I could do something with an extension, but it's not actually something I want to do. Still, it's very nice to have the starting point, and I agree it's not a bad experience overall. Edited to add an example: Prelude> 1 2 <interactive>:1:1: error: • Non type-variable argument in the constraint: Num (t1 -> t2) (Use FlexibleContexts to permit this) • When checking the inferred type it :: forall t1 t2. (Num t1, Num (t1 -> t2)) => t2 Prelude> :set -XFlexibleContexts Prelude> 1 2 <interactive>:3:1: error: • Could not deduce (Num t0) from the context: (Num t, Num (t -> t1)) bound by the inferred type for ‘it’: forall t t1. (Num t, Num (t -> t1)) => t1 at <interactive>:3:1-3 The type variable ‘t0’ is ambiguous • In the ambiguity check for the inferred type for ‘it’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type it :: forall t1 t2. (Num t1, Num (t1 -> t2)) => t2 Prelude> :set -XAllowAmbiguousTypes Prelude> 1 2 <interactive>:5:1: error: • No instance for (Num (Integer -> ())) arising from a use of ‘it’ (maybe you haven't applied a function to enough arguments?) • In the first argument of ‘print’, namely ‘it’ In a stmt of an interactive GHCi command: print it There's nothing wrong with enabling FlexibleContexts, but it's not going to solve your problem. You likely don't want AllowAmbiguousTypes on globally (though it's not as dangerous as it might sound). The final error message you get is the most useful, so going on this little journey isn't terrible, but it could have been short circuited if you took a beat to understand the extension it was asking for, and why it's being asked for in this context. Edited to add: The problem with the above code, of course, is that I'm trying to apply the function 1 to the value 2, but 1 doesn't represent a function. But it could! Because the way number literals in Haskell are handled is much the same way as OverloadedStrings works - 5 is treated as (fromInteger 5) - and they have type (Num a => a), so that the context gets to pick which numeric type they're interpreted as. As far as the language is concerned, I could make integer literals represent functions that (say) add that number to an input: instance Num (Integer -> Integer) where fromInteger n = (+ n) ... ... but that's not actually what I wanted. Almost certainly, it was a typo.

by tome 6y ago

elbear 6y ago

Maybe it's more coherent, but the fact that, after learning the language, you discover that you have 20 more extensions to learn feels like a never-ending quest. I think that's what the previous commentators mean. If the language is more coherent with the extensions, they should enable them by default.

pyrale 6y ago
Most haskell programmers I know don't know or use all extensions, and do just fine without them. I personally don't know most of them, and I've been doing haskell professionally for years now. Once in a while, I will need to do a specific thing and will google up stuff, and the thing I'll write will remain contained in a couple files, and callers won't have to know about it. It is absolutely not a prerequisite to know all extensions to earn one's living doing Haskell, just like one doesn't have to know the JVM or the dozens of design patterns inside and out to program in Java.
- rattray 6y ago
  > It is absolutely not a prerequisite to know all extensions Which ones are a prerequisite? OverloadedStrings? TemplateHaskell? How many others? If the answers to that list were enabled by default in the language, and most Haskellers agreed on them, there really wouldn't be much complaint – you'd reach for these fancy macros when you need them, like you say, and that'd be that. A newcomer wouldn't know that some of them are required reading and others aren't and not know which is which.
  - tome 6y ago
    Learn them when you come across them, like any other language feature. It's as simple as that. That they are enabled via an extension is really just a historical quirk of the language having been originally defined by a standard.
  - pyrale 6y ago
    I have never touched template haskell. OverloadedStrings is one of the few extensions you'll see everywhere, but there's nothing to remember about it. It's really the kind of thing you'll understand in 10s and find obvious forever after. > If the answers to that list were enabled by default in the language, and most Haskellers agreed on them, there really wouldn't be much complaint Here is the thing: just moving all the extensions into the language and removing the pragma would basically mean there would still be the same amount of things in the language, but with no convenient way to know what's used in a specific file, and it would be hard to research that topic which you don't know. Extensions are great in that they force devs to label files with searchable names for the concepts they use in the code. > A newcomer wouldn't know that some of them are required reading and others aren't and not know which is which. A newcomer, just like a seasoned haskeller, shouldn't bother learning new extensions if they're not about to use them. That's the way to go forward.
  - dllthomas 6y ago
    I like TemplateHaskell, but it's very much a "turn it on where you need it" thing. On the other side, ScopedTypeVariables is the way the language should have always worked, and should probably just be enabled globally. OverloadedStrings is a trivial syntactic convenience, where every use of a string literal is replaced by (fromString "the string literal"). This makes code substantially more readable when you are wanting literal values of (typically) Text. The downside is that the compiler can't always know what type fromString is expected to return, so you sometimes need to add more type annotations, which gets messy again. I don't care much which way it's set at a project level - I toggle it per file if the project default is too much of a pain locally.
tome 6y ago
> If the language is more coherent with the extensions, they should enable them by default. The main reason that they are not enabled by default is that Haskell has a standard. It's like gcc having -std=c++11, except the opposite way around.

rattray 6y ago

> there is one overall Haskell language and the absence of a particular language extension disables a particular feature. The language is, by and large, more coherent with language extensions turned on Right, that's exactly it! Almost nobody uses Haskell without un-disabling many features; in doing so, they discover "Real Haskell" and leave behind the less-coherent "Plain Haskell". However, there is no central understanding (that I've ever seen) of what "Real Haskell" is. Everyone defines their own. Beauty being in the eye of the beholder, it's thus no wonder that wizened Haskellers come back from the wilderness speaking of a thing of magnificence – for the Haskell they have seen is a Haskell they wrought. They found the extensions that suited them, and unlocked the "Real Haskell" of their dreams. But for a new adventurer setting out, there is no one charted path to Nirvana; only swirling rumors, each as different as the next. Perhaps all travelers agree that a good bit of String is necessary to carry along, but it ends there. This isn't to say that Haskell fails – there are many who love it, and its curiosities inspire much exploration in plainer realms – but.... well, you can see that it wouldn't be appealing to someone who wants to understand a system instead of playing a choose-your-own-adventure mystery game ;)

tome 6y ago
This is a tale that people like to weave. I can only imagine that they haven't used Haskell much, or at least my experience is completely different. Sometimes I try to do something that seems sensible. The compiler says "you can't do this, you need to turn on -XExtension". I do so. The end. It's really not terribly mysterious or complicated.
- rattray 6y ago
  Hmm, ok. Yeah that really doesn't sound so bad.
- dllthomas 6y ago
  > I do so. The end. Ehh... except the times it thinks I could do something with an extension, but it's not actually something I want to do. Still, it's very nice to have the starting point, and I agree it's not a bad experience overall. Edited to add an example: Prelude> 1 2 <interactive>:1:1: error: • Non type-variable argument in the constraint: Num (t1 -> t2) (Use FlexibleContexts to permit this) • When checking the inferred type it :: forall t1 t2. (Num t1, Num (t1 -> t2)) => t2 Prelude> :set -XFlexibleContexts Prelude> 1 2 <interactive>:3:1: error: • Could not deduce (Num t0) from the context: (Num t, Num (t -> t1)) bound by the inferred type for ‘it’: forall t t1. (Num t, Num (t -> t1)) => t1 at <interactive>:3:1-3 The type variable ‘t0’ is ambiguous • In the ambiguity check for the inferred type for ‘it’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type it :: forall t1 t2. (Num t1, Num (t1 -> t2)) => t2 Prelude> :set -XAllowAmbiguousTypes Prelude> 1 2 <interactive>:5:1: error: • No instance for (Num (Integer -> ())) arising from a use of ‘it’ (maybe you haven't applied a function to enough arguments?) • In the first argument of ‘print’, namely ‘it’ In a stmt of an interactive GHCi command: print it There's nothing wrong with enabling FlexibleContexts, but it's not going to solve your problem. You likely don't want AllowAmbiguousTypes on globally (though it's not as dangerous as it might sound). The final error message you get is the most useful, so going on this little journey isn't terrible, but it could have been short circuited if you took a beat to understand the extension it was asking for, and why it's being asked for in this context. Edited to add: The problem with the above code, of course, is that I'm trying to apply the function 1 to the value 2, but 1 doesn't represent a function. But it could! Because the way number literals in Haskell are handled is much the same way as OverloadedStrings works - 5 is treated as (fromInteger 5) - and they have type (Num a => a), so that the context gets to pick which numeric type they're interpreted as. As far as the language is concerned, I could make integer literals represent functions that (say) add that number to an input: instance Num (Integer -> Integer) where fromInteger n = (+ n) ... ... but that's not actually what I wanted. Almost certainly, it was a typo.