An alternative frontend for Haskell?

[sullyj3]

I like a lot of these ideas in a vacuum, but I don’t think they’re worth the fragmentation. It also becomes a bit too kitchen sink further down. Eg polymorphic variants seems like a pretty significant change. It would have massive divergent effects on the ecosystem and interop with regular haskell.

[atravers]

@atravers

[…]

…how on this planet did I forget this?

• GitHub - haskell-lisp/liskell: Haskell Semantics with Lisp Syntax

  • Haskell Lisp - HaskellWiki

---

While not “Haskell with an alternative syntax”, these could also be informative…and they appeared in my search:

• curry-frontend: Compile the functional logic language Curry to several intermediate formats

• Stack Builders - Connecting a Haskell Backend to a PureScript Frontend

• [HIW’22] Compiling Mu with GHC: Halfway Down the Rabbit Hole

[AntC2]

@atravers

remove […] partial functions like head […]

…and (/), div, mod, divMod, quot, rem, quotRem, et al!

… and (+), (-), (*) for fixed-width numeric types, because they can cause over/underflow without even giving a run-time exception.

@george.fst

This is really not that different to what I’d do in Haskell:

f = \case
    Nil -> _
    Node{value} -> _

@gilmi

Btw you can still do the thing you wanted to do in Haskell with similar convenience and without field selectors by using aliasing:

incTree = \case
  Nil -> Nil
  n@Node{value} -> n { value = value + 1 }

In view of the risk of partialness for field selector functions/if we’re only ever going to pattern match for label bindings [**], I’d like to allow labels spelled upper-case. To me they’re more like (de-)constructors, not functions.

[**] Or if we’re going to use specific syntax Node.Value for field access.

@jameshaydon

    updateCounts i acc = if isEven i
      then acc {evens = acc.evens + 1}
      else acc {odds  = acc.odds + 1}

(This is working Purescript code.)
Note that I don’t need to declare the record type anywhere, this code just works standalone. This is what I understand by anonymous (unnamed, undeclared) records.

Yeah even with my Haskell-ish eyes, that update syntax looks misleading: I have to do a double-take that’s not function acc applied to some record.

    updateCounts i {Evens = evens, Odds = odds} = if isEven i
      then {Evens = evens + 1, Odds = odds}
      else {Evens = evens,     Odds = odds + 1}

Any more readable? (It’s just making explicit what the code will compile to anyway.) Or?

    updateCounts i {Evens = evens | r} | isEven i = {Evens = evens + 1 | r}
    updateCounts i {Odds = odds   | r}            = {Odds = odds + 1   | r}

[AntC2]

@gilmi

being able to write let x = Nil in x { value = 1 } and value Nil

I’m not seeing anything specific to Haskell records/field selectors:

let y = Nothing in fromJust y

let z = [] in head z

Of course real-life examples are going to be more convoluted than that. The coverage checker will detect the ‘obvious’ ones.

remove footguns such as partial functions like head

Fast as you remove them, people are going to write their own. And uses of head might be perfectly safe – it’s just the coverage checker can’t see through the program logic.

[AntC2]

@gilmi

In a language with first class records like PureScript, field selector like the ones in Haskell are irrelevant because they don’t work on the data type Tree, they work on the payload of Node. So your snippet becomes:

incTree = case _ of
  Nil -> Nil
  Node r ->
    Node (r { value = r.value + 1 })

You can get that code accepted in Haskell today (or even in H98 except for the r.value: use value r instead). You need

data Tree a
      = Nil
      | Node (Node' a)
data Node' a = MkNode{ value :: a, left :: Tree a, right :: Tree a }

IOW, just as with purescript, nest an extra constructor to express the field names. You might even be able to use the auxiliary Node' within other data types; in effect re-using the field names.

So your ‘Alternative front end’ could support some syntactic sugar to make those decls less verbose.

There are good reasons to introduce free-standing first-class records/global field labels into a Haskell, but merely to avoid partial access is not one of them: I suspect the nested-constructor here will be just annoying enough people will define direct extractor functions – and you’re back to partiality.

[atravers]

remove […] partial functions like head […]

…and at 2022 Nov 16, the canonical precedent was set for all future decisions regarding partiality in Haskell. Now the wait begins for “the other shoe to drop” - the first of the proposals to remove them altogether from the current front-section.