convincing management to switch to Ocaml

convincing management to switch to Ocaml

[STARYNKEVITCH Basile]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1831 bytes --]


Hello,

Does any one have clues or positive experience about convincing
management to switch to Ocaml?

 I'm working for an European Community ESPRIT project [TWO] for static
code analysis -with testing in mind- using abstract interpretation
techniques.

But I failed to convince my management to switch to a good language
such as Ocaml.

================ 

My manager's arguments are:

* There is an existing (important) code base (a static C code
analyser) coded in C and C++ and it is unreasonable to recode it.

* Ocaml is an academic langage

* Ocaml is a slow implentation

* Ocaml is hard to learn for people (fluent in C++) with less than a PhD
in computer science (unfortunately for me, I do hold a PhD in
Artif. Intel.)

* Ocaml might not last long (but ESPRIT projects don't last neither)

================

ESPRIT projects are supposed to be preindustrial and OCaml is only academic

Although I do know Ocaml and in a previous job I was (for 15 months)
an Ocaml evangelizer I failed to convince my boss (who is computer
educated, and knows much more about static code analysis or clever
compiler techniques than I do).

Any *quantitative* facts about Ocaml productivity boosts will be
appreciated; any history about switching to Ocaml for an
*existing* project with an existing code base (about 300kloc of C or
C++) would be great.


N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

---------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique 
DTA/LETI/DEIN/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX * France
phone: 1,69.08.60.55; fax: 1.69.08.83.95 home: 1,46.65.45.53
email: Basile point Starynkevitch at cea point fr 

Re: convincing management to switch to Ocaml

[Markus Mottl]

> Does any one have clues or positive experience about convincing
> management to switch to Ocaml?

If the term "management" also covers responsible academic staff, the
answer is unfortunately: "no". I have tried (really hard) to change the
mind of professors and assistants at a Department of Applied Computer
Science at a University of Economics to teach other languages than C/C++
to students of "commercial data processing".

Having been the system administrator, I had to see that students had
enormous problems grasping the ideas of these languages. Instead of
learning good ways to design software (algorithms, datastructures,
abstraction methods), they wasted most of their time trying to figure
out the complex and ill syntax and semantics of these languages.

The reason, why my proposal was declined, was that "industry needs C++
so we teach C++" - what a miserable attitude for an academic institution!

> My manager's arguments are:
> 
> * There is an existing (important) code base (a static C code
> analyser) coded in C and C++ and it is unreasonable to recode it.

Although I think that these arguments are just lame excuses (see below),
it is fairly easy to eliminate this one:

Interfacing OCaml to C/C++ is nearly as easy as writing header files -
even if you do it by hand. But CamlIDL does a very good job, so making
existing code bases available to OCaml is a neglictible effort.

> * Ocaml is an academic langage

As you can see above, even academia is not prepared to change its mind
easily.

Anyway, I think there are enough people from "industry" in this mailing
list who can prove the opposite...

> * Ocaml is a slow implentation

Another lame excuse: this is a matter of "not knowing". My personal
experience (and I'd be surprised if other people in this list don't share
it) is that when programming in OCaml I find it much easier to use more
sophisticated (=complicated) algorithms and datastructures. So my programs
most often run even *faster* than earlier versions of my software in, say,
C++. Last but not least, this is due to the *astonishing* performance
of the native code compiler (actually, to my knowledge the byte code
compiler and the toplevel interpreter have no competitors in "industry"
which can match their performance).

> * Ocaml is hard to learn for people (fluent in C++) with less than a PhD
> in computer science (unfortunately for me, I do hold a PhD in
> Artif. Intel.)

I don't have any degree at all, had also programmed C++ for some
years before having switched to OCaml and it was a most encouraging
experience when I decided to learn it: for the first time in life I
had the impression that I had *really* understood what algorithms and
datastructures are about. The educational effect on the programmer
is enormous! I am sure this is also true for PhDs who change from C++
to OCaml.

> * Ocaml might not last long (but ESPRIT projects don't last neither)

In, say, 60 years or so I will also not last anymore - and before that
I will definitely not want to waste my life time with C++ (personal
opinion).

Now, what concerns the life time of "projects" in industry:

The true reason, why your boss comes up with arguments against OCaml
(about which he obviously doesn't know anything at all) is, well, not
laziness to change mind: I'd say he is *risk averse*.

It's the same as with Linux: although provably technically superior to
most competitors on the market (especially *the* competitor), management
in industry was very reluctant to make use of it - if some project fails,
a manager cannot be blamed for having used "new toy technologies" (even
though these technologies would have made a failure much more unlikely).

The same is true for OCaml: one has to admit that industry got "burned"
from time to time when they decided to make use of a "new" language.

The only possibility I see is to have the "lower levels of hierarchie"
create enough pressure on management. So try to convince as many
colleagues as possible - if there are enough "evangelized" people among
them, you might stand a much better chance to turn the boss around.
There is very probably no "quick" way of introducing OCaml to industry. It
all takes time and much effort - but I think OCaml is worth it.

> Any *quantitative* facts about Ocaml productivity boosts will be
> appreciated; any history about switching to Ocaml for an
> *existing* project with an existing code base (about 300kloc of C or
> C++) would be great.

A personal and rather conservative judgement of my productivity gains:
I'd say, at least a factor of 3 (probably more) compared to C++. Not
even to mention the better quality of the resulting product...


I see that "marketing" OCaml (and computer languages in general) is
a tough problem: you cannot just send a TV-spot "Use OCaml!". On the
other hand it is clear that without marketing even the most advanced
technologies won't be successful. OCaml is not Java (that's good) -
mainly because INRIA is not Sun. I really wonder what kind of steps
INRIA generally takes so as to promote their products...

Good luck with promoting OCaml,
Markus Mottl

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

Re: convincing management to switch to Ocaml

[John Skaller]

At 16:47 28/07/99 +0200, STARYNKEVITCH Basile wrote:
>
>Hello,
>
>Does any one have clues or positive experience about convincing
>management to switch to Ocaml?

	Why switch? Is there some reason not to adopt a more
pluralist approach and use both?

	Try asking your bosses if they always use a screwdriver to
nail panels to the wall. :-)

-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

Re: convincing management to switch to Ocaml

[Gerd Stolpmann]

On Wed, 28 Jul 1999, STARYNKEVITCH Basile wrote:
>Hello,
>
>Does any one have clues or positive experience about convincing
>management to switch to Ocaml?
>
> I'm working for an European Community ESPRIT project [TWO] for static
>code analysis -with testing in mind- using abstract interpretation
>techniques.
>
>But I failed to convince my management to switch to a good language
>such as Ocaml.

I'm still trying the same, but my (industrial) project has different
prerequisits. It is already a multi-language implementation, at least
Perl, C, C++, and Java code exists. Currently, only two relatively small
Ocaml programs exist, one is a semi-automatic structure mapper that
tries to track the users' structure changes, one a parser/generator.
Both communicate with other programs only by file exchange; this is
important to get a new language integrated into projects.

>
>My manager's arguments are:
>
>* There is an existing (important) code base (a static C code
>analyser) coded in C and C++ and it is unreasonable to recode it.

This is of course a hard argument. But: Managers never want to pay for
recoding anything even if recoding is reasonable. There must be some
additional profit from recoding, such as a better program structure,
performance improvements, features that can ONLY be implemented after
the program has been recoded. It must be a dramatic story.

Possibly some parts can be reused by the C interface.

>
>* Ocaml is an academic langage

An ESPRIT project would be a chance that ocaml leaves the universities.
It is one of the tasks of a public project to transfer knowlege from the
academic world to the industry.

If the argument would count, we all would have to program in COBOL; many
wide-spread languages have their roots in the universities. Think of procedural
languages and object-oriented languages, both coming from the academic world.

I think Ocaml is actually only academic in the sense that most users can 
be found at the universities. It is truly not the case that Ocaml addresses
academic problems. Ocaml avoids some of the Lisp errors:
- it is an "open world", i.e. well-integrated into the existing operating
  systems
- it has a rich syntax

>* Ocaml is a slow implentation

This is not true; speed depends on the mainly used data structures. I expect
that abstract interpretation mainly works with term structures, and Ocaml is
fast on them. Possibly you need some benchmarks.

There are of course other technical features besides speed:

- Ocaml has a garbage collector, C and C++ don't have. Memory management is one
  of the important advantages of OCaml, because the search for memory leaks
  usually takes a considerable amount of time in C/C++. Note that memory leaks
  slow down programs.
- Ocaml does not know NULL or bad pointers. This is a matter of stability, and
  C/C++ programs almost always crash because of bad pointers.
- Ocaml is portable across platforms.
- Ocaml has a good string implementation (if this counts)
- Ocaml has exceptions, C does not have, C++ sometimes.
- Ocaml has scripting. This often reduces the time for tests.
- Ocaml has small memory footprints compared with C++.

>* Ocaml is hard to learn for people (fluent in C++) with less than a PhD
>in computer science (unfortunately for me, I do hold a PhD in
>Artif. Intel.)

People how really CAN C++ should have no problems in learning OCaml, as C++
is one of the most complicated languages currently available. (Does anybody
know a CORRECT C++ compiler?) Ocaml is much simpler (in the sense that it is
more systematic).

Many people coming from imperative languages have in deed problems learning
Ocaml because there is much more recursion, there are closures, iterators, and
other features they do not like or they have not seen yet at all. But:
- These constructs, once learned, are very productive. You can often express
  the same more consisely.
- There are imperative constructs, too, and they look like as one expect (i.e.
  the ";" denotes statement sequencing, there are "for" and "while" loops and
  so on). You need not to jump into the cold water: you can start with an
  imperative style and adopt step-by-step the functional constructs.

I think that functional constructs are not academic, there are many examples
of them but most people do not recognize them:
- Explain your boss that the Unix commands "find" and "xargs" are higher-order
  functions.
- Every program generator is a closure (but inefficiently implemented)
- CGI programs are often purely functional (because you do not have a
  background state)
- ...
The difference is that these applications of functional constructs are
exceptions from the usual way, and that Ocaml uses them systematically.

NB: I do not have a PhD.

Gerd
--
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   Gerd.Stolpmann@darmstadt.netsurf.de (privat)
Germany                     
----------------------------------------------------------------------------

Re: convincing management to switch to Ocaml

[Francois Rouaix]

> Does any one have clues or positive experience about convincing
> management to switch to Ocaml?

> My manager's arguments are:
> 
> * There is an existing (important) code base (a static C code
> analyser) coded in C and C++ and it is unreasonable to recode it.

Interface OCaml to the C code (C++ is harder if you use exception)
if that makes sense (but maybe it doesn't).

> * Ocaml is a slow implentation

Can be refuted. ocamlopt is not that bad, and brings more
advantages (e.g. symbolic-manipulation requires decent and safe memory
allocation, safe typing and all that).

> * Ocaml is hard to learn for people (fluent in C++) with less than a PhD
> in computer science (unfortunately for me, I do hold a PhD in
> Artif. Intel.)

Simple test: throw the OCaml distribution at a C++ engineer, ask the guy
to write a semi-simple program in it. Chances are the engineer will be able
to do that in one afternoon (including installing the compiler). 
This is based on a true story (tech due diligence on us by people we're working
with, I can't disclose the name).

> * Ocaml might not last long (but ESPRIT projects don't last neither)

True, but the compiler is stable. How often do you need to update the compiler 
?

> ESPRIT projects are supposed to be preindustrial and OCaml is only academic

How many ESPRIT projects actually produce code that is being used ?


--f

Reply to: convincing management to switch to Ocaml

[Jens Olsson]

I'd like to add some of my reflections to the discussion:

>* Ocaml is an academic langage

Functional languages are in use in the industry. I have working
experience with Erlang which is a functional language used in real time
telecom software. This particular language (as far as I know anyway)
is being developed from scratch by and for the industry. See
www.erlang.org for information if interested.

>* Ocaml is a slow implementation

I think Ensemble could be a good example of rather advanced software
developed in Ocaml that achieves very good performance compared to
C/C++ equivalents.

/Jens


--
--[ Jens Olsson ]-----------------------------------------------------
  [Address]            [Phone]                 [WWW]
  Djäknegatan 13, 1tr  Home: 018 -  24 88 77   jenso@csd.uu.se     
  754 23 Uppsala       Work: 018 - 471 76 85   www.csd.uu.se/~jenso
  SWEDEN               Cell: CEASED!!!         ICQ UID 8955231
---------------------------------[ CS student @ Uppsala University ]--

RE: convincing management to switch to Ocaml

[Frank A. Christoph]

> Does any one have clues or positive experience about convincing
> management to switch to Ocaml?
>
>  I'm working for an European Community ESPRIT project [TWO] for static
> code analysis -with testing in mind- using abstract interpretation
> techniques.
>
> But I failed to convince my management to switch to a good language
> such as Ocaml.

I think you should take a look at the following articles by Phil Wadler:

"Functional Programming: Why no one uses functional languages"
"Functional Programming: An angry half-dozen"

Both are available from his home page

http://cm.bell-labs.com/cm/cs/who/wadler/

under "recent publications"

http://cm.bell-labs.com/cm/cs/who/wadler/topics/recent.html

> ================
>
> My manager's arguments are:
>
> * There is an existing (important) code base (a static C code
> analyser) coded in C and C++ and it is unreasonable to recode it.

I bet there have been more static analyzers and abstract interpretation
programs written in functional languages than in C.

> * Ocaml is an academic langage

Is that relevant? Is code analysis really a peculiarly industrial
technique....?

> * Ocaml is a slow implentation

Yes, since it is the _only_ implementation, it is definitely the slowest
implementation of Ocaml. :)

On the other hand, it is the fastest functional language I know.

> * Ocaml is hard to learn for people (fluent in C++) with less than a PhD
> in computer science (unfortunately for me, I do hold a PhD in
> Artif. Intel.)

(You have my condolences. :)

I frequently see people argue that functional languages are too hard to
understand and use, and that you have to be a guru programmer to use them. I
am fluent in C++ and I use functional languages because they are easier to
use than conventional languages. I don't consider myself an especially good
programmer, so I need as much help from the programming system as I can get.

Conventional languages shift all the burden onto the user (= the
programmer): without garbage collection, he has to do the memory management;
without parametric polymorphism, he has to remember which type to cast a
pointer back to; without higher-order functions, he has to duplicate code
and remember to maintain both versions; without type safety, he has to code
defensively and there is a greater cognitive burden in general. The user has
to do all this stuff, so compiling the language itself is easy because, if
it runs, it's pretty much guaranteed to run fast.

With typed functional languages, the burden is on the compiler and the
implementors. The language is more expressive and declarative, so the
programmer is freer to concentrate on the problem at hand. Let the
implementor figure out how to compile it well; as a programmer I want _less_
things to worry about.

Maybe if I was Linus Torvalds or Xavier Leroy :) or some other world-class
programmer, I would be using C or C++. It's partly because I'm _not_ that I
like to use functional languages.

--FC

Re: convincing management to switch to Ocaml

[John Skaller]

At 10:00 30/07/99 +0100, Markus Mottl wrote:
>The reason, why my proposal was declined, was that "industry needs C++
>so we teach C++" - what a miserable attitude for an academic institution!

	I beg to differ. At my alma mater, a point was made
_not_ to teach anything that smacked of being 'commercial'.
They even invented a 'machine' to teach machine principles,
instead of using an existing micro-processor.
[They also completely messed up the design]

	As a result, competing universities have much better
graduate employment records, and the particular department
is suffering serious financial problems. (Many graduates
couldn't write a program, industry prefered engineers,
physicists, and mathematicians to computer scientists]

	Now they teach a new OO language to first years (sigh), 
and C/C++ to second years. [and ocaml to third years I believe]

	Computer programming is primarily a _commerical_
processes: people write programs for industry, and they
are themselves _employed_ to do so, that is, they make 
their living out of it. And a lot of that work is involved
in interfacing to existing code.

	Of course you can write wrappers. Perhaps it is easy.
So where are they? How much work is involved in wrapping
ALL the POSIX and Microsoft windows API?? How much
work implementing the functionality of Swing,
delivered standard with Java?

>> * Ocaml is an academic langage
>
>As you can see above, even academia is not prepared to change its mind
>easily.

	Of course not. Fundamentally, academia is part of industry,
which is naturally and wisely conservative.

>The true reason, why your boss comes up with arguments against OCaml
>(about which he obviously doesn't know anything at all) is, well, not
>laziness to change mind: I'd say he is *risk averse*.

	Which, surely, is reasonable.

>It's the same as with Linux: although provably technically superior to
>most competitors on the market (especially *the* competitor), management
>in industry was very reluctant to make use of it - if some project fails,
>a manager cannot be blamed for having used "new toy technologies" (even
>though these technologies would have made a failure much more unlikely).

	Ah, but that is now changing as (Redhat) Linux proves itself and is being
accepted as the most serious competitor to both Sun and Microsoft.

>The same is true for OCaml: one has to admit that industry got "burned"
>from time to time when they decided to make use of a "new" language.

	Yes. And much better supported ones too. Such as Eiffel.
Indeed, many are now getting 'burned' by Java.

	C++ on the other hand has much to recommend it:
widely used, ISO Standardised, C compatible, and designed
not to compromise efficiency. And a huge number of books
published on it.

	OTOH, ocaml has a number of problems compared with C++:
it doesn't support separate compilation properly (mutually
recursive calls don't work), it has bugs, there is no
readable reference (in English) -- the language reference is good, 
but it is for experts, the tutorial is good, but it is for
beginners .. and currenly, I'm in the middle.

	In fact, I'm kind of happy that ocaml ISN'T widely used!
It gives the developers a much freer hand in changing it,
without burning too many projects.

-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

RE: convincing management to switch to Ocaml

[Friedman Roy]

I currently use OCaml as part of an industrial project, although it is
easier when you have your own startup. At the same time, I am also on the
faculty at the department of computer science at the Technion. From my
experience, when I finally convince students to try OCaml, they learn it
VERY quickly, and usually immediately become OCaml advocates.

I guess the main problem is that university graduates get the wrong
message in all those software engineering courses regarding how to design 
software and what languages should be used. They are basically led to
beleive that good programming prectice == Object Oriented programming ==
C++ or Java. Of course, these students then go to industry, and soon
become the "management" that is hard to convince to try other
approaches/languages.

Roy

> (You have my condolences. :)
> 
> I frequently see people argue that functional languages are too hard to
> understand and use, and that you have to be a guru programmer to use them. I
> am fluent in C++ and I use functional languages because they areeasier to
> use than conventional languages. I don't consider myself an especially good
> programmer, so I need as much help from the programming system as I can get.
> 
> Conventional languages shift all the burden onto the user (= the
> programmer): withoutgarbage collection, he has to do the memory management;
> without parametric polymorphism, he has to remember which type to cast a
> pointer back to; without higher-order functions, he has to duplicate code
> and remember to maintain both versions; without type safety, he has to code
> defensively and there is a greater cognitive burden in general. The user has
> to do all this stuff, so compiling the language itself is easy because, if
> it runs, it's pretty much guaranteed to run fast.
> 
> With typed functional languages, the burden is on the compiler and the
> implementors. The language is more expressive and declarative, so the
> programmer is freer to concentrate on the problem at hand. Let the
> implementor figure out how to compile it well; as a programmer I want _less_
> things to worry about.
> 
> Maybe if I was Linus Torvalds or Xavier Leroy :) or some other world-class
> programmer, I would be using C or C++. It's partly because I'm _not_ that I
> like to use functional languages.
> 
> --FC
> 
> 

Re: convincing management to switch to Ocaml

[Chris Tilt]

Hello.

Français Faible: (excusez s'il vous plaît la traduction automatique)
Un problème modelant difficile était écrit dans Java, mon langage plus
compétent. Cependant, quand il est devenu maladroit, j'ai récrit le
programme entier dans OCAML en seulement trois semaines. Nous favorisons
maintenant le ml pour les problèmes qui ont sophistiqué la structure,
spécifiquement graphique et théorie des ensembles. Cette démonstration
mènent à un autre programmeur étudiant des langages fonctionnels à une
université voisine; et il contribuera bientôt à la
présente partie du projet. 

Ainsi, je proposerais que nous toujours choisissions le meilleur outil
pour le travail et laissions nos accomlishments être le témoignage ou
notre position.

Beaucoup de grâce à ceux qui rendent OCAML disponible à l'industrie!
Merci, Chris

En anglais:
A difficult modeling problem was being written in
Java, my most competent language. However, when it
became awkward, I rewrote the entire program
in OCAML in only three weeks. We now favor ML for
problems that have sophisticated structure, specifically
graph and set theory. This demonstration lead to another
programmer studying functional languages at a nearby
university; and he will soon be contributing to this
part of the project.

So, I would suggest that we always choose the best tool
for the job and let our accomlishments be the testimony
or our position.

Many thanks to those that make OCAML available to industry!

Merci, Chris

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chris Tilt                           WebCriteria, Inc.
CTO, VP Engineering       2140 SW Jefferson, Suite 210
                               Portland, OR 97201, USA
mailto:chris@webcriteria.com       voice: 503 225 2991
http://www.webcriteria.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

RE: convincing management to switch to Ocaml

[Frank A. Christoph]

John Skaller wrote:
> 	C++ on the other hand has much to recommend it:
> widely used, ISO Standardised, C compatible, and designed
> not to compromise efficiency. And a huge number of books
> published on it.
>
> 	OTOH, ocaml has a number of problems compared with C++:
> it doesn't support separate compilation properly (mutually
> recursive calls don't work), it has bugs, there is no
> readable reference (in English) -- the language reference is good,
> but it is for experts, the tutorial is good, but it is for
> beginners .. and currenly, I'm in the middle.

This is a very one-sided perspective. Anyone on this list can name twenty
signifiicant things that C++ lacks and Ocaml possesses. For example, type
safety, parametric polymorphism, type inference, modules, module signatures,
functors, higher-order functions, higher-order functors, garbage collection,
tail recursion, a top-level.

More generally, I think the balance that Ocaml strikes between efficiency,
and {safety, simplicity, clarity, conciseness} is much better than C++'s.
C++ is very efficient, but very unsafe, very complex, rather unclear (I'm
thinking of coercions and dynamic dispatch) and very long-winded. On the
other hand, Ocaml is fairly efficient, very safe and quite simple, clear and
concise.

Separate compilation: Considering C++ programs hardly ever employ recursion,
this is not a very convincing criticism. Anyway, mutual recursion across
module boundaries is methodologically questionable, and not that often
needed.

Bugs: I've found the Ocaml implementation to be more bug-free than many
extant C++ compilers. Undoubtedly this is largely due to the fact that C++
is so complex that few people know what its semantics are supposed to be.
Anyway, whenever I have encountered a bug, I've found that bug reports are
answered swiftly and satisfactorily within a day or two.

Lack of a reference: Is this really a fair criticism? C++ is practically an
industry in itself. No reason to indict the Ocaml team just because they
spend most of their team working on the language rather than marketing it.

Lack of ISO standardization: Who cares? Ocaml runs on many platforms despite
this, it's faster than practically all comparable language implementations,
bug reports are always promptly addressed, and new versions are regularly
released.

I don't think it is logical to criticize a _language_ for not being widely
used, not having third-party publications, or lacking ISO standardization.
That sounds more like a criticism of language _users_. :)

--FC

RE: convincing management to switch to Ocaml

[John Skaller]

At 10:51 25/08/99 +0900, Frank A. Christoph wrote:
>John Skaller wrote:
>> 	C++ on the other hand has much to recommend it:
>> widely used, ISO Standardised, C compatible, and designed
>> not to compromise efficiency. And a huge number of books
>> published on it.
>>
>> 	OTOH, ocaml has a number of problems compared with C++:
>> it doesn't support separate compilation properly (mutually
>> recursive calls don't work), it has bugs, there is no
>> readable reference (in English) -- the language reference is good,
>> but it is for experts, the tutorial is good, but it is for
>> beginners .. and currenly, I'm in the middle.
>
>This is a very one-sided perspective. 

	Of course it is! I am intentionally pointing out that
the arguments for and against both C++ and Ocaml exist: it is not
a one sided 'ocaml is better at everything' situation.

>Anyone on this list can name twenty
>signifiicant things that C++ lacks and Ocaml possesses. 

	Perhaps, but:

>For example, type safety, 

	Wrong. C++ is type safe, provided you don't use casts.

>parametric polymorphism, 

	Wrong. C++ has parametric polymorphism: both class and 
function templates can be defined.

>type inference, 

	Wrong. C++ does type inference, or it would not be possible
to call template functions without explicitly specifying the
parameter types.

>modules, 

	This is technically true, however, C++ does have a cousin
with different properties, namespaces.

>module signatures,

	Namespaces can have declarative parts -- which I agree
is not quite the same thing.

>functors, 

	A subset of what ocaml can do with functors can be
done with templates.

>higher-order functions, 

	C++ supports 'function objects', it is easy enough to
have higher order ones. [But it does require a lot more
messing around]

>higher-order functors, garbage collection,

	It's not clear that the template facilities don't
allow a subset of higher order functors to be implemented.
Perhaps ocaml does it cleaner, but you can pass templates
to templates, and you can partially specialise templates, and you can
use them recursively. Together, these features allow
some higher order functorality (but the technology is
definitely arcane!)

	C++ doesn't have GC, although you can always link in
a conservative collector.

>tail recursion, 

	Wrong: this is an implementation detail and some C++ compilers
DO do tail recursion. Microsoft does, for example.
	
>More generally, I think the balance that Ocaml strikes between efficiency,
>and {safety, simplicity, clarity, conciseness} is much better than C++'s.

	That may well be the case: I would be inclined to agree with you.
But that is precisely my point -- "the balance". There is indeed
a balance, and I was simply trying to show that by exhibiting some
of the advantages of C++, both as a language in itself, and also
in the social/industrial context.

>C++ is very efficient, but very unsafe, 

	No. You are wrong. It is NOT 'very unsafe'.
It IS possible to shoot yourself in C++ (and not just in the foot!)
however with reasonable programming practices, the class of errors which
cannot
occur in ocaml -- mainly null pointer problems -- can become
manageable.

	The reason is that the technology permits wrapping
memory management up in such way that faults are limited
to the implementation of the libraries the client is using:
the 'end user' programmer will not need to ever 'delete'
anything.

	I will also add: it isn't clear to me C++ is more
efficient than ocaml. Where complex memory management
schemes are required, it is possible ocaml is MORE efficient,
particularly since it generates assembler, bypassing C.
[Have any benchmarking been done?]

>very complex, 

	I agree that some of the syntax and lookup rules in C++
are overly complex. OTOH, I find the ocaml precedence rules are a
real annoyance -- I can't remember them, and I find all the brackets
not only make code hard to read, they make it hard to write (for me).

>rather unclear (I'm thinking of coercions and dynamic dispatch) 

	I would say that there are some problems with specification,
including imprecision, and complexity. But then, C++ HAS a specification
document, ocaml doesn't (AFAIK).

	Furthemore, these problems rarely come up in practical
programming, if the programmer is using sensible techniques.

>and very long-winded. 

	No dispute at all!!

>On the
>other hand, Ocaml is fairly efficient, very safe and quite simple, clear and
>concise.

	I do not 'quite' agree. I won't argue about efficiency,
but I do not think it is that much more 'safe' than C++: it is still
possible to write infinite loops, and get run time errors.

	I agree it is concise in _some_ places, but in others
the current implementation requires needless extra verbosity.
For example, when types and classes are mutually recursive,
it is necessary to first create generic classes, then
specify the algebraic types, and then instantiate the generics:
'type' and 'class' constructions cannot be connected by 'and'
to allow mutual recursion.

	Similarly, there is duplication between interface
and implementation files that is very annoying and doesn't
happen nearly as much in C++, since templates, classes,
and functions can be specified _once_ in header files.

>Separate compilation: Considering C++ programs hardly ever employ recursion,
>this is not a very convincing criticism. 

	This is silly. When I want to write a program to do something
such as build a compiler, which I am doing, then I need to have
recursive data structures, and I need to have recursive functions,
no matter what language I am using for the implementation.

>Anyway, mutual recursion across
>module boundaries is methodologically questionable, and not that often
>needed.

	You may be right on the first point, but then I would need
a LOT of functions in one module that I would prefer to separate.

>Lack of a reference: Is this really a fair criticism? 

	It is irrelevant whether it is FAIR or not.
The issue at hand related to whether management should choose 
C++ or ocaml. Fairness is relevant only by relation to
the requirements, not the background of the product.

	I could say it is NOT fair to say C++ is overly complex,
since it is designed as an extension of the woeful C language.
But I won't say that, because it isn't relevant: C++ really
is complex, and the 'why' of it isn't important.

>C++ is practically an
>industry in itself. No reason to indict the Ocaml team just because they
>spend most of their team working on the language rather than marketing it.

	I'm not indicting the Ocaml team!
I'm here, I'm USING ocaml, I haven't written any C++ for years,
and I really like Ocaml -- for the reasons you list and more.

	Indeed, I could probably give an account of what is missing
from C++: nested functions, deduction of types of
variables, and variants being the principal missing features IMHO.
[And ALL of these features could have been added to C++: indeed
I proposed all of them]

>Lack of ISO standardization: Who cares? 

	A very large number of organisations.
I do too because either I can tell the vendor that their
product doesn't meet specifications, or I can lodge a Defect
Report, saying the specifications are unclear or incorrect.
I can't do that for ocaml -- although I can appeal
to this newsgroup for help.

	Unfortuntely, it seems to me that this mechanism
become much less useful as the number of users increases:
to the extent that I am now writing a Python compiler
mainly so _I_ have control over my own product.

>I don't think it is logical to criticize a _language_ for not being widely
>used, not having third-party publications, or lacking ISO standardization.
>That sounds more like a criticism of language _users_. :)

	I wan't being critical of the language per se, I was pointing
out that there are arguments in favour of management using C++:
clearly there are more arguments than just technical ones,
and they cannot be dismissed.

	I'm just commencing an IT project where the implementation
language will be C/C++. Much as I _personally_ would like to use
ocaml, I'm not even going to suggest it. All the other programmers
use C/C++ and there simply isn't time for them to learn ocaml.
The customer wants C/C++ too. He may have reasons beyond
mere 'programmer availability' -- such as being able to
read the code himself, and being able to sell the product
to clients that may require C++, or even an ISO Standardised
language (most government agencies seem to require that).

	These arguments are not technical: they're social.

	I should say: I have reasons for liking ocaml
other than the language. It is based on category theory,
and is developed by mathematicians. THAT gives me 
much more faith than anything else. 

-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

RE: convincing management to switch to Ocaml

[Frank A. Christoph]

> >Anyone on this list can name twenty
> >signifiicant things that C++ lacks and Ocaml possesses.
>
> 	Perhaps, but:

John,

I started off writing this message as a point-by-point rebuttal of your
rebuttals, but the truth is that I'm neither prepared nor inclined to get
into a debate on the technical finer points of C++. I admit that I have
sometimes been surprised by C++'s ability to emulate some of the features of
other languages (via templates, function objects, the placement operator,
...), but in each case this is significantly mitigated by the fact that
programmer needs to share much of the burden, for example, because he must
follow some unusual or subtle programming practice, or because there is just
so much syntactic overhead associated with it, or because C++ just can't
enforce some significant static guarantee, or whatever.

For example, you suggested that C++ supports parametric polymorphism via
templates. But the truth is that templates are a far cry from true
parametricity. First, templates are only intensionally polymorphic, i.e.,
they imply code duplication. Second, they aren't parametric because the
template may silently put constraints on instantiable classes. Third, the
user must explicitly instantiate a template to use it.

I think it is silly to suggest that C++ is anywhere near as safe as Ocaml or
any ML derivative. There is a world of difference between a language that
_can_ be used safely by following good programming practices (and I am
skeptical even that C++ satisifies this claim), and one that _enforces_ them
statically. For me, at least, it is the latter fact that makes ML most
attractive.

Anyway, let me address the non-technical issues:

> >Lack of a reference: Is this really a fair criticism?
>
> 	It is irrelevant whether it is FAIR or not.
> The issue at hand related to whether management should choose
> C++ or ocaml. Fairness is relevant only by relation to
> the requirements, not the background of the product.
>
> 	I could say it is NOT fair to say C++ is overly complex,
> since it is designed as an extension of the woeful C language.
> But I won't say that, because it isn't relevant: C++ really
> is complex, and the 'why' of it isn't important.

OK, that's sensible. Then let me suggest this: although there is no
(English) literature on Ocaml per se, there is certainly a significant
amount of literature on functional programming in general, and a huge amount
on the mathematical foundations of functional programming. I've always found
that, although the details are of course different, the important points
carry across very well. That's one reason I don't find this such a big
problem, personally. If you know Haskell, or Scheme, or lambda-calculus, or
universal algebra, or type theory... you essentially know Ocaml.

Of course, more literature never hurts either.

> >Lack of ISO standardization: Who cares?
>
> 	A very large number of organisations.
> I do too because either I can tell the vendor that their
> product doesn't meet specifications,
> or I can lodge a Defect Report, saying the specifications are unclear or
incorrect.
> I can't do that for ocaml -- although I can appeal
> to this newsgroup for help.

Sure you can. You can write the implementors. They read this list anyway.

> >I don't think it is logical to criticize a _language_ for not being
widely
> >used, not having third-party publications, or lacking ISO
standardization.
> >That sounds more like a criticism of language _users_. :)
>
> 	I wan't being critical of the language per se, I was pointing
> out that there are arguments in favour of management using C++:
> clearly there are more arguments than just technical ones,
> and they cannot be dismissed.
>
> 	I'm just commencing an IT project where the implementation
> language will be C/C++. Much as I _personally_ would like to use
> ocaml, I'm not even going to suggest it. All the other programmers
> use C/C++ and there simply isn't time for them to learn ocaml.
> The customer wants C/C++ too. He may have reasons beyond
> mere 'programmer availability' -- such as being able to
> read the code himself, and being able to sell the product
> to clients that may require C++, or even an ISO Standardised
> language (most government agencies seem to require that).
>
> 	These arguments are not technical: they're social.

And political.

> 	I should say: I have reasons for liking ocaml
> other than the language. It is based on category theory,
> and is developed by mathematicians. THAT gives me
> much more faith than anything else.

Me too. Although I like Standard ML better from this perspective, since for
example it has a published semantics.

--FC

Re: convincing management to switch to Ocaml

[Stefan Monnier]

>>>>> "John" == John Skaller <skaller@maxtal.com.au> writes:
> 	Wrong. C++ is type safe, provided you don't use casts.

And several other C constructs like unions, arrays, varargs, manual
memory management, ...

I wish my crond and other similar daemons were written in O'Caml
or some other safe language.  After all, where is bit-twiddling
(or CPU-performance as opposed to IO and algorithm speed) required
in those programs anyway ?


	Stefan

Re: convincing management to switch to Ocaml

[Andreas Rossberg]

This is going off topic, but I felt that some of the points stated by
John should not be left unanswered.

John Skaller wrote:
> 
> >For example, type safety,
> 
>         Wrong. C++ is type safe, provided you don't use casts.

Wrong, due to pointer arithmetics. This can happen silently: e.g. the
combination of arrays and subtyping as present in C++ is unsound, you
can produce segmentation faults without using any casts or explicit
pointer arithmetics or other features deemed unsafe. I think the basic
example is even in one of Stroustrups books.

> >type inference,
> 
>         Wrong. C++ does type inference, or it would not be possible
> to call template functions without explicitly specifying the
> parameter types.

This is far from real type inference as present in most functional
languages. Except for template arguments nothing is inferred at all (and
even this `inference' is very restricted and ad-hoc). In particular,
polymorphic parametricity cannot be infered.

> It IS possible to shoot yourself in C++ (and not just in the foot!)
> however with reasonable programming practices, the class of errors which
> cannot
> occur in ocaml -- mainly null pointer problems -- can become
> manageable.

I seriously doubt that.

>         I will also add: it isn't clear to me C++ is more
> efficient than ocaml. Where complex memory management
> schemes are required, it is possible ocaml is MORE efficient,
> particularly since it generates assembler, bypassing C.

Not only because of memory management. I believe that simulating higher
order functions by using classes (and note that virtual functions often
are nothing more then an obscured form of higher order parameterisation)
is inherently more inefficient than using first class functions.

> >rather unclear (I'm thinking of coercions and dynamic dispatch)
> 
>         I would say that there are some problems with specification,
> including imprecision, and complexity. But then, C++ HAS a specification
> document, ocaml doesn't (AFAIK).

I believe that not even the most experienced C++ guru can tell what is
going on when arbitrary combinations of overloading, dynamic dispatch,
templates, template specializations, implicit coercions, and user
defined coercions come into play. In my experience (though a bit dated)
at least existing compilers cannot. And I fear the language
specification cannot either.

> OTOH, I find the ocaml precedence rules are a
> real annoyance -- I can't remember them, and I find all the brackets
> not only make code hard to read, they make it hard to write (for me).

However, they only require a simple look at the grammar. But I agree
that OCaml's syntax is too large and has its flaws.

>         Furthemore, these problems rarely come up in practical
> programming, if the programmer is using sensible techniques.

One gets a feeling of what a complex set of rules is required to specify
these `sensible techniques' by looking at the number and size of books
available that try to teach such stuff. And the necessity of such rules
adds to the language complexity. But even if this were considered
feasible I still doubt the statement.

> >Lack of a reference: Is this really a fair criticism?
> 
>         It is irrelevant whether it is FAIR or not.

I agree. Users don't care why (and why should they?).

> >Lack of ISO standardization: Who cares?
> 
>         A very large number of organisations.

A document defining the language more formally than the user manual
would definitely be a good thing. If a standard is needed then one has
to stick to Standard ML for now, I'm afraid.

>         These arguments are not technical: they're social.

You are right that there are more than just technical reasons for
choosing a particular technology. And many (not all) of these arguments
have their justification. However, I don't agree that in the particular
case of OCaml vs. C++ there exist any _technical_ advantages in the
language C++ itself.

	- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

:: be declarative. be functional. just be. ::

Re: convincing management to switch to Ocaml

[John Skaller]

At 12:00 27/08/99 +0200, Andreas Rossberg wrote:
>This is going off topic, but I felt that some of the points stated by
>John should not be left unanswered.
>
>John Skaller wrote:
>> 
>> >For example, type safety,
>> 
>>         Wrong. C++ is type safe, provided you don't use casts.
>
>Wrong, due to pointer arithmetics. This can happen silently: e.g. the
>combination of arrays and subtyping as present in C++ is unsound, you
>can produce segmentation faults without using any casts or explicit
>pointer arithmetics or other features deemed unsafe. 

	Ah, I apologise: you are correct. Here is the example:

	struuct X { int x; };
	struct Y : X { int y; };
	Y a[2];
	X *px = a;
	px[1]; // type error, not detected

This is not just a bound error, it really is a hole in the
type system. There is, in fact, another one:

	struct X { 
		int i;
		X *x; 
		X() { x = this; } 
	};
	X const anX;
	anX.x->i = 1; // write into const object!


>> >type inference,
>> 
>>         Wrong. C++ does type inference, or it would not be possible
>> to call template functions without explicitly specifying the
>> parameter types.
>
>This is far from real type inference as present in most functional
>languages. 

	I agree. However, the original point was 'categorical'
in saying C++ didn't have type inference.

>> It IS possible to shoot yourself in C++ (and not just in the foot!)
>> however with reasonable programming practices, the class of errors which
>> cannot occur in ocaml -- mainly null pointer problems -- can become
>> manageable.
>
>I seriously doubt that.

	A lot of programmers manage these problems every day.
Note I am not saying this is a good as, say, using a system
in which these class of error is eliminated.

>I believe that simulating higher
>order functions by using classes (and note that virtual functions often
>are nothing more then an obscured form of higher order parameterisation)
>is inherently more inefficient than using first class functions.

	You are probably right.

>I believe that not even the most experienced C++ guru can tell what is
>going on when arbitrary combinations of overloading, dynamic dispatch,
>templates, template specializations, implicit coercions, and user
>defined coercions come into play. In my experience (though a bit dated)
>at least existing compilers cannot. And I fear the language
>specification cannot either.

	I would agree with you.

>> OTOH, I find the ocaml precedence rules are a
>> real annoyance -- I can't remember them, and I find all the brackets
>> not only make code hard to read, they make it hard to write (for me).
>
>However, they only require a simple look at the grammar. But I agree
>that OCaml's syntax is too large and has its flaws.

	So now, we have some balance. That is what I was looking for.

>>         Furthemore, these problems rarely come up in practical
>> programming, if the programmer is using sensible techniques.
>
>One gets a feeling of what a complex set of rules is required to specify
>these `sensible techniques' by looking at the number and size of books
>available that try to teach such stuff. 

	Perhaps I am either extra stupid, or extra smart,
but generally I don't have this problem in C++. Instead,
i am just bored with so much typing on the keyboard to get
the same results as in ocaml with the same confidence in
correctness.

>And the necessity of such rules
>adds to the language complexity. But even if this were considered
>feasible I still doubt the statement.

	You would have to ask various people actually using C++
regularly to determine the truth of the statement.


>>         These arguments are not technical: they're social.
>
>You are right that there are more than just technical reasons for
>choosing a particular technology. And many (not all) of these arguments
>have their justification. However, I don't agree that in the particular
>case of OCaml vs. C++ there exist any _technical_ advantages in the
>language C++ itself.

	I am not sure due to inexperience with Ocaml, but I would
guess (since I know C++ backwards) that the main issue would
be performance, and a secondary issue the ocaml compilation
system (with the requirement on a strict ordering which is
getting in my way at present).

	I would be a lot more convinced on the performance
issue if I could see some benchmarks. Are there any?

-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

Re: convincing management to switch to Ocaml

[Dave Mason]

>>>>> On Fri, 27 Aug 1999 12:00:34 +0200, Andreas Rossberg <rossberg@ps.uni-sb.de> said:

>[many things I agree with!]

> A document defining the language more formally than the user manual
> would definitely be a good thing. If a standard is needed then one
> has to stick to Standard ML for now, I'm afraid.

Would it really be beyond a Master's student working under Xavier (or
other CAML guru) to translate the SML formal spec into a CAML formal
spec?  Or at least a PhD student.

I think it would be a Very Good Thing!  (And would make the semantic
differences between the languages very explicit.)

../Dave

Re: convincing management to switch to Ocaml

[John Skaller]

At 14:36 26/08/99 -0400, Stefan Monnier wrote:
>>>>>> "John" == John Skaller <skaller@maxtal.com.au> writes:
>> 	Wrong. C++ is type safe, provided you don't use casts.
>
>And several other C constructs like unions, arrays, varargs, manual
>memory management, ...

	Technically you are right for unions: however, I'd
consider using a union component 'equivalent to a cast'.
However, it isn't greppable like a cast, so you are right.

	C arrays are type safe, but the C conversion
of an array lvalue to a pointer to an array is not
type safe in the presence of classes when the array
type is a derived type, so you are also right there.

	Varargs macros are specially hacked up kinds
of casts, but again, you're technically correct.

	The case of stuffed up memory management
leading to a run time fault not really related to the type
system (just like indexing past the end of an array).

	There is, however, a special exception to this,
where you are right:

	Y *y = new X[n]; // upcast to base class
	del x; // hole in type system

but this is really the _same_ hole as before,
due to the conversion of an array to a pointer.

There is, in fact ANOTHER hole:

	Y *y = new X;
	del y;

which will fail if X doesn't have a virtual destructor.

------------------------

Given the list of things that are unsafe in C++,
I withdraw my claim that C++ is typesafe,
provided you don't use casts. The list of caveats
is much longer. [Ugh]


-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

Re: convincing management to switch to Ocaml

[Pierre Weis]

Hi,

As part as a discussion O'Caml versus C++, John Skaller wrote:

> OTOH, I find the ocaml precedence rules are a
> real annoyance -- I can't remember them, and I find all the brackets
> not only make code hard to read, they make it hard to write (for me).

I don't want to start a flamewar on syntax, but as a computer science
teacher and Caml implementor and designer, I'm interested at those
facts you mentioned about the syntax of the language, since I just
think the opposite way: I find the Caml precedence rules pretty
convenient, easy to teach, and fairly easy to remember since
absolutely intuitive and natural (provided they have been explained to
you and you have understood the design ideas).

So, there is something interesting to understand here, could you
elaborate a bit on your difficulties on precedences and especially
about ``all the brackets'' that make the code hard to read and hard to
write ?

Thanks in advance,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: convincing management to switch to Ocaml

[Sylvain BOULM'E]

> 
> 	I would be a lot more convinced on the performance
> issue if I could see some benchmarks. Are there any?
> 

There are some benchmarks mentionned in the following thread of the caml list :
http://pauillac.inria.fr/caml/caml-list/0886.html
http://pauillac.inria.fr/caml/caml-list/0928.html

Sylvain.

Re: convincing management to switch to Ocaml

[Xavier Leroy]

> Would it really be beyond a Master's student working under Xavier (or
> other CAML guru) to translate the SML formal spec into a CAML formal
> spec?  Or at least a PhD student.

It's not just a translation.  Some of the features of OCaml (such as
the recursive object types, the partially unspecified evaluation
order, and the whole class system) have deep impact on the formal
semantics and would require a total rewrite.

More generally, don't underestimate the difficulty of producing a
formal definition of a real-world language.  The "Definition of
Standard ML" wasn't written by one student, but by one Turing award
recipient and two world-class specialists in type theory and
operational semantics, and I believe it took them well over one year.

The issue of writing a formal definition of OCaml has been discussed a
lot here at INRIA in projet Cristal, and the consensus is that it's
well over our manpower.  My opinion on this is that it's hopeless
without machine assistance to write, type-check, execute on small
examples, and perhaps even prove basic properties of the spec.  None
of the existing tools in this area (e.g. Centaur, Coq, ELF,
lambda-Prolog) seem adequate for this task, and while there's some
promising work in progress in this direction, it's still very much an open
research problem in itself.

- Xavier Leroy

Re: convincing management to switch to Ocaml

[John Skaller]

At 10:02 30/08/99 +0200, Pierre Weis wrote:
>Hi,
>
>As part as a discussion O'Caml versus C++, John Skaller wrote:
>
>> OTOH, I find the ocaml precedence rules are a
>> real annoyance -- I can't remember them, and I find all the brackets
>> not only make code hard to read, they make it hard to write (for me).
>
>I don't want to start a flamewar on syntax, 

	Of course, neither do I (want to start any kind of flamewar) ..

	So i should say that while I find the syntax annoying,
especially after using the nice clean Python syntax, it is a small
price for the powerful semantics.

>but as a computer science
>teacher and Caml implementor and designer, I'm interested at those
>facts you mentioned about the syntax of the language, since I just
>think the opposite way: I find the Caml precedence rules pretty
>convenient, easy to teach, and fairly easy to remember since
>absolutely intuitive and natural (provided they have been explained to
>you and you have understood the design ideas).
>
>So, there is something interesting to understand here, could you
>elaborate a bit on your difficulties on precedences and especially
>about ``all the brackets'' that make the code hard to read and hard to
>write ?

	Sure, I will try. First note that my background is
in procedural languages. So I am used to calling functions like:

	f(x,y)

In ocaml, if I used curried functions, then

	f x+1 y

is an error: I have to put brackets around the individual arguments
instead of the argument list. Secondly, I have a math background,
where forward polish is right associative:

	f g x = f (g (x))

but with curried functions, 

	f g x = (f g) x

and the _other_ style I've used in math is reverse polish, which
is similar to the usual OO notation:

	x g f = x.g().f()

and now ocaml is yet another convention. As a usage example,
I often have to write:

	print_endline (x ^ (string_of_int (f y)))

whereas in a procedural language it would be

	print_endline(x ^ string_of_int(f(y)))

In other words, I'm used to function calls being syntactically
atomic: the arguments are bracketed and can be 'ignored' visually,
'as if they were subscripts'

	print_endline (...)
		x ^ string_of_int (...)
			f (..)
				x

In ocaml, the function being called is _inside_ the brackets,
first on the left, instead of labelling the 'node'. So it
has the same visual status as its arguments.

When I write ocaml, I often do the following to get brackets right:
I put the brackets in first:

	print_endline ()
	print_endline (x ^ ())
	print_endline (x ^ (string_of_int x))

because I cannot count :-) This is a pain, because I have to
keep backspacing. Even worse is: I have a string,
and want to put an integer inside it:

	"xxxx"
	"xx""xx"
	"xx"^^"xx"
	"xx"^()^"xx"
	"xx"^(string_of_int x)^"xx"

which is four editing steps, requiring 6 punctuators,
and three backspaces. If the
string was the argument to a print_endline function, I _also_
have to put brackets around the whole string expression
where none were previously needed:

	("xx"^(string_of_int x)^"xx")	

This is particularly bad, since an insertion reqires
non-local editing.

The other technique I use is to leave all the brackets out,
and then add them later -- get the semantics down first,
before I forget, then add the lexical stuff afterwards.

This problem is exacerbated by the fact that a lot of
ocaml is an expression, so you can do a lot of nesting.

The second problem I have is with the constructions that
are like 'prefix/infix' operators, for example

	if .. then .. else ...
	try .. with ...
	match .. with | .. -> .. | .. -> ..

Sudies were done in the 70's showing this is not as readable as
constructions bounded lexically at both ends.

Both Pascal and C have this fault, but only in a few constructions.
These faults were corrected in Modula: IF .. THEN .. ELSE .. ENDIF
It is a welcome relief to see while .. do .. done in ocaml:
it is not necessary to remember precedence rules that span
many lines of code.

Similarly, using separators like pascal's ";" is not as good
as terminators like C's ";". Clearly, these things are much harder
to edit (i.e, cut and paste doesn't work with separators, especially
ones that are visually terminators like ";" -- you can write

	a
	;
	b

but it looks horrid compared to:

	a;
	b

and then

	a;
	b;

is more 'symmetrical' visually.
For example, an expression like

	if x then y else z

cannot be augmented to

	if x then y; y' else z

instead, nonlocal editing is required:

	if x then begin y; y' end else z

Similarly, nested matches/try expressions always require begin/end:
unless the nesting is right at the end.

A general rule for a good syntax would be that augmentation
of some term of a construction only required local editing.
This means:

	terminators, not separators
	mandatory begin/end keywords

Of course, that would lead to a grossly OVER verbose syntax,
so it is certainly necessary to have _some_ infix operators
with precedences: a reasonable set is:

	unary +-
	binary */
	binary +-
	binary < > <= >= <> !=
	unary not
	binary and
	binary or

plus at most two or three more. (the listed set is
_already_ 7 levels of precedence!)

Anything more than that will conflict with more or less universal 
conventions. For example, Python and C and Ocaml all have bitshift operations,
with _different_ precedences which lead to a fault in 
a routine I had doing UTF8 conversions, it took an hour
to figure out that I needed more brackets.

A good technique is probably to have a lot of non-associating
operators, so that there is never any 'mental' ambiguity.
For example, the power operator should be unassociative:

	a ** b ** c 

should be an error.

I think there is a point here that, because I know a lot
of programming languages, I get confused with the various
precedence rules: I JUST DON'T WANT TO KNOW. So I program
defensively: I put the brackets in to be sure of the semantics.
This is useful for readers who are also not experts in the
language as well.

It is even more confusing when there are prefix, infix,
and postfix operators: in C

	*a[1]

is visually ambiguous: which is applied first, the * or the [1]?
I can never remember exactly, so I often add brackets:

	((*a)[1])

and the same applies in ocaml. Indeed, [] is used in ocaml
for lists as well:

	b [ a.[1] ]

and here only the . tells that .[] is an infix/suffix operator,
whereas b [] is a function with a list argument, so the
[ in the argument is a prefix/suffix operator. :-)

Another visual problem I have is that I think symbols
(i.e. punctuation marks) should bind more strongly
than words: it looks ugly to put brackets around words:

	(fun x -> print_endline ..)

is ugly compared to:

	begin fun x -> print_endline .. end

but the ideal would be

	fun x is print_endline .. efun

because I can type it from left to write,
and augment it without non-local changes.

The point is if you see a complex expression with 
lots of brackets and dots, it is hard to pick out what is
operating on what.  In the above waffling, I have probably
contradicted myself several times: and that is probably
the point.

Of course, there are worse languages: the lambda calculus
being a case that is only marginally better than C declarations
in the competition for all time most unreadable languages :-)
[The prize winner, however, is certainly category theory :-]

-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

Re: convincing management to switch to Ocaml

[John Prevost]

Pierre Weis <Pierre.Weis@inria.fr> writes:

> I don't want to start a flamewar on syntax, but as a computer science
> teacher and Caml implementor and designer, I'm interested at those
> facts you mentioned about the syntax of the language, since I just
> think the opposite way: I find the Caml precedence rules pretty
> convenient, easy to teach, and fairly easy to remember since
> absolutely intuitive and natural (provided they have been explained to
> you and you have understood the design ideas).
> 
> So, there is something interesting to understand here, could you
> elaborate a bit on your difficulties on precedences and especially
> about ``all the brackets'' that make the code hard to read and hard to
> write ?

I had a similar problem with SML and Caml until I realized the one
important rule that makes things clear: The juxtaposition
(application) operator has the highest precedence.  There are two
places this can hurt you, if you don't understand it yet:

let f_of_sum = f x + y
vs
let f_of_sum = f (x + y)

This one's actually pretty simple to figure out--it doesn't take long,
though people tend to feel unsure and write:

let sum_of_f = (f x) + (f y)

constructions when they don't have to.

(And of course, C programmers get bitten by wanting function
application to look like f(arg), rather than f arg.  It doesn't help
that oftentimes intro material takes this tack, then moves away from
it, leaving lingering uncertainties about f(x) in the student's mind.)

The other problem, which is more significant (although it causes more
problems in SML) is constructors.  When I first learned ML, it wasn't
made obvious to me that the application of a value constructor is
exactly the same as any other function.  In fact, it seemed that it
shouldn't be, since you can do pattern matching on one and not on the
other.

The painful part of this shows up mainly in patterns like the following:

let f = fun (Foo x) (Bar y) (Baz z) -> ...

It's not so much of a problem in Caml, since the above sort of pattern
is rarely useful, but in SML, where using multiple cases and multiple
patterns at the same time is possible, it makes for confusing
behavior:

fun f (Int a) (Int b) = Int (a + b)
  | f (Int a) (Flt b) = Flt (float a + b)
  | f (Flt a) (Int b) = Flt (a + float b)
  | f (Flt a) (Flt b) = Flt (a + b)

When I first tried to do something like the above, my first mistake
was to try something like this:

fun f Int(a) Int(b) = Int (a + b)

But this doesn't work, of course.  I then tried various things, until
I got:

fun f (Int a) (Int b) = Int (a + b)

At this point, I decided "Oh, I'll just write everything I can like
Lisp!" and tried to do the following for consistency:

fun f (Int a) (Int b) = (Int a + b)

Which of course, doesn't work.


Summary: It's important for introductory material to point out that 
" " is an operator, similar to others, and how it works precedence-wise.
It's also important to point out that constructor application in both
expressions and patterns acts exactly the same as function
application.  This makes things much clearer.  You can then also point
out useful things like the fact that , binds less tightly than
anything else, so you can say (long expression, long expression) to
form a tuple., and that similar rules apply to other things.

Juxtaposition as application is in some ways the most foreign bit of
syntax for a C-style language programmer.


John.

Re: convincing management to switch to Ocaml

[John Skaller]

At 20:13 30/08/99 -0400, John Prevost wrote:
>Pierre Weis <Pierre.Weis@inria.fr> writes:

>I had a similar problem with SML and Caml until I realized the one
>important rule that makes things clear: The juxtaposition
>(application) operator has the highest precedence.  

Actually, I don't have much problem remembering that one,
since it is used so often. However, let me give
you an example I cannot do today. I tried various
combinations, and have given up in exasperation. :-)
Consider that I wish to add some optional types to:

	let f x y = something;;

Now I know I can write

	let f (x:t1) (y:t2) : t3 = something;;

and I can write

	let f: t2 -> t2 -> t3 = something;;

but the latter doesn't work right if I need the parameters
to have names.  I tried:

	let (f: t2 -> t2 -> t3) x y  = something;;

and that doesn't seem to work? This shape is important,
where I have a set of functions of the same type,
with an abbreviation. There seems to be a problem,
that the operator -> is overloaded in meaning:
it means 'returns the type' and also 'has the value'.
So in

	fun x y -> value

I cannot just write

	fun x y : t1 -> t2 -> value

because the -> would be ambiguous, and I'm at a loss to know
where the brackets should go, or even if it is possible
to type the result of this function or the type of the return
value. In fact, with currying, it isn't quite so clear
what 'return value' means, since it depends on 
whether you apply the return value again.

Now, I am sure the answers lie in the formal grammar, but the 
(informal) grammar in the manual
is too complex to comprehend, and doesn't specify semantics,
(except some curoty notes), and the various 'precedence tables'
floating around don't seem to cover all the cases: I usually
use the 'ocaml' interpreter to answer these kinds of questions
by trial and error.

-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

Re: convincing management to switch to Ocaml

[Brian Rogoff]

On Sat, 28 Aug 1999, John Skaller wrote:
> At 12:00 27/08/99 +0200, Andreas Rossberg wrote:
> >You are right that there are more than just technical reasons for
> >choosing a particular technology. And many (not all) of these arguments
> >have their justification. However, I don't agree that in the particular
> >case of OCaml vs. C++ there exist any _technical_ advantages in the
> >language C++ itself.
> 
> 	I am not sure due to inexperience with Ocaml, but I would
> guess (since I know C++ backwards) that the main issue would
> be performance, and a secondary issue the ocaml compilation
> system (with the requirement on a strict ordering which is
> getting in my way at present).

Consider that C is roughly a subset of C++. Since OCaml is technically
superior in every way to C, the OCaml implementors are then not very smart 
since certain libraries (bignums, regexps, ...) are coded in C, not pure 
OCaml, even though they could easily be written in pure OCaml. Since we
know the OCaml implementors are very smart, we have reduced the
hypothesis of unqualified OCaml superiority to an absurdity :-).

Use the right tool for the job. I probably wouldn't write hardware
simulation models in OCaml. I probably wouldn't write the program to 
do clock tree insertion or scan insertion (essentially build a parse tree 
of structural Verilog and then abuse it) in anything else. Well, maybe 
SML or Icon would not be horrible...

-- Brian

Re: convincing management to switch to Ocaml

[John Prevost]

John Skaller <skaller@maxtal.com.au> writes:

> but the latter doesn't work right if I need the parameters
> to have names.  I tried:
> 
> 	let (f: t2 -> t2 -> t3) x y  = something;;
> 
> and that doesn't seem to work? This shape is important,
> where I have a set of functions of the same type,
> with an abbreviation. There seems to be a problem,
> that the operator -> is overloaded in meaning:
> it means 'returns the type' and also 'has the value'.

Hmm.  I guess this is sort of a bit odd--it would make sense for the
above to work, in terms of how type constraints usually work.  (Maybe
this ought to be changed to be more consistent.)

If you need a workaround, however, the following *will* work:

let (f : t2 -> t2 -> t3) = fun x y -> something

likewise, the following (which doesn't put the types up front) will work:

let f = (fun x y -> something : t2 -> t2 -> t3)

Basically, the "reduced form" of let for functions, namely "let f x y
= var" won't allow you to specify the type of the function as a whole,
only the types of the arguments and the type of the result:

let f (x : t2) (y : t2) = (something : t3)

In some ways, this isn't really a problem--one of the big pieces of
utility in the ML family of languages is that type inference allows
you to leave out such type signatures.  And explicit signatures for
modules takes care of the general case.

So, it's sort of an obscure problem.

John.

Re: convincing management to switch to Ocaml

[Gerard Huet]

At , Xavier Leroy wrote:
>>don't underestimate the difficulty of producing a
>formal definition of a real-world language.  The "Definition of
>Standard ML" wasn't written by one student, but by one Turing award
>recipient and two world-class specialists in type theory and
>operational semantics, and I believe it took them well over one year.
>
>The issue of writing a formal definition of OCaml has been discussed a
>lot here at INRIA in projet Cristal, and the consensus is that it's
>well over our manpower.  My opinion on this is that it's hopeless
>without machine assistance to write, type-check, execute on small
>examples, and perhaps even prove basic properties of the spec.  None
>of the existing tools in this area (e.g. Centaur, Coq, ELF,
>lambda-Prolog) seem adequate for this task, and while there's some
>promising work in progress in this direction, it's still very much an open
>research problem in itself.
>
>- Xavier Leroy
>

Yes indeed. It is still a major challenge to write a formal semantics of a
non-trivial programming language, with two requirements :
1. It should be reasonably close to an implementation of the language used
for real applications
2. It should be machine-manipulable to the extent that at least it brings
some confidence about being able to use it to prove some program property
or as a basis to a software engineering tool such as a debugger or a static
analyser

Very very few attempts have been pushed to a convincing stage :
- around 1972 Mike Gordon wrote his thesis at U. Edinburgh on a
denotational semantics of pure lisp
- around 1975 Veronique Donzeau-Gouge wrote her thesis at U. Paris 7 on a
denotational semantics of the sequential subset of ADA (which by the way
was officially mandatory according to the Stoneman requirements of DoD)
- in the early 80's Larry Paulson wrote his thesis at Stanford U. on a
semantics of Pascal which was usable at least as an interpreter
- in the middle 80's Pierre Weis (yes, the very moderator of this forum!)
wrote his thesis at Paris 7 on the Semantic Abstract Machine, implemented
it in Caml, and used it to describe fragments of ML and Pascal
- in the 80's J Moore wrote what can be considered an executable semantics
of an assembler (Python) in the NQTHM prover, and . Boyer attempted various
hardware description languages
- over the years Peter Moses, Mitchell Wand, Joelle Despeyroux, Frank
Pfenning and many others wrote semantics of  portions of languages as test
examples of meta-description systems
- 8 years ago Luca Cardelli and several colleagues from PRL attempted a
formal semantics of Modula 3, and even wrote a special PROLOG engine to
execute it, but they never saw the end of it and gave up
- so today the formal semantics of Standard ML is to my knowledge the sole
published complete semantics of a real programming language. I do not
believe it answers requirement 2, and probably only a handful of
specialists can explain how close it comes to answering requirement 1.
Gérard

PS Of course 10 years ago it was unconceivable to factor a 512-bits
integer, so we can be reasonably sure that one day we shall have a complete
semantics of Caml or Java answering both requirements.
http://www.inria.fr/Actualites/RSA155.html

Re: convincing management to switch to Ocaml

[Pierre Weis]

> 	Sure, I will try. First note that my background is
> in procedural languages. So I am used to calling functions like:
> 
> 	f(x,y)
> 
> In ocaml, if I used curried functions, then
> 
> 	f x+1 y
> 
> is an error: I have to put brackets around the individual arguments
> instead of the argument list. Secondly, I have a math background,

So, we can consistently consider the mathematical notations as natural, and
use them in Caml :)

The problem in this example has nothing to do with currying, since you would the
same problem writing
        f x+1
instead of
        f (x+1)

Then, compare this expression with the mathematical meaning of
        sin x+1

versus
        sin (x+1)

As in Caml, sin x+1 means (sin x) + 1.

> where forward polish is right associative:
> 
> 	f g x = f (g (x))
> 
> but with curried functions, 
> 
> 	f g x = (f g) x
> 
> and the _other_ style I've used in math is reverse polish, which
> is similar to the usual OO notation:
> 
> 	x g f = x.g().f()
> 
> and now ocaml is yet another convention.

Yes, and once more the Caml convention is the mathematical one.

If you read a succession of functions separated by spaces in a
mathematical book, you certainly will interpret it as an error,
instead of trying to interpret it as some strange stack notation!

For instance

        sin cos tan 0

will be seen as a meaningless sequence of symbols, unless you're
studying the mathematical theory of functions (namely the
lambda-calculus), where f g h means f (g h). Then, since Caml is a
functional language, it uses the mathematical notation for function
application borrowed from the mathematical theory of functions.

> As a usage example,
> I often have to write:
> 
> 	print_endline (x ^ (string_of_int (f y)))
> 
> whereas in a procedural language it would be
> 
> 	print_endline(x ^ string_of_int(f(y)))

As a mathematician, and knowing the mathematical natural conventions
of precedences between function applications and operations, you write

       sin x + cos x

and not

       (sin (x)) + (cos (x))

(even if the second expression, overparenthesized, is mathematically accepted).

Hence, as you simply write

       x + sin (cos y)

instead of

       x + (sin (cos (y)))

you write in Caml

       x ^ string_of_int (f y)

instead of

       x ^ (string_of_int (f (y)))

(even if the second expression, overparenthesized, is camlly accepted).

> In other words, I'm used to function calls being syntactically
> atomic: the arguments are bracketed and can be 'ignored' visually,
> 'as if they were subscripts'

As in mathematics you can use this technique, and add parens to any
function calls if you want. As in

        sin (x)

instead of

        sin x

> 
> 	print_endline (...)
> 		x ^ string_of_int (...)
> 			f (..)
> 				x
> 
> In ocaml, the function being called is _inside_ the brackets,
> first on the left, instead of labelling the 'node'. So it
> has the same visual status as its arguments.

Normal for a functional programming language where functions can be
arguments of other functions, at any nested level. Completely normal
when functions can be stored into data structures as any other
values. In fact, we do want the functions to be regular objects of the
langage, not just ``things'' with special status that can only be
applied to something. So, you're perfectly right ``the function as the
same'' blabla ``as its argument'' is just what we want in Caml!
(including when ``blabla'' is visual status).

> When I write ocaml, I often do the following to get brackets right:
> I put the brackets in first:
> 
> 	print_endline ()
> 	print_endline (x ^ ())
> 	print_endline (x ^ (string_of_int x))
> 
> because I cannot count :-). This is a pain, because I have to
> keep backspacing. Even worse is: I have a string,
> and want to put an integer inside it:
> 
> 	"xxxx"
> 	"xx""xx"
> 	"xx"^^"xx"
> 	"xx"^()^"xx"
> 	"xx"^(string_of_int x)^"xx"
> 
> which is four editing steps, requiring 6 punctuators,
> and three backspaces. If the
> string was the argument to a print_endline function, I _also_
> have to put brackets around the whole string expression
> where none were previously needed:
> 
> 	("xx"^(string_of_int x)^"xx")	
> 
> This is particularly bad, since an insertion reqires
> non-local editing.

Once more this is a problem you already had in mathematics when you
change
         sin 0.5
into
         sin (x + 0.5)

And, as in maths, where you write

         x + sin x + x instead of x + (sin x) + x

you can write
         "xx" ^ string_of_int x ^ "xx" instead of "xx"^(string_of_int x)^"xx"

And, as in maths, you must add parens around the whole
expression to pass it as argument to a function. You write

        atan (x + sin x + x)

and not

        atan x + sin x + x

[...]
> This problem is exacerbated by the fact that a lot of
> ocaml is an expression, so you can do a lot of nesting.

As in maths ?

> The second problem I have is with the constructions that
> are like 'prefix/infix' operators, for example
> 
> 	if .. then .. else ...
> 	try .. with ...
> 	match .. with | .. -> .. | .. -> ..
> 
> Sudies were done in the 70's showing this is not as readable as
> constructions bounded lexically at both ends.
> 
> Both Pascal and C have this fault, but only in a few constructions.
> These faults were corrected in Modula: IF .. THEN .. ELSE .. ENDIF
> It is a welcome relief to see while .. do .. done in ocaml:
> it is not necessary to remember precedence rules that span
> many lines of code.

You're right. You just have to learn the rules for these constructs
(more exactly for parts of them):

1) Any sequence in a arm of a conditional MUST be bracketed.
2) Any match or try in to a pattern matching clause MUST be bracketed.

> Similarly, using separators like pascal's ";" is not as good
> as terminators like C's ";". Clearly, these things are much harder
> to edit (i.e, cut and paste doesn't work with separators, especially
> ones that are visually terminators like ";" -- you can write
> 
> 	a
> 	;
> 	b
> 
> but it looks horrid compared to:
> 
> 	a;
> 	b
> 
> and then
> 
> 	a;
> 	b;
> is more 'symmetrical' visually.

You're right, that's why YOU CAN use the ; as terminator in Caml.

> For example, an expression like
> 
> 	if x then y else z
> 
> cannot be augmented to
> 
> 	if x then y; y' else z
> 
> instead, nonlocal editing is required:
> 
> 	if x then begin y; y' end else z

Same problem as for function arguments: if you want to be able to add
stuff to a function argument, you just have to systematically add
parens to any function argument. If you want to do the same for
conditional, add preventive begin and end keywords to any arms of any
conditional.

> Similarly, nested matches/try expressions always require begin/end:
> unless the nesting is right at the end.
> 
> A general rule for a good syntax would be that augmentation
> of some term of a construction only required local editing.
> This means:
> 
> 	terminators, not separators
> 	mandatory begin/end keywords

This cannot be done elegantly with function application, except if we
use a lisp-like syntax.

> Of course, that would lead to a grossly OVER verbose syntax,
> so it is certainly necessary to have _some_ infix operators
> with precedences: a reasonable set is:
> 
> 	unary +-
> 	binary */
> 	binary +-
> 	binary < > <= >= <> !=
> 	unary not
> 	binary and
> 	binary or
> 
> plus at most two or three more. (the listed set is
> _already_ 7 levels of precedence!)
>
> Anything more than that will conflict with more or less universal 
> conventions. For example, Python and C and Ocaml all have bitshift operations,
> with _different_ precedences which lead to a fault in 
> a routine I had doing UTF8 conversions, it took an hour
> to figure out that I needed more brackets.

Bitwise operations in Caml are not operators with special precedences,
which I consider as a problem, and that why you had a problem, since
relative priority of land lor lsl and asr are all the same, which is
confusing!

> A good technique is probably to have a lot of non-associating
> operators, so that there is never any 'mental' ambiguity.
> For example, the power operator should be unassociative:
> 
> 	a ** b ** c 
> 
> should be an error.

Difficult not to generalize to other operators ...

> I think there is a point here that, because I know a lot
> of programming languages, I get confused with the various
> precedence rules: I JUST DON'T WANT TO KNOW. So I program
> defensively: I put the brackets in to be sure of the semantics.
> This is useful for readers who are also not experts in the
> language as well.

This is legal to add parens almost everywhere in Caml. If you want to
program with a lot of parens, you can, and that's a safe style,
although I will not recommend it. As in maths, I will recommend to
know what you're writing when you are writing it.

As a mathematician, you are accustomed to more baroque and complex
conventions than those of Caml: prefix operators (primitive and
integral of functions, and usual functions application), postfix
operators (factorial, derivation), superscript (exponentiation),
prefix-postfix operator (2 numbers between big parens to express
binomial coefficients), division (one argument over, one argument
under a small horizontal line), infix operators (+, -, ...). The more
interesting are f' that is completely ambiguous or the invisible
operator * in xy ...

When designing Caml, we tried not to be that ambiguous, and to use the
conventions you already have learned in mathematics; hence the use of
parens in expression, the relative precedences of + and *, etc...

[...]
> and the same applies in ocaml. Indeed, [] is used in ocaml
> for lists as well:
> 
> 	b [ a.[1] ]
> 
> and here only the . tells that .[] is an infix/suffix operator,
> whereas b [] is a function with a list argument, so the
> [ in the argument is a prefix/suffix operator. :-)

In the same vein, would you complain about r.lab compared to r.(lab)
or r(lab) or even r lab ? or also module.f compared to Module.f ?

More generally, do you mean that if we change a single character in a
program the meaning should not change ? Or that any notation should
not be a prefix or a suffix of another one ?

There are many constructs to express, so we need many notations. We
try to reuse traditional notations if available, but from time to time
we have to invent a new one. In this case the users need to learn it
if they want to feel easy when using the language !

> Another visual problem I have is that I think symbols
> (i.e. punctuation marks) should bind more strongly
> than words: it looks ugly to put brackets around words:
> 
> 	(fun x -> print_endline ..)
> 
> is ugly compared to:
> 
> 	begin fun x -> print_endline .. end

You can use this form if you want it.

> but the ideal would be
> 
> 	fun x is print_endline .. efun

This is not light enough for a language that uses so many anonymous functions.
Once more generalizing it to efor, ewhile, elet, etry, ematch would
lead to a painful language.

[...]

> Of course, there are worse languages: the lambda calculus
> being a case that is only marginally better than C declarations
> in the competition for all time most unreadable languages :-)
> [The prize winner, however, is certainly category theory :-]

Wao! Too bad for us to have chosen the function application convention
from the lambda-calculus!
[Moreover, don't forget that the Caml effort has been started after
studies in category theory, witnessed in the name of the language
that is an acronyme for Categorical Abstract Machine Language!]

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/

Re: convincing management to switch to Ocaml

[Stefan Monnier]

>>>>> "John" == John Skaller <skaller@maxtal.com.au> writes:
> When I write ocaml, I often do the following to get brackets right:
> I put the brackets in first:
> 	print_endline ()
> 	print_endline (x ^ ())
> 	print_endline (x ^ (string_of_int x))
> because I cannot count :-) This is a pain, because I have to
> keep backspacing. Even worse is: I have a string,

Emacs is your friend.  It will count the parens for you and you
can use Meta-( to introduce a pair of parens (putting the cursor
in the middle).

> The second problem I have is with the constructions that
> are like 'prefix/infix' operators, for example
> 	if .. then .. else ...
> 	try .. with ...
> 	match .. with | .. -> .. | .. -> ..
> Sudies were done in the 70's showing this is not as readable as
> constructions bounded lexically at both ends.

I don't know about studies, but as the maintainer of the SML
mode for Emacs I totally agree:  it's just a pain the rear.

> A general rule for a good syntax would be that augmentation
> of some term of a construction only required local editing.
> This means:
> 	terminators, not separators
> 	mandatory begin/end keywords

Caml (like SML and Pascal and C and ...) has taken the point of view
that begin/end entities should not be made mandatory if they are
unambiguously unneeded.  I can only agree with that point of view:
why should I say
	
	if a then (1) else (2)

?  Of course, it leads to subtle problems when you change one
of the arms without first adding the delimiters, but then the
indentation of your editor might help you.

> defensively: I put the brackets in to be sure of the semantics.
> This is useful for readers who are also not experts in the
> language as well.

You could also try to rely on your programming environment to
help you.  My latest SML mode (sorry, but I happen to use SML
rather than O'Caml.  Hopefully the Emacs support modes for the
two languages can be somewhat merged at some point, given the
amount of similarity) for example (maybe caml-mode does the same)
tries to allow the user to jump over expressions in a precedence-aware
way.  Once you get used to the way it works, you can use it
to check what goes to verify your understanding of precedence
(I also always get it wrong).

> 	(fun x -> print_endline ..)
> is ugly compared to:
> 	begin fun x -> print_endline .. end

Aesthetics is in the eye of the beholder.  It's much harder to visually match
`begin' to `end' than ( to ).  And similarly, it's harder for your text editor
to match them (Emacs for example has excellent built-in support for matching
parenthesis, but lousy support for matching keywords).

> but the ideal would be
> 	fun x is print_endline .. efun

Plop!  Yet another reserved keyword!
Syntax is one of those things that you just can't get right.


	Stefan

Re: convincing management to switch to Ocaml

[John Skaller]

At 02:35 31/08/99 -0400, John Prevost wrote:
>In some ways, this isn't really a problem--one of the big pieces of
>utility in the ML family of languages is that type inference allows
>you to leave out such type signatures.  And explicit signatures for
>modules takes care of the general case.
>
>So, it's sort of an obscure problem.

	I find the 'utility' of type inference more limited.
For many functions, I want to declare the type, to make the
program more readable and reduce the scope of type errors.
(Since ocaml does 'inference first', then checks constraints,
this second technique I'm all too familiar with from using
languages using explicit typing, doesn't work so well).

	In any case, for me at least, it is not an obsure problem,
and I thank you at for exhibiting alternate syntax forms that
will ease the burden of declaring families of functions.
The case arises naturally in providing an Ocaml/Python binding,
the python builtin functions and methods -- and there are lots of them --
are ocaml functions with a fixed type. It is therefore natural to
want to abbreviate the declarations: in the interface, the types
are trivially given by

	val f : t

and now, in the body by

	let (f:t) = fun a b c d e -> body

which saves annotating each argument, which is a pain because the
names of the parameter types are long, my previous style requiring a line each
parameter (instead of one line per function).


-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

Re: convincing management to switch to Ocaml

[John Skaller]

At 19:10 31/08/99 +0200, Pierre Weis wrote:
>> 	Sure, I will try. First note that my background is
>> in procedural languages. So I am used to calling functions like:
>> 
>> 	f(x,y)
>> 
>> In ocaml, if I used curried functions, then
>> 
>> 	f x+1 y
>> 
>> is an error

>The problem in this example has nothing to do with currying, since you
would the
>same problem writing
>        f x+1
>instead of
>        f (x+1)

	Please excuse my clumbsy use of terminology: by currying I meant
'representing a function with multiple arguments using a higher order
function':

	a1 -> a2 -> r

instead of a tuple:

	a1 * a2 -> r

Using this latter form:

	f(x+1,y)

is 'correct', and 'natural' in the context of many languages I have
previously written.

>Yes, and once more the Caml convention is the mathematical one.

	Not where I can from: I learned algebra using reverse polish 
notation: here

	x f g h

is considered unambiously as

	h ( g ( f (x) ) )  (* in forward notation *)

I find the categorical interpretation even cleaner:

	x; f; g; h

where 'x' is an element arrow for x: this notation
is associative, so there is no need for brackets.
Unfortunately, applying a functor is usually done
by introducing an ambiguity (implicit conversion):

	f g h F

which only makes sense if the arrows f g h are 
lifted to element functors.

>> In ocaml, the function being called is _inside_ the brackets,
>> first on the left, instead of labelling the 'node'. So it
>> has the same visual status as its arguments.
>
>Normal for a functional programming language where functions can be
>arguments of other functions, at any nested level. 

	I'm not saying isn't normal for a functional programming
language, I'm commenting that for someone like myself,
whose 'normal' experience is with procedural languages,
the change of paradigm is disconcerting, and is sure to put
procedural programmers off switching to a functional language.

>> This problem is exacerbated by the fact that a lot of
>> ocaml is an expression, so you can do a lot of nesting.
>
>As in maths ?

	No. Mathematicians do several tricks to get around this:
more or less, a convenient notation is invented that 
serves the purpose. Usually, this involves introducing
'justifiable' ambiguities. I personally find this
difficult to deal with, and luckily the strong
typing system of languages like ocaml do not permit it.
[For example, embeddings are often made implicit]

	So the amount of punctuation required in real maths
is usually a lot less than the same (type correct) ocaml
expression.

	As another example, mathematicians use super and
subscripts, more generally, visual layout often reduces
the need for punctuation.

>> A general rule for a good syntax would be that augmentation
>> of some term of a construction only required local editing.
>> This means:
>> 
>> 	terminators, not separators
>> 	mandatory begin/end keywords
>
>This cannot be done elegantly with function application, except if we
>use a lisp-like syntax.

	Actually, I think it can. Every expression can have 
an unambiguous closed infix for:

	begin e s1 e s2 e s3 end

which automatically nests without knowing any precedence rules.
For any such rule where the separators are the same,
it is always possible to allow an optional trailing one.

A consequence of this may be a loss of error detection:

	(a,b,)

now becomes legal. I'm not suggesting ocaml be changes,
just trying to explain what I personally find difficult
to get used to.

>In the same vein, would you complain about r.lab compared to r.(lab)
>or r(lab) or even r lab ? or also module.f compared to Module.f ?

	I'm not complaining. I'm explaining what I find difficult,
in the hope the information will be useful. For example: more
examples in the tutorial, which demonstrate precedences by usage.
[People learn in the first instance by association, not by symbolic
rules?]

>More generally, do you mean that if we change a single character in a
>program the meaning should not change ? Or that any notation should
>not be a prefix or a suffix of another one ?

	I think that there is a concrete language design rule something
like 'allow common changes to be local in the recommended style'.
So for example,

	IF x 
	THEN
		something;
		something;
		something;
	ELSE
		something;
		somnething;
	ENDIF

here I can change the semantics within the body controlled by the then
or/if part, by editiing within a lexical scope consisting of a sequence
of lines: something my eye and editor a good at.

Easily the best language I have used from this point of view is Python,
although indenting must be considered a fundamental operation,
and I yearn for a folding editor which would work so well with
Python's syntax.

>This is not light enough for a language that uses so many anonymous
functions.
>Once more generalizing it to efor, ewhile, elet, etry, ematch would
>lead to a painful language.

	I have no dispute with this sentiment, I am not offering
a 'design solution'. However, I note that 'for' and 'while'
already DO have terminators: for do done .. while do done.
I am thankful for small mercies :-)

-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

Re: convincing management to switch to Ocaml

[John Skaller]

At 15:03 31/08/99 -0400, Stefan Monnier wrote:
>Caml (like SML and Pascal and C and ...) has taken the point of view
>that begin/end entities should not be made mandatory if they are
>unambiguously unneeded.  I can only agree with that point of view:
>why should I say
>	
>	if a then (1) else (2)
>
>? 

	Why not:

	if a then q else 2 fi

>You could also try to rely on your programming environment to
>help you.  

	I do. (But I'm using Vim :-)

>> 	(fun x -> print_endline ..)
>> is ugly compared to:
>> 	begin fun x -> print_endline .. end
>
>Aesthetics is in the eye of the beholder.  

	This is very true, and a fundamental problem for publishing.
Intent is important too: what works fine on my screen is not quite
the same as what looks good on paper.

>> but the ideal would be
>> 	fun x is print_endline .. efun
>
>Plop!  Yet another reserved keyword!

	.. which is not good, I agree.

>Syntax is one of those things that you just can't get right.

	There is some truth in that, however, many would
claim that, for example, the syntax of C++ or Perl,
compared with say Python, is indeed superior.

-------------------------------------------------------
John Skaller    email: skaller@maxtal.com.au
		http://www.maxtal.com.au/~skaller
		phone: 61-2-96600850
		snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia

Re: convincing management to switch to Ocaml

[TommyHallgren]

John, have you tried Haskell? From what you write I think you haven't.

As a programmer, I want to type less, use less keywords, and still have as much
power.

This is one of the reasons I like Smalltalk better than Java. In Java you end
up with a screenful of compact source, while in Smalltalk, you have nice little
pieces combined to something useful.

Regards, Tommy

===
Tommy Hallgren
Briljantg. 31, SE-421 49, Göteborg
Tel.: 0709 - 312 404 (GSM)
Tel.: 031 - 47 65 28 (Home)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com