From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: bpr@best.com
Cc: skaller@maxtal.com.au, caml-list@inria.fr
Subject: Re: to have labels or not
Date: Tue, 04 Apr 2000 15:53:25 +0900 [thread overview]
Message-ID: <20000404155325J.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: Your message of "Wed, 29 Mar 2000 12:32:18 -0800 (PST)" <Pine.BSF.4.21.0003291200430.557-100000@shell5.ba.best.com>
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>
next prev parent reply other threads:[~2000-04-06 13:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-17 19:30 Jan Brosius
2000-03-19 4:39 ` Brian Rogoff
2000-03-22 2:30 ` Markus Mottl
2000-03-23 0:57 ` Max Skaller
2000-03-23 3:46 ` Markus Mottl
2000-03-23 23:22 ` Max Skaller
2000-03-28 1:07 ` Julian Assange
2000-03-24 2:41 ` Jacques Garrigue
2000-03-25 3:12 ` Markus Mottl
2000-03-25 3:57 ` John Max Skaller
2000-03-29 20:32 ` Brian Rogoff
2000-03-30 9:56 ` John Max Skaller
2000-04-04 6:53 ` Jacques Garrigue [this message]
2000-04-04 13:04 ` John Max Skaller
2000-04-04 16:39 ` Brian Rogoff
2000-04-05 16:02 ` Control inversion John Max Skaller
2000-04-06 13:43 ` to have labels or not Pierre Weis
2000-04-06 16:33 ` Andrew Conway
2000-03-28 1:04 ` labels, Hash.create Julian Assange
2000-03-25 14:46 to have labels or not Damien Doligez
2000-04-07 2:44 Hao-yang Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20000404155325J.garrigue@kurims.kyoto-u.ac.jp \
--to=garrigue@kurims.kyoto-u.ac.jp \
--cc=bpr@best.com \
--cc=caml-list@inria.fr \
--cc=skaller@maxtal.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox