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

[Dave Mason <dmason@sarg.Ryerson.CA>]

>>>>> On Thu, 12 Apr 2001 00:34:42 +0900, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> said:

> From: fare@quatramaran.ens.fr (François-René Rideau)
>> You left without discussion the approach suggested by Arturo
>> Borquez, which is quite distinct from that by Chris Hecker: "An
>> unlabeled argument should be labeled with the first available label
>> in the declared type of the function being called."

> I might have worded my classification in this (less understandable
> way all proposals have to choose between two types of unification,
> strictly matching labels or ignoring them.

> You must ignore them to be compatible with classic mode.  You must
> match them strictly to be compatible with label mode (provide
> commutation with any decent semantics).

I understand if you only want to implement one of those 2 choices,
after all, it's your time.

However, if it is a question of what should go into my (and many other
people's) favourite language, I think taking those as the only 2
options is rather restrictive, and there are many other possible ways
to do this.

> So this is just impossible to be compatible with both
> simultaneously.  To some degree you may allow idioms of classic mode
> in label mode (like dropping some labels), but not the other way
> round, and not 100% compatible.

I think you should reconsider the suggestion from Borquez (as
encouraged by Rideau), because I think that it would support something
very close to the best of both world (while remaining completely
backward-compatible with `classic' mode).

> This is the basic reason I didn't try to answer in detail all
> proposals.

I must admit I was rather concerned by the response to Remy where you
said you needed all the parameters available at once.  That is not
functional programming as I know and love it!

> The rule you describe here might also be seen as an alternative to
> label mode (yet incompatible with classic mode). However it is not
> compatible with label mode, semantics are a bit more complex, and
> this idea of choosing label by label whether to write or not sounds
> a bit too laxist to me (not a good reason, but the other two are).

It may not be perfectly compatible with `label' mode, but it looks
pretty darned close (although it wouldn't force as many error messages
as perhaps you want).  And it would be completely compatible with
`classic'.  Are those the ``other two'' you refer to?

The important part to me, is that it would allow me to define labels
on *all* my parameters (rather than having to choose which one is
likely to be most useful to leave off), but only use them at
application if I wanted to, and therefore to be able to use labeled
functions with higher-order functions that use multiple parametered
arguments (like fold), without the ugliness of (visible)
eta-expansion.  (If it does eta-expansion behind the scenes if it was
not the last 2 parameters that I left unnamed, so be it.  Just don't
force me to uglify my code!)

There is a syntax that would allow me to control the use of such
arguments rather nicely, I think.  Assume I have:

f: ~a:int -> ~b:int -> ~c:int -> int

I could use fold like:
	fold (f ~b:4 : ~c ~a) [1;2;3] 17
which would, behind the scenes be turned into, essentially:
	fold (function x -> function y -> f y 4 x) [1;2;3] 17
or:
	fold (f ~b:4) [1;2;3] 17
which becomes:
	fold (function x -> function y -> f x 4 y) [1;2;3] 17
or:
	fold (f 4) [1;2;3] 17
which would be the same as:
	fold (f ~a:4) [1;2;3] 17
which can be logically thought of as:
	fold (function x -> function y -> f 4 x y) [1;2;3] 17
but, of course, requires no such expansion.

This may not be as interesting theoretically as the existing label
mode, but it doesn't look that hard to do, and the unification rules
look fairly easy to state.

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