Re: to have labels or not

From: John Max Skaller (skaller@maxtal.com.au)
Date: Tue Apr 04 2000 - 15:04:33 MET DST

  • Next message: Brian Rogoff: "Re: to have labels or not"

    Jacques Garrigue wrote:

    > We could discuss very long on the two library vs. two mode
    > approaches, without reaching a conclusion. Both have their own
    > merits.
    >
    > However an important point in this choice is just practical
    > implementation problems:
    >
    > * using the current OCaml techniques, like MD5 identification of module
    > interfaces, linking of codes based on different libraries is not
    > possible. Moreover, making it possible without code duplication is
    > not trivial.

            My specification does not create any problems. It cannot,
    it requires the client to choose the libraries _exactly_ as they do now,
    by 'open'ing the required modules. The compiler switch hack is _exactly_
    like inserting magical 'open' statements at the beginning of each source
    file.

            Therefore, this argument is not effective against my two libraries
    proposal, although it may knock out others using a different selection
    mechanism.

    > * maintaining concurently two different standard libraries would be a
    > pain. It was already with olabl. And what about Str, Dbm or Unix,
    > which can naturally profit from similar labellings.

            This argument cannot be knocked out, but I can knock
    its effectiveness down to a quite tolerable minimum using a
    powerful tool you've heard of before, namely interscript, my literate
    programming tool.

            Using interscript, you create a _single_ body of 'code' which is
    used to _generate_ the two libraries .. in such a way they're quite easy
    to
    keep synchronised .. and documented .. since the code .. and
    documentation ..
    is generated from a single specification.
     
    > * on the other hand, the two mode scheme only requires a few lines
    > in the compiler. Basically switching on or off some checks, and a
    > slightly different treatment of function application.

            This is a strong argument to retain the current system until
    a _clearly_ superior proposal surfaces. I'd agree that is not the case.
    Yet :-)
     
    > So I believe that having 2 modes was a rather natural first choice.
    > Now, if we realize after some time that this was not a good choice, it
    > will still be possible to change it for another approach. Of course
    > with a transition as painless as possible, and with the core language
    > preserved.

            Agreed.
     
    > Keep cool, we are not talking about divorce :-)

    > If we let conservatism decide on all subjects, there is no possible
    > progress. Are we going to have people to vote about what scientific
    > theories they like, or (more accurate) which novel writers should be
    > published and which not?

    > Let's leave people more time to decide what they want for themselves.
    > Then at that point there may be a better solution, which an early
    > decision would not have discovered.

            I agree. But are we not covering the obvious .. and not so obvious ..
    nearby territory so as to ascertain at least that there is not an
    immediately
    accessible superior solution? Isn't this also not good science?

            Indeed, if this discussion were NOT occurring one might judge
    ocaml a failure, for failing to inspire creative thought. But no,
    it has succeeded :-)
     

    -- 
    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 : Thu Apr 06 2000 - 15:28:48 MET DST