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

[Simon Taylor]

> 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.

Which chapter on functions?

The descriptions of `^' and `:=' definitely belong with the descriptions
of the syntax of the other types of data-terms -- that information should
not be scattered through the reference manual.

I also don't want to emphasise the fact that the `^' syntax is
the same as function application, because users might be confused
by the examples below not working.

> > > 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.

Field access functions are expanded before mode analysis. This is so
we don't have to work out how to mode them. Not expanding the bodies
would also stop switch detection finding switches where the arms
of a disjunction select or update fields of different constructors
of a discrimated union.

> And treating the automatically-generated accessors/setters as (pragma
> inline) functions would allow you to use them as arguments to higher
> order functions/predicates.

They don't have any modes declared, so you need an explicit lambda
expression anyway. To fix that, it might be useful to have default modes
for higher-order functions -- if a function does not have exactly one
mode, higher-order terms constructed using that function would have
mode `f(in, ...) = out is det'. This would allow passing automatically
generated field access functions and constructors as higher-order terms.

> 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.

We already have that -- compiler/dead_proc_elim.m.

> > 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.

I really don't think it's that complicated or confusing.

Simon.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------