Re: datatype constructor as syntax

20/03/14 12:51, Matthew Fluet wrote:
> On Wed, Mar 19, 2014 at 7:37 PM, Phil Clayton <[email protected]> wrote:
>> 19/03/14 19:16, Matthew Fluet wrote:
>>> On Tue, Dec 31, 2013 at 3:47 AM, Florian Weimer <[email protected]> wrote:
>>>> * Henry Cejtin:
>>>>
>>>>> Sorry,  I  thought  I  was  being  clever,  but  if  you look at Andreas
>>>>> Rossberg's Defects in the Revised Definition of Standard ML
>>>>>       http://www.ps.uni-saarland.de/Publications/documents/Rossberg_DefectsSML.pdf
>>>>> you will see that he points out that rule 126 of the  dynamic  semantics
>>>>> implies  that  this  should really give you a bind exception at runtime.
>>>>> This was fixed (meaning you get the in MLton way back in 2001 to give an
>>>>> error at compile time.
>>>>
>>>> Curiously, the fun-based approach
>>>>
>>>>     datatype mytype = foo | bar of int
>>>>     fun bar _ = ()
>>>>     val bar = 23
>>>>
>>>> still runs without raising an exception when compiled with MLton.
>>>
>>> That seems to be an oversight.
>>
>> Perhaps I missed the point here but I'm hoping that it's intentional
>> that MLton allows the status of a constructor id to be overwritten by a
>> fun binding.
>
> The issue is that the static semantics specified in the Definition
> allows a 'val rec' (and, therefore, a 'fun') declaration to override
> the constructor status of an identifier, but the dynamic semantics of
> a 'val rec' (and, therefore, a 'fun') declaration does not override
> the constructor status, and hence binding attempts to perform a
> pattern match that necessarily fails with a Bind exception.
>
> It seems that most SML implementations resolve this inconsistency by
> adopting a dynamic semantics where a 'val rec' declaration does
> override the constructor status.
>
> MLton, on the other hand, resolves this inconsistency by adopting a
> static semantics where a 'val rec' declaration is not allowed to
> override the constructor status of an identifier.  This was adopted in
> 2004 (https://github.com/MLton/mlton/commit/110d6b6) as part of
> Stephen's implementation of a proper front end.  I looked at the mail
> archive from the time of the commit, but couldn't find any discussion
> as to why the choice was to change the front end, rather than
> documenting a deviation from the Definition with respect to the
> dynamic semantics.

Thanks for the explanation.  Do you have plans to change MLton to align 
'val rec' and 'fun'?  (Changing both to follow the Definition seems 
least useful, in my humble opinion.)

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech