Re: to have labels or not

From: Markus Mottl (mottl@miss.wu-wien.ac.at)
Date: Thu Mar 23 2000 - 04:46:13 MET

  • Next message: Sven LUTHER: "Re: Unsigned integers?"

    > 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
    



    This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 13:59:01 MET