[m-rev.] field syntax (was: smart recompilation)

[Ralph Becket]

> From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> Sent: 04 July 2001 04:45
> 
> On 03-Jul-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> >
> > Also, if we're preparing to change the field syntax, I'd
> > like to reconsider the field access function transformation.
> > Personally I've found the argument ordering to be problematic
> > when writing higher order code and have not come across any
> > situations where I would have had to worry about taking the
> > address of a multi-mode function etc.  Nor have concerns about
> > referential transparency raised their heads.
> >
> > Anybody else feel similarly?
> 
> I don't understand exactly what you're proposing here;
> could you spell it out in more detail?

Example: I find it's much more common to need to extract values for
random keys in a map than the extract the values for a given key in
an arbitrary map.  That is, thanks to the current argument ordering
whereby Map ^ elem(Key) == elem(Key, Map), I have to write

	MapElem = ( func(Key) = Map ^ elem(Key) ),
	Values  = list__map(MapElem, Keys)

rather than just

	Values = list__map(elem(Map), Keys)

or even

	Values = list__map(Map ^ elem, Keys)

I could write the shorter version if the transformation was
Map ^ elem(Key) == elem(Map, Key).

[While we do have map__lookup/2 which does the trick here,
having two equivalent projection functions seems redundant and
it's a pain when coding up your own ADTs.]

It's a minor point, but it's wound me up more than once.  There was
a big debate on the issue when field accessors were first introduced;
I merely wondered whether, in the light of experience, people felt 
that the motivation for the current argument ordering in the
transformation was still as convincing.

- Ralph
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------