[m-dev.] for review: tuples [1]

[Fergus Henderson]

On 02-Aug-2000, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> On Wed, Aug 02, 2000 at 12:00:38PM +1000, Fergus Henderson wrote:
> > One possibility would be to add list-like features for tuples.
> > The type `{ T1 | T2 }' could denote a tuple type whose first
> > element has type T1 and whose remainder has type T2 (which must
> > be a tuple type).
> 
> Hang on.  If you're going to do that, wouldn't you be a lot better off using
> the defn:
> 
> 	:- type (T1,T2) ---> (T1,T2)
> 
> This has several advantages over the {...} notation:
> 
>     1)  No need to introduce Fergus' {T1 | T2} notation:  (T1,T2) covers it
> 
>     2)  Much more orthodox notation mathematically (Using parentheses for
> 	tuples is only a little less common than angle brackets; they're
> 	certainly a *lot* more orthodox than braces).
> 
>     3)  Doesn't take away the orthodox notation for sets.  It would be nice to
>         reserve braces for sets at some later time.
> 
> I can only see one disadvantage:  for triples and above, the representation is
> inefficient

Indeed: what you get is not a flat tuple, but instead a list-like
nested structure.  Because this can be a fair bit less efficient, and
because the alternative of using a single-constructor type is quite
easy, programmers would probably more often use a single-constructor type.
In the end you put programmers in the unfortunate position of having
to choose between elegance and efficiency.

> This could be fixed by implementing structure inlining of
> single-constructor types.

Well, that kind of optimization is not the kind of thing you can
rely on, so if the programmer wants guaranteed efficiency, they
would still need to use a single-constructor type.

> Of course, this would have benefits in many
> other situations, as well.  Is there some reason that this is a more
> difficult optimization than it would seem?

Yes.  There are a couple.  One is that doing structure inlining of
single-constructor types would mean that the implementation of
std_util__arg, store__arg_ref and the like would be more difficult.
The other is the one that Simon mentioned: given a predicate which
returns a tuple, the compiler can't tell whether this optimization
will be of benefit without looking at the caller, since if the caller
does things like decomposing the tuple as if it were a list and
passing the tail on to another predicate, then that "optimization"
would actually make things worse rather than better.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------