Re: [Caml-list] Future of labels, and ideas for library labelling

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

Bonjour Claude,

I'm sorry for taking so much bandwidth with this discussion. Yet I do
not see where it can be done, other than the caml-list.
As I put in my disclaimer, if you're not interested, you can just
discard on the title. Not the best solution, but...

> I see a strong analogy between unlabelled/labelled arguments of
> functions and tuples/records types: both are defining product types,
> records are usually useful when there are a large numbers of
> components, and when you do not want to remember the order of
> them. And moreover the { r with ... } construct allows some kind of
> default values in records. But could we imagine any useful application
> to a record-like type where a record contains both labelled and
> non-labelled fields?  I don't think so.

Well, psi-terms in Life (developped at DEC PRL 10 years ago) had such
a feature, and that's where the labels come from. Since they were also
used for data, I would suppose people also used this syntax mixing
labelled and unlabelled fields in records.

A good exemple is a syntax tree: nodes are represented by records,
where one of the fields is a variant giving the type of the node, and
eventually the children. Other fields describe various features of
this node, like position, type, etc...
It seems to me that this main field could very well do without a field
name: in Caml's source it is called desc for description (I think),
but I'm not sure everybody knows what desc stands for...

So, yes, mixing labels and unlabelled fields in a record may be
perfectly meaningful. It is just that most languages do not provide
such a feature. Not that I mean that this feature is really needed:
you have much less record descriptions in a program than function
calls.

Cheers,

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr