[
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: | Markus Mottl <mottl@m...> |
| Subject: | Re: to have labels or not |
> So now, we want something better: a _single_ language, not two variants. I agree that having a single language should be a medium-term goal. > The arguments about the standard library seem to me to be this: some of > the > ocaml (classic) users like myself would prefer to move to the > modern/strict/label > mode and get rid of the classic mode. But we're not willing to do so if > it > clutters our use of the standard library. I also agree here: use of the standard library should not become inconvenient. If this requires to remove labels from part or even all of it - well, then so be it. Though, I wouldn't like seeing them to be removed from the language itself. > I do not feel I gain the real advantage of labels with GUI/PCRE > type libraries _unless_ the labelled optional argument things > commute. I also don't want to clutter use of simple > standard library functions with labels. Optional arguments can also be used to pass the "same" argument in different forms (by using different labels on them), as is the case in the PCRE: you can pass regular expressions as a string, in which case it will be compiled for you, or as a precompiled regular expression, useful if matching happens in a loop. This can be done by having two optional arguments, one overriding the other if present. There is no commuting involved (not necessarily), but this "trick" still gives the user a great deal more of flexibility: he can choose whether he wants the "readable" or "efficient" form without having to memorize more function names. If I had wanted to do something similar with the previous (unlabeled) version, this would have required me to invent a new prefix for the "readable" form of the function and to *double* the number of all access functions for all of the already existing forms, which was already perversly high. With each similar new "feature", the number of special functions grows exponentially - a horror for both the user and the maintainer... > So here's a suggestion. Get rid of classic mode. > But have TWO complete standard libraries: I do not think that this is the way to go: this will just shift the problem of "two styles" from the compiler to the library. > IF -classic or -label is specified on the compiler > command line, one of these open statements is inserted > into each module 'by magic', this is a compatibility hack > for legacy code. But where is the difference then if you still can (have to) specify a flag on the command line to switch between styles? The aim should be to get rid of such a flag and still satisfy all (at least: most of the) users. I really believe it is a good idea to have two modes know, allowing people to adapt to new styles of programming (or not). In any case, more experience among the users will make it easier to take a final decision. Regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl