Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: to have labels or not
[ Home ] [ Index: by date | by threads ]
[ Search: ]

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

Markus Mottl

Markus Mottl,,