[m-dev.] An optimization worth doing.

Lee Naish lee at cs.mu.oz.au
Mon Feb 10 17:31:24 AEDT 1997

In message <199702100516.QAA21926 at mundook.cs.mu.OZ.AU> I wrote:
>:- type my23tree1 --->
>        nil;
>        non_empty23t(my23tree1, data, maybe_empty23tree).
>:- type maybe_empty23tree --->
>	yes_its_empty;

Should be

>	no_its_not_empty(my23tree1, data, my23tree1).

As for whether its a Mercury defficiency or a Mercury implementation
defficiency, Fergus might be right but I suspect some changes to the
Mercury type system would be needed to get the additional
expressiveness.  Pointers at the implementation level tend to be
reflected by something at the language level (even if it is more tame).

Basically what we are talking about is "inlining" type definitions to
avoid pointers.  To me this seems more problematic than inlining
procedures but perhaps its because I'm more open to declarative views of
code than declarative views of data (ie, values rather than a data
structures).  I've certainly be viewing things from a very "data
structures" perspective today.


More information about the developers mailing list