Re: datatype constructor as syntax

On Sat, Mar 22, 2014 at 5:52 PM, Phil Clayton <[email protected]> wrote:
> 20/03/14 13:09, Andreas Rossberg wrote:
>> While I also appreciate the possibility of playing tricks like these, I
>> don't think it's a good idea to rebind an identifier as fundamental as
>> NONE in real code, no matter how easy or hard it is.
>
> Sure - I would never advocate this in hand-written SML!  The situation
> arises in bindings to an existing library, where the existing names and
> the SML abstraction result in a value called 'NONE', for example:
>
> https://developer.gnome.org/gtk3/3.10/gtk3-Standard-Enumerations.html#GtkJunctionSides
>
>    signature GTK_JUNCTION_SIDES =
>      sig
>        eqtype t
>        include BIT_FLAGS where type flags = t
>        val NONE : t               <----------------------
>        val CORNERTOPLEFT : t
>        val CORNERTOPRIGHT : t
>        val CORNERBOTTOMLEFT : t
>        val CORNERBOTTOMRIGHT : t
>        val TOP : t
>        val BOTTOM : t
>        val LEFT : t
>        val RIGHT : t
>        ...
>      end
>
> The SML trickery is hidden inside the bindings code so I don't see any
> detraction from a user perspective.  The alternative would be a
> different name e.g. NONE', which has obvious detractions, e.g. doesn't
> match existing documentation and will catch programmers out.

That seems to be a reasonable use case.  I would imagine that one
would normally access these ids via a long name (e.g.,
JunctionSides.NONE), so there is little chance of confusion with
top-level constructors of the same name.

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