[HN Gopher] An alternative front end for Haskell?
___________________________________________________________________
An alternative front end for Haskell?
Author : amalinovic
Score : 45 points
Date : 2023-10-05 08:00 UTC (2 days ago)
(HTM) web link (gilmi.me)
(TXT) w3m dump (gilmi.me)
| thealistra wrote:
| Just an opinionated bunch of changes. Some of them I really hate.
| Some of them I don't care.
|
| This should really by going though proposals 1 by 1. Not as a
| features-someone-likes.
|
| Cons list syntax is the worst proposal
| sparkie wrote:
| Instead of the cons proposal, should just make the `(:)`
| operator work on ListLike[1] instead of only built in lists.
|
| [1]:https://hackage.haskell.org/package/ListLike-4.7.8/docs/Dat
| a...
| temp123789246 wrote:
| Curious about the reasoning for removing type aliases? I don't
| have an opinion on that myself
| tadfisher wrote:
| newtypes are strictly better. Basically 100% of the time a type
| alias leaks some API that's inappropriate for the intended
| usage of the type, and you can derive newtype methods if you
| actually want to do that.
| codeflo wrote:
| Many of these address "paper cuts". Individually, they aren't
| huge issues. But lots of small annoyances can easily add up and
| make a language not fun to use, and especially punishing for
| beginners. That's why some language communities prioritize fixing
| such paper cut problems. The Haskell community mostly doesn't
| seem to.
|
| Another minor thing that happens to annoy me very much is how
| everything about Haskell's syntax and standard conventions is so
| diff-unfriendly.
|
| To see what I mean, I picked the first "official" example I could
| find. Here are a few lines of code from the one of the examples
| in the Haskell playground (https://play.haskell.org/ -- it seems
| to pick a random one each time you load it):
| data Visitor = Member Profile | NonMember
| (Maybe T.Text) deriving Show data Profile
| = Profile { name :: T.Text ,
| birthday :: Time.Day } deriving Show
|
| You see Haskell code like this all the time, and the (IMO old-
| fashioned) lack of an optional trailing comma practically forces
| you into something like this. But just imagine inserting another
| variant to Visitor before Member, or removing the name field from
| Profile!
|
| A more practically minded language might allow a syntax like
| this: data Visitor = | Member Profile
| | NonMember (Maybe T.Text) deriving Show
| data Profile = Profile { name :: T.Text,
| birthday :: Time.Day, } deriving Show
|
| Bamm, each line is identical, editing is easy, diffs are clean.
| TypeScript, for example, has something like this for union types.
| Haskell unfortunately doesn't.
| crote wrote:
| This resonates quite strongly with me.
|
| Back when I first learned Haskell, I strongly got the
| impression that the Haskell community just... didn't like
| programming? I kept running into endless papercuts like these,
| language extensions which were poorly documented and mutually
| incompatible but basically mandatory due to widespread usage,
| and libraries which were considered "top-of-the-line" but where
| anything beyond the happy path was considered an open research
| topic.
|
| All in all, it felt more like a loose collection of unfinished
| PhD theses than an actual programming language. Which is a real
| shame, because it has quite a few _excellent_ concepts which
| are a genuine pleasure to use. Unfortunately I think languages
| like Rust and F# are essentially killing any chance it has at
| gaining a mainstream foothold: they bring over enough of the
| good parts of Haskell into mainstream programming that it
| simply isn 't worth having to deal with the bad parts anymore.
| Ossiamk wrote:
| [dead]
| frou_dh wrote:
| Tried with OCaml, multiple times, and they all withered away and
| practically everyone is back to using normal OCaml syntax.
|
| (I'm not only talking about ReasonML, Reason, ReScript etc. There
| was a more officially proposed revised syntax too:
| https://caml.inria.fr/pub/old_caml_site/camlp4/tutorial/tuto...)
| stepchowfun wrote:
| Most of the comments so far are negative, so I'll add something
| positive. One thing I love about the Haskell community is how
| they are always questioning their assumptions and genuinely
| seeking the best way to do things (often drawing upon or
| contributing to computer science research). The core concepts
| behind Haskell are clean and simple (essentially something
| between System F and System Fo), but there's a lot of baggage on
| the surface that obscures that underlying elegance. We should
| encourage people taking an introspective look into their tools
| and asking how they can be better, even if certain proposals are
| unrealistic or controversial.
|
| I think the author is just writing down their opinions (which are
| worth discussing!) and not seriously trying to start a new GHC
| frontend. Personally, I think Haskell is approximately stuck in a
| local maximum, which can only be escaped by embracing dependent
| types (which are actually simpler than where Haskell has been
| heading) rather than building increasingly complex approximations
| of them. Once you try a dependently typed language like Agda,
| Lean, Coq, or Idris, it's hard to go back to the complexity of
| having two (or more!) separate languages for types and programs.
|
| Regarding the proposals in the article, the most interesting to
| me is (2), although I'm not sure about some of the specifics. In
| general, I think Haskell needs a way to graduate (or retire)
| language extensions, rather than having them accumulate
| unboundedly. It's harder to talk about Haskell when everyone is
| using a different flavor of it.
| codeflo wrote:
| > Personally, I think Haskell is approximately stuck in a local
| maximum, which can only be escaped by embracing dependent types
|
| To give a counter point, there seem to be lots of small wins
| that aren't taken, possibly in part _because_ people seem to
| wait for the big ideas.
|
| Take partial functions like head: You can do what Haskell and
| Java do and throw an exception. Or you can have dependent types
| and statically prevent the function from being applied to an
| empty list. But the obvious and easy solution in the current
| language would be to return Maybe, which isn't done because
| there's a feeling that it's not a big enough step to be worth
| the effort, and dependent types will eventually solve this
| anyway.
| Quekid5 wrote:
| That's an interesting counterpoint, but I think it's a bit of
| a different tradeoff. Adding, say, dependent types, can be
| done as a gradual process with opt-in (via language
| extensions) and "only" requires heroic effort on the part of
| the compiler writers... whereas changing 'head' requires
| 10000i Hackage packages to update their code.
|
| This is all tied into how inflexible the base/Prelude story
| is currently, etc. If the Prelude were a fully independent
| library where you could just depend on any old version you
| like, then there'd be no problem changing the signature.
| (Other than the usual diamond dependency problems). Of course
| you can choose NoPrelude and go from there, but then you're
| already in a place where changing 'head' doesn't matter to
| you, only the maintainer of your alternative Prelude.
|
| People are working on both of these aspects, and that's got
| me really excited about where Haskell is going these days!
|
| (I've always loved Haskell as a language, but there have been
| undeniable ecosystem issues.)
| mhitza wrote:
| > I think Haskell needs a way to graduate (or retire) language
| extensions, rather than having them accumulate unboundedly.
| It's harder to talk about Haskell when everyone is using a
| different flavor of it.
|
| That is what the standardization process is for. I don't think
| that the parties that could write a new Haskell standard have
| the time, resources, or bandwidth to work on one. That's why
| for now we're stuck with 98, 2010 and a bunch of extensions.
| chpatrick wrote:
| These are by far not the biggest problems with Haskell and
| splitting the language will definitely not help.
___________________________________________________________________
(page generated 2023-10-07 23:00 UTC)