Syntactic sugar for destructuring patterns in more places

[stylewarning]

So, you probably have written this a million times by now:

(define-type Foo (Foo Integer))

(define (frob f)
  (match f
    ((Foo n) ...)))

Or perhaps even

(map (fn (x) (match x ((Foo n) ...))) ...)

There's been desire and enthusiasm to make cases like these easier to type, since they come up frequently. This discussion thread is to collect proposals and discuss them. If you have a new proposal, please add a ## Proposal n: title and discuss what it is. If you're commenting on a proposal, please mention it by number.

To start, here are some proposals.

Proposal 0: Unproposal

One proposal is to do nothing. The language is simpler with fewer, more orthogonal syntactic constructs. Writing a formal semantics for Coalton wouldn't require having the user make simplifying assumptions (even if they're "without loss of generality"). Code processing Coalton is simpler. Code producing Coalton is simpler. Writing debuggers (and related functionality) is slightly simpler.

The negative is that we don't actually address this pain point.

Proposal 1: Sugar macros

We could add some new macros to Coalton. Coalton would remain as-is, but the new macros would be available for people who want them. For instance, we could have define* and fn* for destructuring variants (think * as "splat").

(define* ((Foo n))
  ...)

(map (fn* ((Foo n)) ...) ...)

This could be generalized to multiple arguments. The macro's pseudocode would be something like

(defmacro define* (name args body)
  `(define ,name (fn* ,args ,body)))

(defmacro fn* (args body)
  assert |args| >= 1
  let gargs = gensym each arg
  `(fn ,gargs [for each arg,garg: if not patternp(arg) then (let ((garg arg)) ...) else (match garg (arg ...))]))

Pros: Orthogonality and a small language are maintained, "just library code"

Cons: Now users have a choice between define and define*. If everybody ends up writing define* anyway, what's the point?

Proposoal 2: Build sugar into define and fn

We could also extend the AST to support this directly. The compiler internally would perform the rewrite into simpler base operators.

Pros: Fewer operators, more homogeneous code, probably nicer debugging in theory

Cons: The "small set of operators" are now syntactically overloaded with many ways to write them

Proposal 3: Make %define and %fn core operators, let define and fn be sugar

This is proposal 1, but with a different naming convention. We could define define and fn as sugar operators in the library and let %define (or some other name) be the "core" variants.

Pros: Small language in tact and sort of "hidden", formal semantics still easy to write, clear delineation of what's "internal" (though accessible!) to users

Cons: The "core" language is no longer idiomatic.

It's probably worth noting Haskell goes through a severe desugaring phase, and that's worked well for them AFAIK.

[gefjon]

To explicate my position in this more formal non-Discord context: I am in favor of proposal 2 or 3. I have no particular opinion about whether the primitive operators should handle this and be desugared by the compiler, or whether the public interfaces should be macros which expand into primitive operators. From a user's perspective, I don't believe it matters. (Coalton should be able to print the pre-macro-expansion source form in its error messages, but that's a separate discussion.)

I also very much want let to support destructuring, both when used as an expression on its own and when appearing as a statement in a progn. I assume this is no more technically or morally difficult than fn.

I'm opposed to proposal 1 because:

• In the Common Lisp world, I've had to explain to beginners the difference between let and let*, and it's a pain.
• One of the proposed operators is clearly more general and more useful than the other, so it should be preferred by users, blessed by the language, and therefore get the shorter name.

[eliaslfox]

I'm in favor of proposal 2. Code desugared in macros isn't visible to the compiler, and leads to worse error messages.

[stylewarning]

I'm in favor of proposal 2. Code desugared in macros isn't visible to the compiler, and leads to worse error messages.

I don't see why a macro expansion couldn't produce debug info that attaches itself to the AST somehow. It's an interesting thing to think about and I think it's a relatively under-explored area.

[gefjon]

the coalton-toplevel macro must call macroexpand on its subforms at some point, right? if so, it should be relatively easy to keep track of both the source form and the macro-expansion (probably via a special variable which holds a hash-table which maps forms to their source forms), and to have error messages print both.

[chebert]

I like proposal 2 or 3. I think pattern matching is such a core part of ADT systems that having the function definitions themselves be able to match seems intuitive from a UX perspective. I don't think I would need a let binding to be able to match, but come to think of it, it would be nice to capture a whole match. If I recall correctly, In haskell this would be whole@(Constructor _ arg2 _)

[gefjon]

to be clear: neither proposal 2 nor 3 suggests allowing the haskell thing where multiple top-level definitions for the same function can coexist and do pattern matching. i can't speak for the maintainers, but personally i am very uncomfortable with the ordering of top-level forms having semantic meaning, which is a requirement if you want top-level definitions to do matching. this discussion is about whether binding forms should be able to destructure, which is to say, match with the requirement that a single pattern be exhaustive.

[chebert]

Ah, okay thanks for clarifying: I didn't understand that. If that's the case: I don't really have interest in any of the proposals. I'd be interested in a function form that handles creating functions and can match multiple patterns.

Edit: Just as an example of what I mean:

(fn-match
    (((Just a) (Left b)) (+ a b))
    ((Nothing _) 0)
    ((_ _) -1))

[rdm70]

When using optima in other settings, I have defined LMATCH as the obvious composition of LAMBDA and MATCH. Seems to work well for me, which is one vote for proposal 1.

[ornamentist]

I've found myself writing package-local macros to try and simplify match constructs with multiple arguments like:

  ;; ...
  (match (Tuple xs ys)
      ((Tuple (Something xs) (Something ys)) (Something (some-function xs ys)))))

Which may reflect my lack of CL and Coalton knowledge more than anything.

[Inc0n]

I was entranced by the cleaness of haskell syntax/language, and inspired to make a defun macro that transform a haskell-like function definition into nested match of a single variable:

(hasklisp:defun fatorial (n acc)
  | 0 acc -> acc
  | 1 acc -> acc
  | n acc -> (fatorial (- n 1) (* n acc)))

Posting this I would like to know also if coalton would like to stay true to the lisp form syntax, or perhaps "absurd" syntax sugar such as this could one day be considered and added?

[stylewarning]

My own personal belief is that as long as they're S-expressions (i.e., no reader macro over-use), it's generally kosher. We have some precedent for "traditionally non-Lispy" constructs, like flattened LET.

[Inc0n]

Perhaps the above would fit better with the following modifications (and also with define now):

(hasklisp:define (factorial n acc)
  (0 acc) -> acc
  (1 acc) -> acc
  (n acc) -> (fatorial (- n 1) (* n acc)))

[stylewarning]

Perhaps even just use :=. I like it!