Browse thread
Re: [Caml-list] Future of labels
-
Yaron M. Minsky
-
Jacques Garrigue
-
Judicael Courant
- Markus Mottl
- kahl@h...
- Chris Hecker
-
Judicael Courant
-
Jacques Garrigue
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Claude Marche <Claude.Marche@l...> |
| Subject: | Re: [Caml-list] Future of labels, and ideas for library labelling |
>>>>> "Judicael" == Judicael Courant <Judicael.Courant@lri.fr> writes:
>> To summarize recent posts by various people, there are two approaches
>> for a universal mode:
>>
>> * Take the label mode as a basis, and split libraries where needed to
>> avoid troubling non-labellers.
>> Labels, when present, are no longer optional.
>>
Judicael> I would vote for this one.
I guess like many people reading this list, I'm very tired with this
thread. I definitely vote for this choice: when a function as been
defined with labels, it has to be called with labelled arguments. Does
it solve all incompatibility problems between classic and label mode ?
If yes, I vote twice!
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.
- Claude
--
| Claude Marché | mailto:Claude.Marche@lri.fr |
| LRI - Bât. 490 | http://www.lri.fr/~marche/ |
| Université de Paris-Sud | phoneto: +33 1 69 15 64 85 |
| F-91405 ORSAY Cedex | faxto: +33 1 69 15 65 86 |
-------------------
To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr