Joe English:
> (Am I the only one who's never been bitten by the MR restriction?)

If one always uses type sigs, or never/rarely uses compositional/
combinator style function definitions, it's much less likely to
crop up.


> How about leaving the 'a = b' binding form as it is,
> (monomorphism restriction and all) and using 'a = ~ b'
> to indicate call-by-name.  '~' is already a reserved
> symbol, and it can't currently appear on the RHS of
> a binding, so this new syntax would't break any existing
> programs.

I like that much less (though I admit I wasn't all that smitten by John
exact notation, either).  I like it less because it looks (even) worse,
IM(humble-or-otherwise)O, and more to the point because I consider it
(still) to be the wrong 'default'.  The symbol ':=' in John proposal can
be explained as 'monotypically bind a CAF', whereas Joe's notation
preserves the existing, ugly distinction between simple pattern bindings
and function pattern bindings.  That is, in other words, that
definitions don't eta-convert.


> This way call-by-need remains the default, and compilers
> will still signal an error if the programmer accidentally
> bumps into the MR.

This way bizarre type errors remain the default, and compilers
will signal an error _somewhere else_ in the program when you
bump into the MR, if my experience is anything to go by.


> For people reading the code,
> a ~ on the RHS of a binding is a signal that something
> out-of-the-ordinary is going on operationally, the same as
> when it appears on the LHS.

I dispute that there's anything 'operationally out-of-the-ordinary'
about an overloaded function definition, which is almost invariably
what the MR is (silently) complaining at me for doing when I fall
over it.  It's only out-of-the-ordinary if you were depending on
it being operationally a CAF, so having some sort of special CAF
syntax seems reasonable to me.  Certainly I will happily stipulate
that ':=' may not be the definitive word on the best such syntax
(give us back our 11 days -- err, I mean, our constructor operator
symbol namespace!).

Slan libh,
Alex.



Reply via email to