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

[Fergus Henderson]

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

----------

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?
If so, why did you decide against it?

> + at node Field extraction
> + at subsection Field extraction
> +
> + at example
> + at var{Field}(@var{Term})
> + at end example
> +
> +Each field label @samp{@var{Field}} in a constructor causes generation
> +of a field extraction function @samp{@var{Field}/1}, which takes a data-term
> +of the same type as the constructor and returns the value of the
> +labelled field, failing if the top-level constructor of the argument
> +is not the constructor containing the field.
> +
> +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."

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

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------