Consortium Caml

Consortium Caml

[Michel Mauny]

-- [ English version below ] ---

Chers collègues,

Nous sommes heureux de vous annoncer la mise en place du Consortium
Caml, qui a vocation à fédérer les efforts de conception et de
développement autour du langage de programmation Caml. Le Consortium
Caml tentera donc de réunir, autour de l'équipe de développement du
langage, les industriels, centres de recherche et établissements
d'enseignement intéressés pour apporter leur soutien à la conception
et au développement du langage et des outils associés.


Formant un groupement d'utilisateurs fortement motivés, le Consortium
sera le lieu où ses membres pourront identifier leurs besoins communs,
échanger leurs expériences et solutions, et coopérer pour proposer tel
ou tel développement d'intérêt général. Un des rôles du Consortium est
donc d'être un lieu de rencontre et d'échange entre utilisateurs du
langage. C'est là que se créera une véritable communauté propre à
aider au développement du langage et à lui assurer une visibilité
telle que cette communauté soit à même de se développer.

La motivation et l'importance industrielle de ses membres attireront
aussi à l'intérieur du Consortium des sociétés désireuses d'être
présentes sur le marché des applications et de la formation Caml. Un
autre rôle du Consortium est donc d'attirer de nouveaux membres,
qu'ils soient utilisateurs du langage ou fournisseurs de services.

Enfin, le Consortium fournira un élément de réponse à la question de
la pérennité du langage. Les éléments essentiels de la pérennité d'un
langage de programmation sont la pérennité de ses compilateurs (ou
leur libre disponibilité), sa base d'utilisateurs, et le volume des
codes (stables) existants. Le succès du Consortium Caml permettra de
mesurer la base d'utilisateurs et le volume de code Caml
existant. Quant à la disponibilité et le développement des
compilateurs Caml, ceux-ci sont d'ores et déjà librement distribués
avec leurs sources. Si l'INRIA décide un jour de se désengager du
développement de Caml, et donc de dissoudre le Consortium Caml tel
qu'il sera à ce moment, les membres du Consortium seront suffisamment
nombreux, ils auront des profils suffisamment diversifiés, et le
marché du langage sera tel que les membres du Consortium puissent sans
difficulté perpétuer l'existence et le développement du
langage. L'INRIA facilitera cette transition, qui est dans l'intérêt
général.

Pour de plus amples informations, et en particulier pour comprendre le
processus d'adhésion et le fonctionnement du Consortium, je vous
invite à consulter

      http://caml.inria.fr/consortium/index-fr.shtml

Très cordialement,

-- Michel Mauny

--- [ English version ] ---

Dear Colleagues,

We are pleased to announce the creation of the Caml Consortium, whose
aim is to federate the design and development efforts around the Caml
programming language. The Caml Consortium will therefore try to bring
together, around the language development team, industries, research
centres and educational establishments interested in contributing
their support to the design and development of the language and
related tools.


Comprising a group of highly-motivated users, the Consortium will be
the place where the members can identify their common requirements,
exchange their experiences and solutions, and co-operate to propose a
particular development of general interest. One of the Consortium's
roles is therefore to be a place where users of the language can meet
and exchange information.  It is here that a true community will be
created with the specific intention of assisting in the development of
the language and to provide it with such a visibility that this
community will expand by itself.

The motivation and industrial importance of its members will also
attract companies to the Consortium which want to be present on the
Caml applications and training market. Another role of the Consortium
will therefore be to attract new members, whether they are users of
the language or service providers.

Finally, the Consortium will provide a response to the question on the
language's continuity. The essential elements for the continuity of a
programming language are the continuity of its compilers (or their
free availability), its user base, and the volume of existing (stable)
codes. The success of the Caml Consortium will make it possible to
measure the user base and the volume of the existing Caml code. As for
the availability and development of the Caml compilers, these are
already freely distributed with their sources. If INRIA decides at
some point to withdraw from Caml development, and therefore to
dissolve the Caml Consortium as it presently stands, the members of
the Consortium will be sufficiently numerous, they will have
sufficiently diversified profiles, and the market for the language
will be such that the members of the Consortium will have no
difficulty in continuing the existence and development of the
language. INRIA will facilitate this transition, which is in the
general interest.

For more information, I suggest that you consult

     http://caml.inria.fr/consortium/

Best regards,

-- Michel Mauny

Re: Consortium Caml

[John Max Skaller]

Michel Mauny wrote:

As a matter of interest, does anyone know what 2000 Euro is in $A?
($US will be good enough, since 1 USD ~ .7 AUD)

Also, could someone comment on the kind of software which would be
accepted instead of money? If the software is under development,
what impact would that have on continued development?

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Print arbitrary value

[Mattias Waldau]

Is there a simple way to print how a complex structure?

Essentially I would like to use the toplevel print functionality within my
program for debugging purposes.

/mattias

Re: Print arbitrary value

[Xavier Leroy]

> Is there a simple way to print how a complex structure?
> Essentially I would like to use the toplevel print functionality within my
> program for debugging purposes.

The short answer is: no.  Here is a more detailed answer (this should
be addressed in the FAQ at some point).  

- It is easy to write a generic "print" function that simply decodes
the internal representation of its argument, using the same "tag"
information that the GC or the structural equality function (=) use.
The problem is that the internal representations contain much less
information than needed for printing.

For instance, integer, characters, booleans, and constant constructors
are all represented internally as integers; thus, the values 0,
'\000', false and [] would all be printed as "0".

Similarly, the names of sum constructors and record labels are lost:
constructors become integer tags and labels are encoded positionally.
So, the list [1;2] would be printed something like "C0(1, C0(2, 0))".
Totally useless.

- For better printing, it is necessary to have a run-time
representation of the static ML type of the value to print, in
addition to the value itself.  The ML type acts as a "decoder" for the
low-level representation of the value, allowing precise printing.
This is how the toplevel proceeds to print results of evaluations.

This works fine for the toplevel because it has easy access to all the
required typing information -- the toplevel integrates the
type-checker and compiler.  But normal programs do not: at run-time,
they do not have access to their static types and type environments.
This is just compile-time information that is not transmitted to
run-time.

Several schemes have been designed to allow some amount of run-time
type information to be available to running programs, such as
"dynamics" and the Weis-Furuse "generics".  The toplevel print
facility is hard to fit within these schemes, because it does not
suffice to have "some amount of RTTI": the full ML types plus the full
typing environment (with all type definitions, module signatures and
whatnot) are required, and this raises rather serious efficiency
issues.

So, it is unlikely that the exact equivalent of the toplevel generic
printer will ever be available at run-time.  Currently, one has to
write printing functions by hand for debugging purposes.  The
ocamlc/ocamlopt compilers, for instance, contain about 10
pretty-printers for the various intermediate representations.

Writing pretty-printers is a lot of boring work, but for complex
enough data structures, the output of the toplevel generic printer is
too verbose anyway (all the constructor names, record labels,
parentheses and braces clutter the output), and a hand-written printer
is useful to print the data in a more compact, problem-specific
notation.

- Xavier Leroy

Re: Consortium Caml

[Joshua D. Guttman]

Michel Mauny <Michel.Mauny@inria.fr> writes:

>   the Consortium will be the place where the members can identify
>   their common requirements, exchange their experiences and
>   solutions, and co-operate to propose a particular development of
>   general interest. One of the Consortium's roles is therefore to be
>   a place where users of the language can meet and exchange
>   information.

I wonder whether it would be possible to explain the proposed
activities of the consortium in more detail.  How does it differ from
this mailing list, for instance?  Many of these activities have been
going on through this mailing list.

I've been using Caml for my programming for four years now, and I've
been gradually coaxing, luring, or coercing my colleagues into joining
me.  There has been some resistance, such as "Won't it be done quicker
if I just use Java?  I already know all the libraries."  But there is
now a nucleus of Caml usage here, and I think that the English
translation of the Chailloux/Manoury/Pagano book will speed the
process.

So I would like to have my organization join the consortium.

However, to get authorization to spend a couple thousand euros, I need
to be able to explain exactly what the benefits to the company will
be.  How shall I explain this?

I'd also ask whether the cost may be a trap.  Is 2,000 euros per
member enough to make a big difference to INRIA?  Does it offset the
disadvantage of being a barrier to joining?  Would it be better to
have a fee of say 500 euros, which may lead to many more members?
Many projects can spend on that scale without much explanation to
outside bureaucrats.

Thanks very much.  Caml is a remarkably high quality system, and I
hope for the success of the consortium as a way to promote it.

        Joshua 
-- 
	Joshua D. Guttman		<guttman@mitre.org> 
	MITRE, Mail Stop A150 
	202 Burlington Rd.		Tel:	+1 781 271 2654
	Bedford, MA 01730-1420 USA	Fax:	+1 781 271 3816

Re: Consortium Caml

[Michel Mauny]

Joshua D. Guttman wrote/écrivait (Jan 31 2001, 03:34PM -0500):

> I wonder whether it would be possible to explain the proposed
> activities of the consortium in more detail.

The Consortium members will meet at least twice a year. They will have
the opportunity to identify common needs (libraries, for instance),
and their contribution to the Consortium (money) will be used to
satisfy those needs (e.g. implement these libraries). The Consortium
could also decide to organize or support events such as a Caml
workshop (open to everyone), for instance.

> How does it differ from this mailing list, for instance?

Of course, this won't affect the mailing list. But the money collected
by the Consortium will be first used to fulfill the needs of the
Consortium members.  Being of general interest, the result should be
beneficial to the whole Caml community.

> So I would like to have my organization join the consortium.

This would be great.

> However, to get authorization to spend a couple thousand euros, I need
> to be able to explain exactly what the benefits to the company will
> be.  How shall I explain this?

The first idea of the Consortium is to put people together and to have
enough money to hire an engineer giving a hand to the development of
Caml.

The second one is that this group of members will identify urgent
needs common to most of them (and consistent with the language and
implementation) to be addressed using the money of the Consortium. The
developments that members need will have a kind of higher priority. Of
course, the Caml developers will still work for all Caml users, but
the manpower supported by the Consortium should work to fulfill the
members' needs. Note that these developments will be released as Open
Sourse, as the rest of the system.

The overall idea is to have a strong group of motivated users, willing
and working to facilitate the development of applications written in
Caml, and to extend the Caml user base. In some time from now, the
group of Caml users could be large enough to represent a reasonable
market and to attract companies willing to offer OCaml training,
consulting, ... Managers should then feel more comfortable if Caml is
used in their companies, and this should ensure the language's
continuity.

> I'd also ask whether the cost may be a trap.  Is 2,000 euros per
> member enough to make a big difference to INRIA?

The big difference is when we can hire someone (an engineer, not a
researcher) to do Caml development most of his/her time. INRIA is a
research institution, and some developments, although needed to do
serious Caml programming, don't belong to research.

> Would it be better to have a fee of say 500 euros, which may lead to
> many more members?

Well, we had to choose an amount for the first option, and I don't
know wether it's easier to have 100 members giving each 500 Euros or
to have 25 giving each 2 KEuros (or even less giving even more :-). I
chose the latter, and only the experience will tell if it works this
way or not.

I hope my arguments can be convincing. Everyone is welcome to improve
them in such a way that we can soon have, in this list, a thread
entitled "convincing management to switch to Ocaml", with positive
answers.

-- 
Michel

Re: Consortium Caml

[Francisco Reyes]

On Thu, 1 Feb 2001 18:44:33 -0500, Michel Mauny wrote:

>Joshua D. Guttman wrote/écrivait (Jan 31 2001, 03:34PM -0500):
>The overall idea is to have a strong group of motivated users, willing
>and working to facilitate the development of applications written in
>Caml, and to extend the Caml user base.

I have been looking at Caml from the sidelines for some time.
In my humble opinion a possible approach may be to use something
like 60% of the funds to the needs of the large contributors and
the rest for documentation and general enhancements.

To me documentation is extremely important. For instance the
easier it is for someone to learn the more people that will be
envolved in things such as programming, more documentation,
etc.. It is a spiral.

>In some time from now, the group of Caml users could be large enough

The more resources placed into growing the user base the faster
many of the other things will be possible. It takes money to
fund development... unless you have enough volunteers, but
"quality" volunteers may be not so easily come-by.

>> I'd also ask whether the cost may be a trap.  Is 2,000 euros per
>> member enough to make a big difference to INRIA?
>
>The big difference is when we can hire someone (an engineer, not a
>researcher) to do Caml development most of his/her time.

In addition to membership you should have a way for people
simply to contribute money.
For example if you look at freebsd.org they have a way for
anyone to simply give them some money. Whether it is 10 euros or
a 1000 euros, these are donations which simply are a way for
people to support the project without a direct influence into
what happens.

Another model, which I particularly like, is to have a list of
planned projects. Individuals' funding can help decide the
order. For instance if something is low on the list and someone
gives you 2000 euros to bring that up on the list and nobody
else has given anything even close, then that feature should me
significantly moved up on the list. This in combination with the
funding from the consortium members may be a good way to start
some cash flow.

>Well, we had to choose an amount for the first option, and I don't
>know wether it's easier to have 100 members giving each 500 Euros or
>to have 25 giving each 2 KEuros (or even less giving even more :-).

Two levels of membership is probably best. Those who pay 2
Keuros can come to the bi-yearly meeting and have direct say so.
Those who pay 500 Euros will have access to a
forum/email/newsgroup which is for members only so their voice
has some weight, just that they won't be able to come to the
meetings (unless of course they pay up some more to join the
meeting).


>I hope my arguments can be convincing. Everyone is welcome to improve
>them in such a way that we can soon have, in this list, a thread
>entitled "convincing management to switch to Ocaml", with positive
>answers.

I have 2 projects at work on convincing management on using
"alternative" technology (FreeBSD and PostgreSQL). My boss is
extremely flexible, yet he has a series of concerns which need
to be addressed: Who else on the company knows the technology,
how easy would it be to find others who know the technology, how
easy would it be for someont to learn the technology. The same
applies to Caml. I found a good book, but I still find that lots
of more examples are needed. It is very discouraging to
newcomers to have to ask for every single thing on the list.


francisco
Moderator of the Corporate BSD list
http://www.egroups.com/group/BSD_Corporate

Re: Consortium Caml

[Pierre Weis]

> applies to Caml. I found a good book, but I still find that lots
> of more examples are needed. It is very discouraging to
> newcomers to have to ask for every single thing on the list.
> 
> francisco
> Moderator of the Corporate BSD list
> http://www.egroups.com/group/BSD_Corporate

[English Abstract]

Francisco asks for examples: a lot of new ones can be found at

http://pauillac.inria.fr/caml/Examples/

[Version française à la fin du message]

Hi Francisco,

You already asked for Caml examples and we agreed you were right to do
so. That's why I worked hard to add a lot of new examples for
Objective Caml: it's a big zoo of about 120 source files that tries to
demonstrate the strength of the language. It ranges from a trivial
``hello world!'' program for beginners to sophisticated examples for
experts only. It uses standalone programs as well as interactive
evaluation at toplevel, byte-code and native (optimizing) compilation.

Some examples are non trivial, for instance, we have a full-fledged
tetris game as the more advanced example to demonstrate the Caml/Tk
GUI. We also have a Knuth-Bendix completion routine for Term-Rewriting
systems experts, a tiny Logo like language implemented in Caml to
demonstrate language manipulation facilities and graphics drawings, a
grep implementation that demonstrates simple interfacing Caml and C,
examples of parsers, lexers, data type definitions, type-checking
algorithms, string manipulation programs, ...

All those examples are freely available and can be found at the
following address:

http://pauillac.inria.fr/caml/Examples/

Have fun!

PS: This is work in progress, so feel free to send remarks and
additions. In particular, new examples are welcome.

[Version française]

Francisco demande des examples: j'ai recueilli un bestiaire d'exemples
pour Caml Light et Objective Caml, à l'adresse suivante:

http://pauillac.inria.fr/caml/Examples/

Pour Caml Light, la nouveauté réside essentiellement dans les exemples
de la GUI (Graphical User Interface) Caml/Tk.

Pour Objective Caml, la nouveauté réside essentiellement dans la
traduction de l'ensemble des exemples qui étaient disponibles pour
Caml Light, plus un certain nombre d'exemples nouveaux (120 fichiers
.ml environ).

Amusez-vous bien!

PS: Ces exemples sont en développement, donc toutes les remarques
constructives extrêmement bienvenues, ainsi que les exemples nouveaux. 

Pierre Weis

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

Re: Consortium Caml

[John Max Skaller]

Francisco Reyes wrote:

> Two levels of membership is probably best.

	Actually, I'd consider three levels: add a 
level for individuals. The contribution should be enough
to cover administrative overheads, the main communal benefit
would be the existence of a 'registry' of serious
Caml users. Such a list would help us to know each other,
and also help to convince management that there really
is more than one Caml programmer in the world :-)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Consortium Caml

[Pierre Weis]

> 	Actually, I'd consider three levels: add a 
> level for individuals. The contribution should be enough
> to cover administrative overheads, the main communal benefit
> would be the existence of a 'registry' of serious
> Caml users. Such a list would help us to know each other,
> and also help to convince management that there really
> is more than one Caml programmer in the world :-)
> 
> -- 
> John (Max) Skaller, mailto:skaller@maxtal.com.au
> 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
> checkout Vyper http://Vyper.sourceforge.net
> download Interscript http://Interscript.sourceforge.net

I can give you the list of actual Caml list subscribers who are more
or less serious (serious enough to suffer the mail avalanche from the
list!).

I propose to publish it on the list with a trivial encoding algorithm
(to prevent direct usage via some kind of robot). As an exiting
alternative way of publishing this list, I can put it on the Caml Web
site as a binary file obtained via the Objective Caml output_value
facility. This would not be cryptographically bullet proof, but at
least deliciously recursive!

If any of you disagrees with the publication of this list of address,
please let me know it.

Best regards,

Pierre Weis

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

Re: Consortium Caml

[John Max Skaller]

Pierre Weis wrote:
 
> I can give you the list of actual Caml list subscribers who are more
> or less serious (serious enough to suffer the mail avalanche from the
> list!).

	Of course .. although that will not provide information
about who the people are: is X a commercial programmer available for
Caml work, a researcher, a student, or what?
 
	Personally .. I'm applying for C++ jobs, but I'd
just love to be paid to write Ocaml. In my last job,
I got to choose the language to use to implement another
language, and of course chose Ocaml... but this was
a rare opportunity, as was the previous job working
on yet another language with a compiler written in
Ocaml. It would be _so_ nice not to have to go back to C++ ... :-)

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Consortium Caml

[Didier Remy]

> I can give you the list of actual Caml list subscribers who are more
> or less serious (serious enough to suffer the mail avalanche from the
> list!).

Pierre,

I don't think this is a good idea at all. 

One registers to the caml-list either to listen or to participate to the
discussions related to Caml. The implicit contract (in such mailing lists)
between the subscriber and the administrator is that names and addresses are
only used for the purpose of redistribution of messages ---nothing else---
and that this data is kept private. I think we should keep very tightly to
this clear implicit policy.

If we wish to count the number of Ocaml supporters (for whatever reason) it
should be done by some other means. 

More seriously, if you wish to publish a list of names and/or emails, you
should only list those people who explicitly requested to be listed. You
should certainly not, by default, list all those who did not said that they
would not like to be listed: this would be a change of (implicit) contract
without an explicit agreement.

        -Didier.