Re: to have labels or not

From: John Max Skaller (skaller@maxtal.com.au)
Date: Sat Mar 25 2000 - 04:57:54 MET

  • Next message: John Max Skaller: "Hashtable iter/remove"

    Jacques Garrigue wrote:
     
    > This is a reasonable argument. However, by discussing with olabl
    > users (many of them being originally ocaml users) I really got the
    > feeling that the fact to have to write labels for standard library
    > functions didn't bother them.

            It bothers me, because it will create a lot of extra clutter,
    and force me to 'fix' thousands of lines of code. I'm having enough
    trouble coping with the weak error messages in classic ocaml,
    without being confused by additional ones.

            I often make systematic changes (replace one type with another),
    and I rely on compiler diagnostics to find all the uses to allow
    me to upgrade the relevant code. This works well in C and C++,
    but not so well in ocaml (for a variety of reasons).

            My small experiment with polymorphic variants sent me
    running for my backup copy. :-(

            [I replaced a large 'type X = | v1 .. | v2 .. ' with three
    smaller (non-polymorphic) variants, and created three polymorphic
    variants each covering two of theses cases. Had this worked,
    it would have greatly improved my code, since many functions
    are only interested in 2/3 of the cases -- the other 1/3 cannot occur
    dynamically, and it is really bad writing default handlers
    like '| _ -> assert false' because this prevents the compiler
    diagnosing missing cases. Anyhow, I couldn't get it to work
    after two days, so I gave up. I couldn't make head or tail
    of the error messages half the time

    FYI: the case involed is a language 'term', of which there are three
    kinds: ones that only exist at compile time and are replaced on
    evaluation (sugary constructions), ones that are the same at
    compile and run time (things like integers), and ones that only
    exist at run-time (like dictionaries represented as hashtables).
    ]

    > So before deciding whether you want to stay classic or go to commuting
    > label mode, you might just give it an (extensive enough) try.

            How? The modes are incompatible.
     
    > > So here's a suggestion. Get rid of classic mode.
    > > But have TWO complete standard libraries:
    > >
    > > module Classic = .. put classic modules here ..
    > > module Olabl = put labelled versions here
    >
    > We thought about that. And even tried it before releasing 2.99.
    > I am the one who pushed against this solution, because I felt this
    > would really cause a community split.

            The community started out split, and has been brought closer together
    by the ocaml/olabl merger. But the community is _still_ split because
    the
    usage of the modes is incompatible: we have two languages and one
    library.
    The way I see it, two libraries and one language reduces the split
    again.
    I do _not_ see this as idea -- OR permanent. But having two libraries
    is a temporary hack to allow a full merger of the languages, and to
    focus
    on an acceptable compromise to get one library.
     
    > The problem is not just the standard library.
    > If you do not have classic mode, then it means that everybody will
    > have to write all labels. If you have a look at LablGL, you will see
    > that I use there plenty of non-optional labels, and very few optional
    > ones. I'm pretty sure people would start asking me to remove them.

            I don't think so. The greatest feeling here is with the
    standard libraries, because we all have a vested interest in
    out current code, and our programming habits.
     
    > The whole point is: the user (not the implementor) should decide.
    > And in practice it is better to decide on a program-wide rather than a
    > per-module basis (as some suggested).

            I don't agree: I do not wish to choose between two 'almost the same'
    languages. But I regularly chose which library components to use
    in an application, so this is just the same choice I usually make.

    > The only weakness of this approach is if you copy some code from a
    > file in classic mode to one in commuting label mode (or reverse).
    > Then you have to add/remove labels by hand. But then this is also a
    > way to understand the code better :-)

            In a production environment, one is NOT interested in
    understanding 'the code', one is trying to USE the code
    WITHOUT understanding it. This is the very point of abstraction
    and information hiding.

            For example, I use Pcre, I do NOT understand the code,
    and I don't want to. I'm too busy to waste time on such details,
    I prefer to trust Markus -- complain if something doesn't work
    as advertised, or ask for help if I don't understand.

            BTW: I'm not claiming two libraries is the right solution
    either. I really don't know. I am glad a first step has been
    made to merge the two systems. Thank you!

    -- 
    John (Max) Skaller, mailto:skaller@maxtal.com.au
    10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
    checkout Vyper http://Vyper.sourceforge.net
    download Interscript http://Interscript.sourceforge.net
    



    This archive was generated by hypermail 2b29 : Mon Mar 27 2000 - 19:28:54 MET DST