[Caml-list] proposal for library

[Caml-list] proposal for library

[Diego Olivier Fernandez Pons]

Nicolas Carnasse a écrit :

> I also think it would be nice to have one big polymorphic data-
> structures library ( a la C++ Standard Template Library ) including 
> both mutable and non-mutable structures and most of the common
> algorithms - and perhaps some "misc" functions for strings and
> others...

Chris Okasaki avait annoncé il y a plusieurs années déjà une version
ML de sa librairie Edison actuellement seulement disponible en version
Haskell.
Ne voyant toujours pas la version ML venir, j'ai d'abord porté
quelques modules dont j'avais besoin, puis une partie de la libraire
(essentiellement les séquences).
J'avais en tête de poursuivre ce portage pendant les vacances.

Je dois cependant vous avertir sur un certain nombre de points :

- la création d'une librairie de structures de données n'est pas aussi
simple que cela pourrait en avoir l'air. J'en tiens pour preuve les
nombreuses discussions qui ont déjà eu lieu sur cette liste.

- la structure de la librairie Edison est un choix parmi d'autres
(tout comme la STL que vous prenez en exemple) est n'est pas
nécessairement le meilleur. Richard A. O'Keefe a dit avec raison dans
une discussion sur l'éventuel portage d'Edison vers Mercury « In
short, while we should certainly learn from Okasaki, we should not
imitate him slavishly ». 

- Ce qui vaut pour Edison vaut tout autant pour la STL. Je vous
renvoie à un article de Peyton Jones (Bulk types with class)

En somme votre affirmation « Once it'll be complete and safe, I don't
think there will be any problem for putting it into the official
distribution » n'est pas si évidente et un très important travail de
réflexion, discussion et concertation doit être fait au préalable.
Cela est d'autant plus vrai en Caml que ce dernier propose de nombreux
paradigmes de programmation (fonctionnelle, impérative, objets)

De surcroit, il faudrait y intégrer les nombreuses structures de
données déjà réalisées indépendamment par d'autres (patricia trees,
pomap, Splay trees, ...)

Pour ne pas finir sur une note négative, je signale quand même que la
présence d'une telle librairie, même si elle ne fait pas l'unanimité
serait interessante d'un point de vue pédagogique :

- implémentation fonctionnelle de structures de données (dans la
lignée du portage fait par Mottle des exemples du livre d'Okasaki)
- exemples élémentaires de programmation par objets (qui font parfois
défaut, comme l'ont prouvé certaines discussions sur cette liste, sur
la liste des débutants ou sur la liste ML)
- exemples de mélange fonctionnel / impératif

et surtout possibilité de comparer les différents paradigmes (puisque
les fonctionnalités offertes sont toujours les mêmes). C'est
d'ailleurs dans cette optique là que j'avais commencé le portage
d'Edison.

        Diego Olivier

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Alessandro Baretta]

Jean-Marc Eber wrote:
> happy that you posted it on the list.
> I didn't want to propose it to you, because I thank you wanted it to
> stay non public.
> JM


Oh, it was definitely meant to be public. It was astonishing 
for me to hear an ex-IBM researcher, a man on science, one 
would imagine, say that his customers are not interested in 
any new or advanced stuff. And I'm pretty sure he knows what 
he's talking about.

How can customers not realize that improvements in the 
production technology necessarily translate to reduced costs 
and improved quality? I'd be willing to pay more for a piece 
of software, if I had a compiler-generated proof that no 
segmentation fault can occur. There is a dose of absurdity 
in all this--although there is some sense, as well.

Xavier, let me ask a dumb question, if you don't mind: how 
do you choose which processor architectures to port ocamlopt 
to? Could .NET simply be regarded as a new "architecture" 
for ocamlopt?

At any rate, I am writing and deploying O'Caml programs. My 
customer has no internal EDP resources, so they are relying 
entirely on me. Of course, they did not ask what language I 
would write the code in. They only care to see it work, and 
they are not disappointed. Long live the Caml!

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Xavier Leroy]

> Oh, it was definitely meant to be public. It was astonishing 
> for me to hear an ex-IBM researcher, a man on science, one 
> would imagine, say that his customers are not interested in 
> any new or advanced stuff. And I'm pretty sure he knows what 
> he's talking about.

What's so surprising about this?  This man chose a particular line of
business where customers are not interested in new or advanced stuff.
Just like you could choose to manage a McDonald's and have no
professional interest in gourmet food or fine wines.

I'm not disturbed in the least by the fact that many computer
professionals couldn't care less about what we do.  (And conversely :-)
What I am concerned about is the well-meaning suggestions that we
should move towards "their" technologies in the vague hope that they
will pay more attention then.  They won't.

> They want *real_world* products on
> *real_world* platforms: COBOL and .NET, that's what they want."
> No comment. But if Ocaml could somehow "run on .NET", people
> like the above CEO (an ex-mathematician and IBM researcher,
> by the way) would be a whole lot more interested in Ocaml.

Again, I think this is a fallacy.  By the same logic:

"if OCaml could somehow 'look like COBOL', people like the above CEO 
 would be a lot more interested in OCaml".

"if Bordeaux red wines were carbonated, McDonald's would be a lot more
 interested in selling them".

You can make your own parallels: it's fun :-)

> Xavier, let me ask a dumb question, if you don't mind: how 
> do you choose which processor architectures to port ocamlopt 
> to?

By a combination of demand and availability (of a machine running said
architecture).

> Could .NET simply be regarded as a new "architecture" for ocamlopt?

Not at all.  .NET isn't just a (virtual) machine instruction set: it's
a whole infrastructure, including memory management, data
representation formats, systems services, libraries, etc.  All these
replace (and conflict with) those we have in the OCaml implementation.

Our past experiments in retargeting the OCaml implementation to .Net
failed because of this.  For more details, and an explanation of why
.Net is a real straight-jacket for innovative programming languages,
see a previous post of mine:
        http://caml.inria.fr/archives/200102/msg00190.html

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Markus Mottl]

On Thu, 20 Jun 2002, Xavier Leroy wrote:
> I'm not disturbed in the least by the fact that many computer
> professionals couldn't care less about what we do.  (And conversely :-)
> What I am concerned about is the well-meaning suggestions that we
> should move towards "their" technologies in the vague hope that they
> will pay more attention then.  They won't.

I don't think that the problem is about moving towards "their"
technologies but moving OCaml and its tools towards "their" problem
domain. It's definitely not the job of INRIA to do this, though some
help might make this task easier for the commercial programmers among us
(not me).

This usually boils down to adhering to or defining somewhat accepted
standards. E.g., I suppose that many programmers would be happy about
locale support or libraries in the distribution that handle some
high-level standard internet protocols, etc.

It might be a good idea to define some set of rules that allows people
external to INRIA to write libraries in such a way that they could be
accepted in the standard distribution. Or even better, to define and
implement standard packaging schemes that make seamless integration of 3rd
party libraries easy. Then the community could much more effectively take
over the burden of providing OCaml-libraries and tools for commercial use.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[Alessandro Baretta]

Xavier Leroy wrote:
> What's so surprising about this?  This man chose a particular line of
> business where customers are not interested in new or advanced stuff.
> Just like you could choose to manage a McDonald's and have no
> professional interest in gourmet food or fine wines.

It is not so much his choice as the choice of his customers, 
which, of course, he must adhere to. If his customers ask 
for MS-SQLserver he gives them that, although he openly 
declares to have a preference for DB2.  The same is with 
PLs. He mentioned a "fantastic" programming languange by the 
name of APL which he used to use when he was a researcher at 
IBM. (I'm sure you know about APL much better than I.) It is 
not without melancholy, he said, that has had to move 
towards more commercial systems, mainly Java, and more 
recently, given the massive marketing effort from Microsoft, 
towards .NET.

What I'm talking about is the scarce interest customers have 
for quality software development processes, which 
necessarily include quality programming languages, as 
opposed to caring about the marketing hype behind one 
platform or another. Have you seen the MS commercial where a 
robot begins to paint a car frame as soon as the customer 
declares his preference for that color, stops when the 
customer shows some indecision, and immediately resumes as 
the client confirms his first choice? Has this got anything 
at all to do with .NET?

It's just the same thing with teenagers and MacDonalds: is 
it good for their health to eat there? Definitely not. An 
education effort must be carried out with teenagers to teach 
them to eat pizza, which is good for them ;-) as opposed to 
hamburgers. (And, BTW, yes, I am Italian.) A similar 
education effort might make corporate customers aware of the 
fact that O'Caml is good for them, while MS is not. (And, 
yes, I'm also a Caml rider and Penguin breeder.)

> I'm not disturbed in the least by the fact that many computer
> professionals couldn't care less about what we do.  (And conversely :-)
> What I am concerned about is the well-meaning suggestions that we
> should move towards "their" technologies in the vague hope that they
> will pay more attention then.  They won't.

I don't mean to say that "we" (the Ocaml team at INRIA, 
really) should bow to the omnipotence of Big Bill, 
especially when the language needs special features in its 
VM in order to work, as you mention later on. Yet, it would 
be easier for me to market O'Caml applications if I could 
mention some commercial trademarks my customers have already 
heard. "O'Caml" is not a winner for a trademark, especially 
when you are confronted by the inevitable question: "What 
does it stand for?"

>>They want *real_world* products on
>>*real_world* platforms: COBOL and .NET, that's what they want."
>>No comment. But if Ocaml could somehow "run on .NET", people
>>like the above CEO (an ex-mathematician and IBM researcher,
>>by the way) would be a whole lot more interested in Ocaml.
> 
> 
> Again, I think this is a fallacy.  By the same logic:
> 
> "if OCaml could somehow 'look like COBOL', people like the above CEO 
>  would be a lot more interested in OCaml".
> 
> "if Bordeaux red wines were carbonated, McDonald's would be a lot more
>  interested in selling them".
> 
> You can make your own parallels: it's fun :-)

I don't think O'Caml should like like anything other than 
O'Caml, with the sole exception of DdR's CamlP4 and its 
revised syntax. The customers has no visibility of the 
language itself, but of the entire platform on which the 
software runs: VM, API and libraries. I don't know a lot 
about VMs, but I can definitely say the Caml VM is a whole 
lot faster and more efficient that Sun's JVM. I had to buy a 
new PC one year ago just to write--and run--a few thousand 
lines of Java. O'Caml work, on the other hand, requires no 
costly hardware. I really like the VM. But all this does not 
make it terribly attractive to my customers. As I already 
mentioned, it is mainly a marketing problem.

>>Xavier, let me ask a dumb question, if you don't mind: how 
>>do you choose which processor architectures to port ocamlopt 
>>to?
> 
> 
> By a combination of demand and availability (of a machine running said
> architecture).
> 
> 
>>Could .NET simply be regarded as a new "architecture" for ocamlopt?
> 
> 
> Not at all.  .NET isn't just a (virtual) machine instruction set: it's
> a whole infrastructure, including memory management, data
> representation formats, systems services, libraries, etc.  All these
> replace (and conflict with) those we have in the OCaml implementation.
> 
> Our past experiments in retargeting the OCaml implementation to .Net
> failed because of this.  For more details, and an explanation of why
> .Net is a real straight-jacket for innovative programming languages,
> see a previous post of mine:
>         http://caml.inria.fr/archives/200102/msg00190.html

Dumb question. Alright, forget it.

Thank you very much for your time and interest. I hope I am 
making some sense.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Unix.file_descr -> int ???

[YAMAGATA yoriyuki]

From: Markus Mottl <markus@oefai.at>
Subject: Re: [Caml-list] Unix.file_descr -> int ???
Date: Thu, 20 Jun 2002 13:52:37 +0200

> It might be a good idea to define some set of rules that allows people
> external to INRIA to write libraries in such a way that they could be
> accepted in the standard distribution.

and some degree of disclosure of the future development plan, or at
least, what INRIA team is working now, would help.  This would reduce
danger of duplicated works.

--
Yamagata Yoriyuki
http://www.mars.sphere.ne.jp/yoriyuki/
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] proposal for library

[Christophe Raffalli]

Le jeu 20/06/2002 à 16:42, YAMAGATA yoriyuki a écrit :
> From: Markus Mottl <markus@oefai.at>
> Subject: Re: [Caml-list] Unix.file_descr -> int ???
> Date: Thu, 20 Jun 2002 13:52:37 +0200
> 
> > It might be a good idea to define some set of rules that allows people
> > external to INRIA to write libraries in such a way that they could be
> > accepted in the standard distribution.
> 
> and some degree of disclosure of the future development plan, or at
> least, what INRIA team is working now, would help.  This would reduce
> danger of duplicated works.

Why not have a system of submission/referee for adding functions to
existing library (I am often mising for instance the usual List.flat_map
or List.rev_append in list.mli) or adding new library to the standard
OCaml ? 

There should exist some clearly written rules to respect, and the
referees should check that these rules are respected. The referees could
also ask for modification and so on ..

I do not think the INRIA team spend a lot of time adapting the libraries
when they do incompatible change to OCaml. And moreover, some libraries
could be maintained outside of INRIA (by the guy who created the
library) ?

I think this is interesting, because we often write some small library
of function that could be useful to every body ... so it is a nice way
to share them.

among the useful missing library that I am sure many people have
allready written, there are: library for multiset (using Map or
something better), partial order, etc ...

Morever, people could also submit optimized replacement for existing
libraries (using a compatible interface ans semantics, this is hard to
check for the referre). So this way we could get nice, complete and
efficient libraries for OCaml !

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] proposal for library

[Nicolas Cannasse]

> I think this is interesting, because we often write some small library
> of function that could be useful to every body ... so it is a nice way
> to share them.
>
> among the useful missing library that I am sure many people have
> allready written, there are: library for multiset (using Map or
> something better), partial order, etc ...
>
> Morever, people could also submit optimized replacement for existing
> libraries (using a compatible interface ans semantics, this is hard to
> check for the referre). So this way we could get nice, complete and
> efficient libraries for OCaml !

I also think it would be nice to have one big polymorphic data-structures
library ( a la C++ Standard Template Library ) including both mutable and
non-mutable structures and most of the common algorithms - and perhaps some
"misc" functions for strings and others.... If some people are interested by
opening a SourceForge ( or other CVS ) account to enable such development,
that will enable the whole community to design and write such a library.

Once it'll be complete and safe, I don't think there will be any problem for
putting it into the official distribution.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners