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

[Simon Taylor]

> 
> On 04-Jan-2000, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > +++ reference_manual.texi	2000/01/04 05:27:34
> ...
> > + at item @var{Term} := ^ @var{Field1} ^ ... ^ @var{FieldN}
> > +Unifies @var{Term} with the field of the implicit DCG argument
> > +labelled by @var{Field}. 
> > + at var{Term} must be a valid data-term.
> > + at var{Field1} @dots{} @var{FieldN} must be valid field names.
> > + at xref{Record syntax}.
> 
> What's the rationale for using the symbol `:=' here?
> Normally `:=' is used for destructive assignment.
> But there is nothing in this construct that resembles
> destructive assignment.  I think it would be much
> better to use some other symbol.
> For example, instead of using `:= ^', we could use (a) `=^'
> or (b) `= ^'.
> 
> Another alternative would be (c) to use a reserved symbol,
> e.g. `THIS', to indicate the implicit DCG argument.
> 
> Of these, I think I prefer alternative (b).

I find it slightly clearer to use an asymmetric symbol -- 
with alternative (b) should `^ field1 = Value' be allowed?

I think it might be a bit confusing to use the unification symbol
because with unification you might expect to be able to replace
`X = ^ field1, { Y = functor(Field1) }' with `{ Y = functor(^ field1) }'.

I prefer alternative (a).

> ----------
> 
> Haskell allows the same field name to occur in more than
> one constructor of a given type, so long it has the same
> type in each constructor.  For example (transliterating
> to Mercury syntax), you could write
> 
> 	:- type term
> 		--->	constant(name :: string)
> 		;	functor(name :: string, args :: list(term))
> 		.
> 
> and then the `name/1' function would be defined as if by
> 
> 	:- func name(term) = string.
> 	:- mode name(in) = out is det.
> 	name(constant(Name)) = Name.
> 	name(functor(Name, _Args)) = Name.
> 	
> Did you consider allowing this?

Yes.

> If so, why did you decide against it?

To keep things simple. It can be added later without breaking
anything if we decide it's really useful.

> > +By default, this function has no modes --- the modes are inferred at
> > +each call to the function.
> 
> I suggest adding something like "However, you may explicitly declare
> the modes of this function if you wish.  In that case, the function
> will have only the modes that you declare.".
> or "However, the modes of this function may be explicitly declared,
> in which case it will have only the declared modes."

OK. 

> > +An explicit lambda expression must be used to create a higher-order term
> > +from a field extraction function, unless a mode declaration is supplied.
> 
> I suggest rephrasing that last sentence:
> 
> 	To create a higher-order term from a field extraction function,
> 	an explicit lambda expression must be used, unless there is
> 	a (single) mode declaration for the field extraction function.
> 
> (Otherwise it sounds like every program must use an explicit lambda
> expression...)

OK.

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