[m-dev.] for review: record syntax [2]

[Peter Schachte]

> > > + at node Record syntax
> > > + at subsection Record syntax
> > 
> > I found the division of material between this section and the Field
> > access functions section a bit confusing.  From the names, I'd expect
> > this section to just cover adding labels to type declarations, and the
> > fact that doing so generates a couple of functions for you, and the
> > other section to cover use of those functions.
> 
> What name would you suggest for the "Record syntax" section?

Actually, I think the name is pretty good.  Maybe "Record declaration
syntax" might be a bit better.  It's actually the division of material
that I find confusing.  To me, there are really three parts to this
facility: the ability to label term "fields" in type decls (and get
accessor and setter functions automatically generated); the ^ notation
for function application which happens to be convenient for field
access (but could be useful for other things); and the := syntactic
sugar for transforming calls to accessors into calls to the
corresponding setters.  I think probably the best way to present this
would be to have a section or subsection in the type chapter (as you
have) explaining the labeling of fields in a type declaration, and a
couple of sections/subsections in the chapter on functions discussing
the ^ and := notations.  Of course, each of these would reference the
other two.  Since it comes first, it probably makes sense for the
record declaration section to give a brief illustrative example of the
^ and := notation, but not to go into detail about them.

Really, these are three independent, orthogonal features that happen
to work nicely together.  You could use field labels in type
declarations, but just use ordinary functional notation for accessors.
You could use ^ notation for function application, without using
record declaration syntax, because it puts the argument first and
function second (like unix pipes).  You could use := notation for
arbitrary function applications using ordinary functional syntax,
because it provides a nice syntactic sugar for a nice, consistent
scheme relating a function to its "setter" (cf SETF in common lisp).

> > One detail could use clarification:  Can you write
> > 
> > 	Foo ^ bar(3)
> > 
> > and have that turn into
> > 
> > 	bar(3, Foo)?
> 
> > Also, how about
> > 
> >       Accessor = fieldname,
> >       Variable = Foo ^ Accessor?
> 
> Allowing this would make it difficult to generate field selectors inline.
> The documentation now makes it clear that the field specifiers
> must be function names.

Couldn't you just do this by having the automatically generated
accessor and setter functions implicitly given an inline pragma?  This
should cover the first example.  Of course, the second example has
arbitrarily complex variations that make it impossible to inline in
general, but even if it isn't inlined, it should still work correctly.
And treating the automatically-generated accessors/setters as (pragma
inline) functions would allow you to use them as arguments to higher
order functions/predicates.  The downside is that it'll increase code
size, since 2 real functions will be compiled for each labeled field.
The solution to this is a compiler pass removing unused procs from the
module (where being exported or used in a closure counts as being
used).  This isn't really necessary right now, and would be a
generally useful feature anyway.

> > I don't really see the value in this 'builtin ...' mechanism.
> > Wouldn't it be just as simple for the user to give the field a
> > different name and define the functions using that name?  That would
> > avoid having to explain all this (and the confusion of your earlier
> > example showing field1/1, field2/1, 'field1:='/1, and 'field2:='/1
> > functions being generated, but no 'builtin ...' versions of these,
> > which I would have expected).
> 
> You can think of the 'builtin ...' mechanism as just enforcing a convention
> on the name of the renamed field, rather than making the user come up
> with another name.

What I'm questioning is the value to the user of this enforcement
relative to the complication of having to explain it.  On one hand,
you're giving the user a nice convention, but on the other hand you're
complicating the system and its explanation.  Since the user can quite
easily either use a different field name, or no name and use pattern
matching (the old-fashioned way) to define his setter, it seems to me
this feature doesn't bring enough benefit to the user to warrant the
confusion.

-- 
Peter Schachte                     The end of the human race will be that it
mailto:schachte at cs.mu.OZ.AU        will eventually die of civilization.
http://www.cs.mu.oz.au/~schachte/      -- Ralph Waldo Emerson 
PGP: finger schachte at 128.250.37.3  
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------