Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

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: John Max Skaller <skaller@m...>
Subject: 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

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

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

> 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
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,
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper
download Interscript