to have labels or not

to have labels or not

[Jan Brosius]

Hi,

I am looking around to have a good , free and very easy language , portable
and so on, producing fast code. Objective Caml was and still is for me a
serious candidate among the many free portable languages on the net. I
realise that it is not up to me to enforce a decision . I also realize that
credits always should be given to the implementors and France's research
institute INRIA.

My personal choice is not to use labels at all because it makes the readable
code  too big, it is better I think  to use meaningful words and within
comments to clarify the types of the functions.

I think I would never use the "label on " option.

function x -> ..   could be shortened  by : \x ->.....  I think and the use
of [`a] instead of  `a list and the use of  list comprensions as in Haskell
could shorten the readable code and maintain readability.

friendly et amicalement

Jan Brosius

Re: to have labels or not

[Brian Rogoff]

On Fri, 17 Mar 2000, Jan Brosius wrote:
> My personal choice is not to use labels at all because it makes the readable
> code  too big, it is better I think  to use meaningful words and within
> comments to clarify the types of the functions.

I don't believe this argument. I got the labeled and nonlabeled 
versions of Markus Mottl's PCRE library and looked at their respective 
sizes; the labeled versions had significantly less code (10-20% I think) 
than the unlabeled. It also dealt better with that name mess caused by 
optional parameters in the old PCRE interface causing it to read better 
IMO. 

I agree that labels seem heavy for some uses, and depending on your coding
style they may not be for you.

Making the labels single letter names seems like a bad idea. How do we
distinguish "file" and "function" for example? I like "fn" but "func" is 
OK too. 

I like ":", and I'm not sure I want to give up $, %, or & for labels. Its 
nice to be able to use these as infixes, whether or not infixes are good
for programming-in-the-large. 

I also agree that the error messages are difficult, but that's orthogonal
to labels, call it the "price of type inference".

Whatever happened to those other O'Labl features that haven't made it into 
OCaml yet? In particular, polymorphic methods.

> I think I would never use the "label on " option.

Never say never.

> function x -> ..   could be shortened  by : \x ->.....  I think and the use
> of [`a] instead of  `a list and the use of  list comprensions as in Haskell
> could shorten the readable code and maintain readability.

Actually `a is another issue, and elsewhere it was rightly suggested that
it be made illegal ;-). OK, seriously, you can use CamlP4 to get
comprehension syntax, and but it doesn't work yet with labels so you
won't have a chance to try them if you need P4.

-- Brian

Re: to have labels or not

[Markus Mottl]

> I don't believe this argument. I got the labeled and nonlabeled 
> versions of Markus Mottl's PCRE library and looked at their respective 
> sizes; the labeled versions had significantly less code (10-20% I think) 
> than the unlabeled. It also dealt better with that name mess caused by 
> optional parameters in the old PCRE interface causing it to read better 
> IMO. 

The PCRE library was my first "guinea pig" for using labels - and I think
that it was a fairly successful experiment. At least in my opinion (and
Brian's above) it made the code much more transparent - not only to me as
developer but especially to the users.

I think that there are some specific domains where labels are really most
helpful: applications that can be heavily parameterized clearly benefit
from both default arguments (makes function application much less painful)
and label names (makes use of functions with fat interfaces much more
understandable).

It seems obvious to me that GUI-libraries (though, I don't know much about
GUI-programming) and many others that are tailored for a specific purpose
(e.g. string matching) belong into this domain.

On the other hand, I have to admit that I never use labels with the
standard library. This may be partly due to accustomization to "classic
style", but definitely also, because the standard library is not
"specialized" enough (it wouldn't be "standard" then): there are only very
few functions that take numerous "flags" and "options". The "implicitely
agreed on" order of parameters seems to be clear enough to me.

Additionally, I also find labels a bit cumbersome to use with higher-order
functions. That's why I generally prefer "classic mode" over "label mode".


Since there were some voices that nearly seemed to ask for taking out
labels as a whole, I wonder what alternatives there are for, e.g.,
implementing optional arguments, which I consider as a very big "complexity
saver".

I have experimented a bit now with other ways, but haven't found anything
only closely as convenient as "labels" to do it. I have tried objects
(painraiser for the developer and also a bit slow due to dispatch for each
method call to change "parameters") and also functions with lists of
parameters, where the parameters are polymorphic variants (no need to
define an extra type).  The latter also requires some amount of masochism
on the side of the developer and application is still noticably slower.

I also tried to find other additions to the language that fit better to the
"core", but whenever I wanted to refine an idea (e.g. something similar to
records that allow default values), it "converged" towards labels...


It is fully understandable that many people are happy with the core
language + module language alone and want it to stay untouched. When I
started using OCaml (having used C++ before), I knew nothing about
functional programming and came up with stupid questions like "why don't
you implement the standard library using objects?". Thanks to this mailing
list and this wonderful language, my point of view underwent a dramatic
shift (also raising my interest in theory to a level which made me take a
course on formal semantics *voluntarily* (!) ;-)

But what I also like about this language is that it is a dynamic process:
it does not stand still! (SML looks like a boring snail in comparison).
And somehow magically, neither the "OO"-addition nor the "label"-addition
seem to require any "incompatible" change to the core.

So I really do not understand the point of the quarrel on labels here -
whoever needs them (and wherever) can use them, but nobody is forced to do
so!  Though I avoid them with the standard library, I do not see where
anybody could be harmed by them. I guess the growing heat in this thread is
mostly due to irrational fears that somebody might enforce labels in the
default mode, which, I think (and hope ;-), will never happen...

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: to have labels or not

[Max Skaller]

Markus Mottl wrote:

> So I really do not understand the point of the quarrel on labels here -

There's no quarrel. Instead it is 'give people an inch and they want a
mile'.

Instead of two languages, ocaml and olabl, we now have one language with
two
modes. This is much better for the compiler developers, and classic mode
ocaml users have some benefits, but the olabl system is somewhat
compromised.
So now, we want something better: a _single_ language, not two variants.

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 hope this represents the reason for the 'arguments' here, especially
ones for removing labels from the standard library (or, keeping the 
old unlabelled one).

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.


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

and now we can choose libraries in the usual way
with 

	open Classic

or

	open Olabl

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.

Now, we have two libraries, but one language. This is not ideal,
but it is better, because now we can ague about how to merge
the libraries, and because libraries are generally under _user_ control,
whereas compilers are not.

-- 
John (Max) Skaller at OTT [Open Telecommications Ltd]
mailto:maxs@in.ot.com.au      -- at work
mailto:skaller@maxtal.com.au  -- at home

Re: to have labels or not

[Markus Mottl]

> 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

Re: to have labels or not

[Max Skaller]

Markus Mottl wrote:

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

	Yes.
 
> > 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? 

	You don't have to. This is a compability hack.
There's only one language.

> The aim should be to get rid
> of such a flag and still satisfy all (at least: most of the) users

	The hack remains until everyone updates their code
to select the desired libraries (which now have new names).
This can be done by adding one line to every ml file.

-- 
John (Max) Skaller at OTT [Open Telecommications Ltd]
mailto:maxs@in.ot.com.au      -- at work
mailto:skaller@maxtal.com.au  -- at home

Re: to have labels or not

[Jacques Garrigue]

From: Max Skaller <maxs@in.ot.com.au>

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

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. I wouldn't be honest if I don't admit
that there are some exceptions, but then everybody cannot agree on
everything. And olabl didn't provide anything similar to classic mode,
just a raw compatibility mode in which you couldn't use optionals at
all.

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

By the way, it seems that there will be less labels in the standard
library in 3.00.

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

Here is probably the biggest misunderstanding.
In classic mode, optional arguments _do commute_.
Only non-optional and unlabelled ones do not.
And I would say that for most people (at least those with a pure ocaml
background), the only commutations that matter are those between
optional arguments.

Remark for instance that Markus Mottl himself explained that he was
using only classic mode.

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

On the contrary, if you have classic mode, even classic mode users can
add documenting labels to their interfaces.  And then commuting label
mode users can use these labels to pass arguments in the order they
prefer.
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).

In extreme cases where you want to mix both modes in the same program,
you can do it on a per-file basis.  This is not encouraged, but there
are well-defined semantics as long as you write a .mli file (or check
types in the .cmi file).  I really think that being able to switch in
the middle of a file would be dangerous.  I'm already sometimes
confused by such uses of "open".

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 :-)
It might also be possible to develop a tool to do that semi-
automatically. In fact Jun Furuse has been asking for it for a long
time, but I think he is big enough to be able to do it himself :-)

Best regards,

Jacques

Re: to have labels or not

[Markus Mottl]

> Remark for instance that Markus Mottl himself explained that he was
> using only classic mode.

Currently ;-)

I'll see whether commuting arguments is sufficient enough an incentive to
switch modes: but what concerns the problem with HOFs, there should really
be a solution - at least what concerns the standard library.

> I really think that being able to switch in
> the middle of a file would be dangerous.  I'm already sometimes
> confused by such uses of "open".

I agree: "open" is potentially dangerous. It is not only confusing at
times, it can even break modules (e.g. if you add functions to one module
which shadow definitions in another module).

Best regards,
Markus

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: to have labels or not

[John Max Skaller]

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

labels, Hash.create

[Julian Assange]

In regards to backwards compatability, ocaml2.99+13 frequently refused
to compile many 3rd party sources (compiled without -modern) which
use:

        Hash.create n

instead of

        Hash.create size:n
        

Re: to have labels or not

[Julian Assange]

Markus Mottl <mottl@miss.wu-wien.ac.at> writes:

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

Welcome to dynamic lisp.

Cheers,
Julian.

Re: to have labels or not

[Brian Rogoff]

On Sat, 25 Mar 2000, John Max Skaller wrote:
> Jacques Garrigue wrote:
> > > 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.

I agree with John Skaller on this. Two libraries seems like a better
compromise than two modes. There is also some precedent here in that 
the standard libraries were never "OO-ized" after an object system was 
added to Caml. 

There just doesn't seem to be a good solution to this problem, i.e., one
which will leave everyone happy. This is the human engineering part of
programming language design, and since it appears a lot of Caml programmers 
find labels too heavy for their programming style I think we should go
with the rule "When in doubt, leave it out". Out of the standard library
that is. I'm not happy with this, as I prefer the labeled style, but it 
appears that the community is already somewhat split. 

Of course, some people may complain (as Jacques suggested) about the
labels in certain libraries infecting their code if modern/labeled mode
became the only mode but I think that's a minor problem that can be solved 
by those people by writing wrappers.

> 	BTW: I'm not claiming two libraries is the right solution 
> either. I really don't know. 

Yes, it's certainly not a solution that makes you slap your head and go 
"Why didn't I think of that?" but it seems to be an improvement. 

-- Brian

Re: to have labels or not

[John Max Skaller]

Brian Rogoff wrote:
> There just doesn't seem to be a good solution to this problem, i.e., one
> which will leave everyone happy. 


	Never say die -- see Christophe Raffalli's posting.
This is looking promising to me. The idea that labels can be
optional on use provided they're mandatory on definition
seems exactly the right balance to me.

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

Re: to have labels or not

[Jacques Garrigue]

From: Brian Rogoff <bpr@best.com>

> I agree with John Skaller on this. Two libraries seems like a better
> compromise than two modes. There is also some precedent here in that 
> the standard libraries were never "OO-ized" after an object system was 
> added to Caml. 

Finding a mode which would allow OO-izing the standard library while
keeping backward compatibility would be a nice challenge :-)

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

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

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.

> There just doesn't seem to be a good solution to this problem, i.e., one
> which will leave everyone happy. This is the human engineering part of
> programming language design, and since it appears a lot of Caml programmers 
> find labels too heavy for their programming style I think we should go
> with the rule "When in doubt, leave it out". Out of the standard library
> that is. I'm not happy with this, as I prefer the labeled style, but it 
> appears that the community is already somewhat split. 

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.

Best regards,

Jacques

P.S.
If I remember correctly, you asked a while ago about what would happen
of olabl polymorphic methods.
In fact, there is no progress since last Christmas, and I still view
it the same way. When 3.00 is released, I may start writing a
quick patch based on olabl code. If after a while I can come out with
something stable enough and that would not slow down the compiler, I
think there would be no specific problem in including it in the main
compiler. But I have no idea of when.
For the time being, either you have to stick to olabl 2.04, or find a
workaround without polymorphic methods.  My experience is that for
most non-theoretical uses there are workarounds.

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

Re: to have labels or not

[John Max Skaller]

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

Re: to have labels or not

[Brian Rogoff]

On Tue, 4 Apr 2000, Jacques Garrigue wrote:
> From: Brian Rogoff <bpr@best.com>
>
> 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.

John Skaller already answered your points, and anyways since having two
libraries is in no way an elegant solution I'll leave it alone. I still 
think that having two modes makes it harder to explain OCaml and much 
harder for me to promote it in industry to my colleagues, which is my main 
concern. 
 
> > There just doesn't seem to be a good solution to this problem, i.e., one
> > which will leave everyone happy. This is the human engineering part of
> > programming language design, and since it appears a lot of Caml programmers 
> > find labels too heavy for their programming style I think we should go
> > with the rule "When in doubt, leave it out". Out of the standard library
> > that is. I'm not happy with this, as I prefer the labeled style, but it 
> > appears that the community is already somewhat split. 
> 
> Keep cool, we are not talking about divorce :-)

I'm certainly trying to tread carefully, since I've noticed that this
topic is rather inflammatory. Hopefully I wrote nothing offensive and if 
I did I apologize. 

> 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?

Sure, but programming language design is unlike physics in that there is 
a strong human component which should not be suppressed. That's what I 
mean by "human engineering". And programming languages are like novels in that
unpopular writers will have a harder time getting published and read than 
popular ones, so, in a sense, we do get to vote on who gets published, and 
more to the point, on which programming languages gain acceptance. 

It's also clear to me that there is rarely a unique solution to the
problems raised by human engineering issues; witness how some large set
of programmers really like indentation that matters (Haskell,Clean,
Python, ...) while some hate it, and others can go either way.

I should note that most functional programming languages are designed 
by people with a strong academic/theoretical bent, rather than an industrial 
bent, and so issues like the type system get a lot more attention IMO than 
human engineering issues. I think the Modula-3 book by Nelson had a nice 
section on the language design with the different types of designer given 
colorful names like "Lambdaman", "Hackwell", etc. FPs appear to be designed by 
entire teams of "Lambdamen". (OK, perhaps I'm being a little bit provocative 
here ;-)

> P.S.
> If I remember correctly, you asked a while ago about what would happen
> of olabl polymorphic methods.
> In fact, there is no progress since last Christmas, and I still view
> it the same way. When 3.00 is released, I may start writing a
> quick patch based on olabl code. If after a while I can come out with
> something stable enough and that would not slow down the compiler, I
> think there would be no specific problem in including it in the main
> compiler. But I have no idea of when.
> For the time being, either you have to stick to olabl 2.04, or find a
> workaround without polymorphic methods.  My experience is that for
> most non-theoretical uses there are workarounds.

Yes, that's my experience too with polymorphic methods. Still, I hope the
OOP capabilities continue to expand, I've recently been looking at some
problems where Eiffel style multiple inheritance with feature replication
and renaming work nicely and the OCaml workarounds don't seem as
nice. Hopefully Didier and Jerome are hard at work on it (and didn't take
my jab at type theorists too seriously ;-).

-- Brian

Control inversion

[John Max Skaller]

Given a 'functional/procedural' program which does blocking read
operations,
usually modelled by threading constructions, can we transform this
program into one which operates entirely synchronously using
callbacks from a message dispatcher (where the messages are the
same data that the blocking read would have fetched?

I call this process 'control inversion', because it turns master into
slave, and vice versa: the read 'subroutine' called by the master
algorithm, is turned inside out so that the code is executed
by returning control, and then continuing via a callback (making
the code a slave of the dispatcher).

The requirements for control inversion are to save the state of the
environment and point of control, and to restore the state, modified
by the presence of the 'read' message, at the next point of control.
With 'heavyweight' threads, function programs using the machine stack
are control inverted by operating system level stack/register saving.

With (ultra) lightweight threads, we cannot use the machine stack,
except temporarily, so we must maintain a 'stack' manually,
which is difficult to implement .. by hand. But it should not be so hard
to add 'control inversion' to a bytecode machine.
This has been done for Python (by Chritian Tismer, called Stackless
Python).
But it should also be possible for generated code.

I have a clue that for Haskell, the notion of 'arrows' was invented
to replace monads (these arrows correspond to arrows of categories)
for just this purpose (the application here was thousands of
concurrent interactive web sessions, where existing technology
requires 'recording' the state between interactions in an extremely
clubsy ad hoc (usually perlish) way. My application is different,
but the requirements seem the same.

I'm currently using ocaml to implement a simplistic language
which provides 'automatic' control inversion (allowing programmers
to write threaded programs instead of event driven ones).
Unfortunately, the technique is to generate C++ code.

I'd be very interested to hear more from those that know more about
the inner workings of ocaml, whether there is a possible 'native'
solution to this problem. I imagine this would require language
constructions to specify threads (rather than just a library
function call/calls).

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

Re: to have labels or not

[Pierre Weis]

> I should note that most functional programming languages are
> designed by people with a strong academic/theoretical bent, rather
> than an industrial bent, and so issues like the type system get a
> lot more attention IMO than human engineering issues. I think the
> Modula-3 book by Nelson had a nice section on the language design
> with the different types of designer given colorful names like
> "Lambdaman", "Hackwell", etc. FPs appear to be designed by entire
> teams of "Lambdamen". (OK, perhaps I'm being a little bit
> provocative here ;-)

You certainly are provocative, as far as the Caml team is concerned:
we consistently insisted on practicability and usability of the
language, writing theoretical articles on better handling of
side-effects features, better design of modules to allow separate
compilation, better compilation of floating point numbers and
operations, etc; and then we implemented all those nice ideas into
fairly usable compilers. Last but not least ``concession'' to
praticability: this entire set of new basic types and operations for
integers and big arrays...

Best regards,
-- 
Pierre Weis

INRIA, Projet Cristal, http://pauillac.inria.fr/~weis

RE: to have labels or not

[Andrew Conway]

> > ...
> > "Lambdaman", "Hackwell", etc. FPs appear to be designed by entire
> > teams of "Lambdamen". (OK, perhaps I'm being a little bit
> > provocative here ;-)
> 
> You certainly are provocative, as far as the Caml team is concerned:
> we consistently insisted on practicability and usability of the
> language, ...

I agree that the CAML team works really hard to make Caml practical.
Indeed the reason that I chose CAML to work with over other languages
was its pragmatism. It gave the impression of a "C" type language [no
insult intended], with the help of a whole lot of experience in 
modern language design, to make a really good language.

Re: to have labels or not

[Hao-yang Wang]

On Tue, 4 Apr 2000, Brian Rogoff wrote:
>John Skaller already answered your points, and anyways since having two
>libraries is in no way an elegant solution I'll leave it alone. I still 
>think that having two modes makes it harder to explain OCaml and much 
>harder for me to promote it in industry to my colleagues, which is my main 
>concern. 

Well, there have already been lots of compilers with two modes, for C and 
C++. Both C and C++ are widely accepted in industry.

Cheers,
Hao-yang Wang

Re: to have labels or not

[Damien Doligez]

>From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>

>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 :-)

I know that Jacques is perfectly aware of it, but I think it's good
to stress this point:

Even the above is not entirely true.  If you suspect you'll have to
change modes, you can write code that works in both modes, simply by
giving all labels in the right order in every function
application.  It's even reasonable to write all your code in this
fashion.

And if you didn't do it in advance: to go from classic to commuting
label mode, add the labels.  To go from commuting label to classic
mode, don't remove the labels but put the function arguments back in
the right order.  In either case, the resulting code works in both
modes and you'll never need to change it again.

-- Damien