[m-dev.] Syntactic sugar for functor matching

[Fergus Henderson]

On 01-Nov-2001, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Thu, Nov 01, 2001 at 03:15:12PM +1100, Michael Day wrote:
> > 
> > > Solving the problem Fergus is referring to would mean Mercury would have
> > > to forbid a type having two constructors with the same name (and different
> > > arities).  At least as far as I can see allowing a syntax that doesn't
> > > specify the arity but still uniquely determines a constructor seems to mean
> > > that the functor name alone must determine the constructor.  But if you're
> > > willing to accept that, here's a suggestion.
> > 
> > Presumably types could still have two constructors with the same name but
> > different arity as long as neither of them were used in the pattern
> > matching you've described (if aforementioned pattern matching is smart
> > enough, anyway).
> 
> You could be sophisticated in where you draw the line, such as based on the
> names or types of arguments,

Yes, that would be the natural place to draw the line, IMHO.
It would match the way Mercury handles ambiguity resolution
for other forms of overloading.

Fortunately in this case we can both retain backwards compatibility
and keep the design consistent.

> but there's no way you can unambiguously write
> foo[] when the type has two constructors named foo.

True, but in such cases you can use different syntax
to resolve the ambiguity, e.g. `foo[name1=_]' to resove it
using a field name, or `foo(_, _)' to resolve it based on arity.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  | "... it seems to me that 15 years of
The University of Melbourne         | email is plenty for one lifetime."
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- Prof. Donald E. Knuth
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------