5 ms·

> Fortunately, this is easily possible with Haskell. You need to enable the BangPatterns feature and use exclamations ! in front of patterns for variables where

> Fortunately, this is easily possible with Haskell. You need to enable the BangPatterns feature and use exclamations ! in front of patterns for variables where you want the evaluation to be performed eagerly. Of course, this is simple - you just enable a language extension so that the language you are referring to Haskell is no longer really Haskell. I think Haskell is a fine language, but given the amount of various language extensions that are needed for it to be usable in production without friction, it seems it will forever be a research language - and there is nothing wrong with that.

ParetoOptimal 4y ago
> I think Haskell is a fine language, but given the amount of various language extensions that are needed for it to be usable in production without friction, it seems it will forever be a research language - and there is nothing wrong with that. This isn't really a problem in the real world, only in theory.
nequo 4y ago
It is Haskell, just not Haskell2010. It is included in GHC2021. Would you say that a company that uses a subset of C++ as a policy is not using C++? Their definition of the subset is as arbitrary as another’s that uses BangPatterns.
- eptcyka 4y ago
  Sure, this language feature is mainstream now. But most real-world haskell codbases vary greatly in which language extensions they've chosen to use.
  - kzrdude 4y ago
    Is this a C++ benefit, that the competing implementations GCC and LLVM give each other's extensions to the language more legitimacy by having a second implementation? It doesn't seem like language extensions get so much attention in C++ codebases (but maybe I'm mistaken)?
    - tialaramex 4y ago
      C and C++ programmers who write only or mostly for a single platform often have some extensions they insist on, and may even regard the standard language (lacking these features) as defective. Linux won't compile in MSVC. Obviously it needn't, it's a kernel and not a Windows program, but it also can't, because it needs GNU extensions, which are now also implemented for Clang. If you write broadly cross platform software for C++ you are committed to supporting all three compilers and so that's effectively just the standard. Indeed if all three do or don't do something de facto that is the standard. The ISO document used to say C++ has optional garbage collection, it doesn't because none of the three compilers have that. The ISO standard still doesn't say pointer provenance is a thing, but all three compilers require it, so in fact it's a thing.
      - derefr 4y ago
        > The ISO document used to say C++ has optional garbage collection I'm intrigued; what was this feature supposed to look like?
        tialaramex 4y ago
        https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n26... The standard basically said, if your compiler supports this new feature, here's how you use it in your programs. And no compilers have ever supported the feature. So C++ 20 rips it back out.
- kleingeld 4y ago
  I believe one could avoid BangPatterns by using seq.
- jesse__ 4y ago
  I think his point is that a naive implementation of an extremely simple function uses 35x more memory than the 'optimal' implementation, which is not at all obvious without knowing internal details of the compiler.
mrkeen 4y ago
If our arguments can be so pedantic, then I can say: sure, Haskell is forever a research language. But that's irrelevant to me, because I use no-longer-really-Haskell.
- Brian_K_White 4y ago
  I agree with the original critique more than this defense, but I had to upvote the perfection of the expression of the point I don't agree with.
benreesman 4y ago
GHC language extensions are like C++ Technical Reports. They are a way to evolve the language without excessive red-tape on an opt-in basis, and periodically the ones that worked out make it into a new “standard”. It’s not really all the different from Python PEPs or Rust’s various proposals / nightly stuff. Just about every language has some form of this.
- UncleMeat 4y ago
  That's true. And when somebody says "oh you can just use GCC's special feature to make C++ tolerable" they rightly get pushback because only a portion of these features ever make it into a standard. This means that over time you end up with a codebase that is forever tied to these nonstandard features and might even end up being incompatible with major language changes. Or maybe the feature you adopted does get standardized but in a slightly different and incompatible way and now you've got a big problem on your hands. It is good for people to have ways of playing with a language so it evolves. It is (IMO) bad to suggest the adoption of these things as a means of making a language production-ready.
  - benreesman 4y ago
    Just about every successful C/C++ project uses flags or intrinsics or whatever to some degree. It’s not unusual or particularly problematic. Linux famously uses a bunch of GCC stuff (though I gather that’s in decline) and non-standard defaults like ‘-fno-strict-aliasing’. And the extensions in the article are for the most part in the GHC2021 standard. So it’s more like, this is in C++20. Younger languages like Rust or Kotlin or something have less pressure for mechanisms like this because you have to get to a certain point in the language lifecycle before the tradeoff tilts from “let’s do a breaking change at a point release” to “let’s flag in the new behavior”, but if (as I expect) e.g. Rust lasts as long as C++ or Haskell, it will be be bedazzled with all kinds of flags and extensions and stuff too, how else do you grow a language for 40 years?
    - derefr 4y ago
      > how else do you grow a language for 40 years? You could introduce things in one version of the standard, and then remove them in the next release if people didn't like it, such that to get the feature you have to specifically use --std=2022a, no earlier, no later; and if you want your project to track the evolution of the language rather than getting stuck on a particular version, you'd have to rip use of such features back out. You could sort of think of it as if you had a dependencies lockfile which includes a version-constraint on the major version of the compiler; where every time there's a change in what code is accepted, that major version of the compiler goes up. Any change other than changing what code is accepted as valid goes into the lower semver fields; and gets replicated across all major versions of the compiler, where relevant. (Except that you don't have to do this by actually maintaining separate major-version branches of the compiler for every standards release; you can do it the way we currently do feature flags, only the only flag you get is which standard-version your project is written for.) I don't think I've ever seen anyone actually do this for a language/compiler; but it's a common approach used for protocol and API-client libraries, and seems to work well there.

ParetoOptimal 4y ago

> I think Haskell is a fine language, but given the amount of various language extensions that are needed for it to be usable in production without friction, it seems it will forever be a research language - and there is nothing wrong with that. This isn't really a problem in the real world, only in theory.

nequo 4y ago

It is Haskell, just not Haskell2010. It is included in GHC2021. Would you say that a company that uses a subset of C++ as a policy is not using C++? Their definition of the subset is as arbitrary as another’s that uses BangPatterns.

eptcyka 4y ago
Sure, this language feature is mainstream now. But most real-world haskell codbases vary greatly in which language extensions they've chosen to use.
- kzrdude 4y ago
  Is this a C++ benefit, that the competing implementations GCC and LLVM give each other's extensions to the language more legitimacy by having a second implementation? It doesn't seem like language extensions get so much attention in C++ codebases (but maybe I'm mistaken)?
  - tialaramex 4y ago
    C and C++ programmers who write only or mostly for a single platform often have some extensions they insist on, and may even regard the standard language (lacking these features) as defective. Linux won't compile in MSVC. Obviously it needn't, it's a kernel and not a Windows program, but it also can't, because it needs GNU extensions, which are now also implemented for Clang. If you write broadly cross platform software for C++ you are committed to supporting all three compilers and so that's effectively just the standard. Indeed if all three do or don't do something de facto that is the standard. The ISO document used to say C++ has optional garbage collection, it doesn't because none of the three compilers have that. The ISO standard still doesn't say pointer provenance is a thing, but all three compilers require it, so in fact it's a thing.
    - derefr 4y ago
      > The ISO document used to say C++ has optional garbage collection I'm intrigued; what was this feature supposed to look like?
      - tialaramex 4y ago
        https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2670.htm https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n26... The standard basically said, if your compiler supports this new feature, here's how you use it in your programs. And no compilers have ever supported the feature. So C++ 20 rips it back out.
kleingeld 4y ago
I believe one could avoid BangPatterns by using seq.
jesse__ 4y ago
I think his point is that a naive implementation of an extremely simple function uses 35x more memory than the 'optimal' implementation, which is not at all obvious without knowing internal details of the compiler.

mrkeen 4y ago

If our arguments can be so pedantic, then I can say: sure, Haskell is forever a research language. But that's irrelevant to me, because I use no-longer-really-Haskell.

Brian_K_White 4y ago
I agree with the original critique more than this defense, but I had to upvote the perfection of the expression of the point I don't agree with.

benreesman 4y ago

GHC language extensions are like C++ Technical Reports. They are a way to evolve the language without excessive red-tape on an opt-in basis, and periodically the ones that worked out make it into a new “standard”. It’s not really all the different from Python PEPs or Rust’s various proposals / nightly stuff. Just about every language has some form of this.

UncleMeat 4y ago
That's true. And when somebody says "oh you can just use GCC's special feature to make C++ tolerable" they rightly get pushback because only a portion of these features ever make it into a standard. This means that over time you end up with a codebase that is forever tied to these nonstandard features and might even end up being incompatible with major language changes. Or maybe the feature you adopted does get standardized but in a slightly different and incompatible way and now you've got a big problem on your hands. It is good for people to have ways of playing with a language so it evolves. It is (IMO) bad to suggest the adoption of these things as a means of making a language production-ready.
- benreesman 4y ago
  Just about every successful C/C++ project uses flags or intrinsics or whatever to some degree. It’s not unusual or particularly problematic. Linux famously uses a bunch of GCC stuff (though I gather that’s in decline) and non-standard defaults like ‘-fno-strict-aliasing’. And the extensions in the article are for the most part in the GHC2021 standard. So it’s more like, this is in C++20. Younger languages like Rust or Kotlin or something have less pressure for mechanisms like this because you have to get to a certain point in the language lifecycle before the tradeoff tilts from “let’s do a breaking change at a point release” to “let’s flag in the new behavior”, but if (as I expect) e.g. Rust lasts as long as C++ or Haskell, it will be be bedazzled with all kinds of flags and extensions and stuff too, how else do you grow a language for 40 years?
  - derefr 4y ago
    > how else do you grow a language for 40 years? You could introduce things in one version of the standard, and then remove them in the next release if people didn't like it, such that to get the feature you have to specifically use --std=2022a, no earlier, no later; and if you want your project to track the evolution of the language rather than getting stuck on a particular version, you'd have to rip use of such features back out. You could sort of think of it as if you had a dependencies lockfile which includes a version-constraint on the major version of the compiler; where every time there's a change in what code is accepted, that major version of the compiler goes up. Any change other than changing what code is accepted as valid goes into the lower semver fields; and gets replicated across all major versions of the compiler, where relevant. (Except that you don't have to do this by actually maintaining separate major-version branches of the compiler for every standards release; you can do it the way we currently do feature flags, only the only flag you get is which standard-version your project is written for.) I don't think I've ever seen anyone actually do this for a language/compiler; but it's a common approach used for protocol and API-client libraries, and seems to work well there.