[m-dev.] manifest sets

[Peter Schachte]

On Wed, Aug 16, 2000 at 04:28:32PM +1000, Fergus Henderson wrote:
> Your code allows `{1, 2}', but it doesn't allow `{1}' or `{}'.
> If we're going to support set notation, we should allow the latter to.

True, but easily fixed.

> Also, the overloading that this technique involves is likely to lead
> to some potentially confusing error messages, e.g. for simple code such
> as
> 
> 	main --> print({1,2}).
> 
> It's not clear that advantage of the the syntactic convenience is
> worth the confusion that such problems will cause.

The syntactic convenience is greater than it might seem at first.  Being
able to write proper looking manifest set constants would be even more
useful when debugging than when coding.  It would also mean that it would
make sense to print sets out using this syntax, too.  This would make sets
more pleasant to work with altogether.

There are two problems, though.  Firstly, the overloading problem.  Leaving
the tuple syntax out of it, there's still the problem that {1,2} could be
either the desired set of ints, or a singleton set of internal_sets.  This
could possibly be worked around by having a type class of things that could
be set elements, and carefully leave internal_set out of that type class.

But the bigger problem is that if you start printing sets using proper set
notation, you'd have to make sure that any code that reads terms that may
contain sets would handle (and evaluate) function invocations in the input.
Does the debugger do this?  Any code that calls io.read/3 would get into
trouble.  

Of course, Mercury already has this problem.  You can write
list_to_set([...]) in a source file that will be handled by the compiler,
but if you want to put a set in a text file that will be handled by read,
you need to know to write it as a sorted list.  And if someone decides to
change the set module to use another implementation (after all, that's the
point of an ADT!) you're hosed.  Manifest constants really are a problem.  I
guess this is another argument for weakening or removing the distinction
between constructors and functions.

-- 
Peter Schachte <schachte at cs.mu.OZ.AU>  Predestination was doomed from the
http://www.cs.mu.oz.au/~schachte/      start. 
Phone:  +61 3 8344 9166                
Fax:    +61 3 9348 1184                
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------