Overlap between function heads and match expression

[lpil]

Hello!

One thing that Alpaca has inherited from Erlang is the ability to write multiple function heads and use pattern matching to select the one that runs for given arguments.

val say : fn int -> string
let say 1 =
  "one"

let say 2 =
  "two"

let say _ =
  "dunno"

This serves the same purpose as the match expression.

val say : fn int -> string
let say n =
  match n with
  | 1 -> "one"
  | 2 -> "two"
  | _ -> "dunno"

Perhaps a question about the philosophy of the Alpaca language, but do we want both constructs when they serve the same purpose?

It would be my preference for there to a single way to express anything in the language as this reduces inconsistency in code written in the language, and also makes the language more approachable by reducing the number of things for newcomers to learn.

Thanks, Louis

[j14159]

Perhaps a question about the philosophy of the Alpaca language, but do we want both constructs when they serve the same purpose?

At present the existence of both is deliberate. match existed before function head matching which also got added because I missed having it :) In general I prefer function head matching but I think that it can get a little unwieldy sometimes and it can be cleaner to fall back to a match. It's also consistent in form with the syntax used by receive and beam so I think there's enough similarity there to warrant keeping it around.

Having said that, I'm not 100% opposed to trying out deprecating/removing match as an experiment at some point in the future but:

• it would require local functions/bindings to support function head matching and we might want some syntax changes to make this more pleasant.
• I think it would make us a little less consistent with other MLs (e.g. OCaml).
• I would like us to take a pretty careful look at how this changes the ergonomics of the language. This might get pretty subjective in some corners but I'd like to hear from a relatively wide cross-section of our (still relatively small) community.

I don't know if this is a good solution/something worth trying: a compiler flag that disables match, similar to the possible "decidability" flag that has been discussed elsewhere (would rule type a = int | float a type error).