Estimating the size of the ocaml community

Estimating the size of the ocaml community

[Yaron Minsky]

I've been trying to come up with some estimates on the size of the ocaml
community, and I'm wondering if others have come up with anything better.
Here's what I have so far:

- The mailing list is supposed to have about 500 subscribers[1].  Hard to know
  if this number is up-to-date.  I wonder if that number has changed over
  time, and what it is today.

- The OCaml Humps contributors page[2] has about 200 members.

- If you type OCaml into google, you get about 800k hits.  This compares with
  29 million for C++.  "python programming" (without the quotes) gets about 5
  million

- If you type "ocaml resume", you get about 5.5k hits.  If you type "python
  resume", you get about 270k hits.  If you type "C++ resume", you get almost
  1m hits.

- Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
  courses.  Any other places that teach the language?  Any ideas on how many
  students go through these courses?

- A few companies use ocaml, including Baretta DE&IT, Dassault Aviation,
  LexiFi, Artisan (which has been bought up by AMD?)  Anyone know of other
  such companies?  It would be interesting to get a list togther of companies
  that use ocaml significantly.

I'd be interested of any evidence people have of the size and vibrancy of the
ocaml community.  I'd be particularly interested in evidence of ocaml use in
the United States, since it seems like a majority of ocaml use is outside of
the US.

[1] http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
[2] http://caml.inria.fr/humps/index_contributors.html

Re: [Caml-list] Estimating the size of the ocaml community

[Christopher A. Watford]

On Wed, 2 Feb 2005 16:31:28 -0500, Yaron Minsky <yminsky@gmail.com> wrote:
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>  courses.  Any other places that teach the language?  Any ideas on how many
>  students go through these courses?

The University of Illinois at Urbana-Champaign uses OCaml to teach
programming language theory classes. This is where I was introduced to
OCaml for the first time. Basically we built parsers, lexers, and type
checkers. Function programming was included in the coursework, but
mainly to show its strong suits. Haskell is also taught in these
classes.

-- 
Christopher A. Watford
christopher.watford@gmail.com
http://dorm.tunkeymicket.com

Re: [Caml-list] Estimating the size of the ocaml community

[Frédéric Gava]

Hi,

> On Wed, 2 Feb 2005 16:31:28 -0500, Yaron Minsky <yminsky@gmail.com> wrote:
> > - Some schools teach ocaml.  Brown and Caltech apparently have intro
ocaml
> >  courses.  Any other places that teach the language?  Any ideas on how
many
> >  students go through these courses?

I think that "all" French Universities use OCaml to teach
functional programming  (some of them use Scheme or SML depending of the
years and/or the teachers). Ocaml is also used in "Classe préparatoires",
special schools in France to be engineers.

I also heard that Ocaml is sometime teach in Italian Universities but I am
not sure.

Regards,
Frédéric Gava

Re: [Caml-list] Estimating the size of the ocaml community

[Kenneth Knowles]

On Wed, Feb 02, 2005 at 04:31:28PM -0500, Yaron Minsky wrote:
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>   courses.  Any other places that teach the language?  Any ideas on how many
>   students go through these courses?

Here at UC Santa Cruz, my graduate programming language theory course used
O'Caml, though programming was a very small portion of the course content.  The
undergraduates are taught in C and Java, I think.

- Kenn

Re: [Caml-list] Estimating the size of the ocaml community

[Michael Jeffrey Tucker]

On Wed, 2 Feb 2005, Yaron Minsky wrote:
>
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>   courses.  Any other places that teach the language?  Any ideas on how many
>   students go through these courses?

Although there are no courses that I know of at Harvard which set out to
teach OCaml, it has made appearances in a few classes that I have taken.
Specifically, a graduate-level Artificial Intelligence course on
Computational Game Theory that is offered periodically asks its students
to complete its problem sets using OCaml. Also, Prof.  Norman Ramsey's
course on Programming Languages last year included a lecture on "Classes
and Modules in Objective Caml", though I don't think that the students
were asked to write any code in OCaml for that course.

Mike

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

The COCAN (Ocaml Alliance Network) at:

http://wiki.cocan.org/

has had between 60 and 120 unique visitors per week since it was
launched, (mid 2004).  There are more detailed stats here:

http://www.merjis.com/rocketstats/wiki.cocan.org/

Rich.

PS. We are still offering to do something for free with ocaml.org,
caml.inria.fr, involving a wiki which can be updated, but with
mailback so that people in charge can monitor changes.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Nicolas Cannasse]

> - A few companies use ocaml, including Baretta DE&IT, Dassault Aviation,
>   LexiFi, Artisan (which has been bought up by AMD?)  Anyone know of other
>   such companies?  It would be interesting to get a list togther of
companies
>   that use ocaml significantly.

As Richard answered, the OCaml Alliance website at http://wiki.cocan.org is
a good place for all people in the industry to reference themselves and
learn about each other. Any people who is using ocaml quite intensively is
welcome to register on the website.

Nicolas Cannasse

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Thu, 2005-02-03 at 08:54, Frédéric Gava wrote:

> I think that "all" French Universities use OCaml to teach
> functional programming  (some of them use Scheme or SML depending of the
> years and/or the teachers). 

AFAIK Barry Jay teaches Ocaml for FP at University of 
Technology, Sydney (in Oz).

The text book isn't Ocaml though .. I mean there isn't
one in English other than the online translation of
the French O'Reilly one.

I also had two Ocaml jobs in Australia, one with
Barry at UTS, where I learned it, and an industrial
one where I specified it myself, and then used it
(the company was a telco, the use was for a language
translator for telco service logic, which has
inspired my open source language Felix)

Two jobs in a row being paid to write Ocaml by
an employer is not bad.. I wish I could get
another one :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] Estimating the size of the ocaml community

[Erik de Castro Lopo]

On 03 Feb 2005 14:58:48 +1100
skaller <skaller@users.sourceforge.net> wrote:

> AFAIK Barry Jay teaches Ocaml for FP at University of 
> Technology, Sydney (in Oz).

Unfortunately, someone teaching a language in a course doesn't
always translate into the students using that language after 
the course is over :-(.

However, you, me and Barry, should make it at least 3 people
here in Sydney.au that use O'caml :-).

> Two jobs in a row being paid to write Ocaml by
> an employer is not bad.. I wish I could get
> another one :)

I'll let you have first shot at any o'caml jobs, but if you
need another hand, let me know :-).

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I believe C++ instills fear in programmers, fear that the interaction
of some details causes unpredictable results. Its unmanageable complexity
has spawned more fear-preventing tools than any other language, but the
solution _should_ have been to create and use a language that does not
overload the whole goddamn human brain with irrelevant details."
-- Erik Naggum

Re: [Caml-list] Estimating the size of the ocaml community

[Evan Martin]

On Wed, Feb 02, 2005 at 04:31:28PM -0500, Yaron Minsky wrote:
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>   courses.  Any other places that teach the language?  Any ideas on how many
>   students go through these courses?

The grad-level programming languages class at the University of
Washington used O'Caml throughout.

-- 
Evan Martin
martine@danga.com
http://neugierig.org

Re: [Caml-list] Estimating the size of the ocaml community

[Eric Stokes]

The two places I work both use Ocaml

California State University Northridge
Most of our middleware infrastructure is written in Ocaml (except the
directory server; for now), this includes both web pages using Wdialog,
and traditional middleware layers such as messaging and identity
management, to more low level things such as libraries implementing the
LDAP wire protocol. Remote middleware daemon is a project we started to
solve some of the problems of using ldap directly for identity
management, and ocamldap is a pretty nice ldap library.

http://ocamldap.sourceforge.net
http://www.csun.edu/~eric/ncc-website/opensource/rmwd/rmwd-description.html

Symas Inc.
We use Wdialog for our portal web site

Re: [Caml-list] Estimating the size of the ocaml community

[sejourne_kevin]

Frédéric Gava a écrit :
> Hi,
[...]
> 
> I think that "all" French Universities use OCaml to teach
> functional programming  (some of them use Scheme or SML depending of the
> years and/or the teachers). Ocaml is also used in "Classe préparatoires",
> special schools in France to be engineers.
> 
> I also heard that Ocaml is sometime teach in Italian Universities but I am
> not sure.
> 
> Regards,
> Frédéric Gava

In my master the only students who know a functional language are those 
which come from the 'université de Paris XI'. Even the engineer which 
has make a preparatory class are unaware of this kind of language.
But there is only an half of students who are french and 5 on 98 who 
come from 'université de Paris XI'.


Regards,
Kévin.

Re: [Caml-list] Estimating the size of the ocaml community

[Matthieu Brucher]

sejourne_kevin wrote:
> Frédéric Gava a écrit :
> 
>> Hi,
> 
> [...]
> 
>>
>> I think that "all" French Universities use OCaml to teach
>> functional programming  (some of them use Scheme or SML depending of the
>> years and/or the teachers). Ocaml is also used in "Classe préparatoires",
>> special schools in France to be engineers.
>>
>> I also heard that Ocaml is sometime teach in Italian Universities but 
>> I am
>> not sure.
>>
>> Regards,
>> Frédéric Gava
> 
> 
> In my master the only students who know a functional language are those 
> which come from the 'université de Paris XI'. Even the engineer which 
> has make a preparatory class are unaware of this kind of language.
> But there is only an half of students who are french and 5 on 98 who 
> come from 'université de Paris XI'.
> 
> 
> Regards,
> Kévin.

In the French classes préparatoires, those who learn CaML have taken the 
option IT. Few people are selected to choose between IT and engineer 
sciences.
But those who could choose IT know about CaML.

Matthieu

Re: [Caml-list] Estimating the size of the ocaml community

[Stefano Zacchiroli]

On Wed, Feb 02, 2005 at 10:54:11PM +0100, Frédéric Gava wrote:
> I also heard that Ocaml is sometime teach in Italian Universities but I am
> not sure.

Yes, at least here at the Computer Science Department of the University
of Bologna it was teached in the past and used for students projects in
the compiler course, but this is no longer the case.  Still, it is used
as a programming language in some research projects.

I'm aware of the university of Urbino, in which OCaml is teached as a
part of the compiler course.

Hope this helps.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-

Re: [Caml-list] Estimating the size of the ocaml community

[Olivier Pérès]

sejourne_kevin a écrit :
> In my master the only students who know a functional language are those 
> which come from the 'université de Paris XI'.

    This is not quite true. As it turns out I am a student in the very 
same master and was taught Caml during my previous years in universities 
of Brest and Nantes (both are in France). One of our fellow students 
from ENS Lyon also "speaks" Caml.

    See you,

    Olivier.

Re: [Caml-list] Estimating the size of the ocaml community

[Olivier Pérès]

Erik de Castro Lopo a écrit :
> Unfortunately, someone teaching a language in a course doesn't
> always translate into the students using that language after 
> the course is over :-(.

    If this can cheer you up a bit, last year in University of Nantes 
the two fourth year projects that got the joint best mark were written 
in OCaml (one was a spell checking framework for African languages and 
the other was a library for parallel programming, there's a link to it 
in the Humps). So you see teaching a language *can* convince people to 
use it later...

    Olivier.

Re: Estimating the size of the ocaml community

[Vincenzo Ciancia]

Stefano Zacchiroli wrote:

> 
> I'm aware of the university of Urbino, in which OCaml is teached as a
> part of the compiler course.

In Pisa it's used as metalanguage in the programming languages course.

bye

Vincenzo Ciancia

-- 
Please note that I do not read the e-mail address used in the from field but
I read vincenzo_ml at yahoo dot it
Attenzione: non leggo l'indirizzo di posta usato nel campo from, ma leggo
vincenzo_ml at yahoo dot it

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Thu, 3 Feb 2005, Erik de Castro Lopo wrote:

> On 03 Feb 2005 14:58:48 +1100
> skaller <skaller@users.sourceforge.net> wrote:
> 
> > AFAIK Barry Jay teaches Ocaml for FP at University of 
> > Technology, Sydney (in Oz).
> 
> Unfortunately, someone teaching a language in a course doesn't
> always translate into the students using that language after 
> the course is over :-(.

Yes, indeed. I even learned to know a few people who did an Ocaml-related 
PhD which afterwards got totally absorbed by the idea that C were the 
only true and proper programming language.

Huh.

Anyway, this leaves us with a very interesting question: how many people 
actually do believe in the value of Ocaml? I, for myself, use it whenever 
it is the most appropriate tool for a job (usually, when portability is 
an issue). This is sometimes the case, but more often than not, LISP 
turned out to be a better choice for what I do.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Frédéric Gava]

Hi,

> Anyway, this leaves us with a very interesting question: how many people
> actually do believe in the value of Ocaml? I, for myself, use it whenever
> it is the most appropriate tool for a job (usually, when portability is
> an issue). This is sometimes the case, but more often than not, LISP
> turned out to be a better choice for what I do.
What kinds of programs code with LISP could not be implemented (easely)
using Ocaml ?

Regards,
Frédéric Gava

Re: [Caml-list] Estimating the size of the ocaml community

[ronniec95]

On Thu, Feb 03, 2005 at 07:06:30PM +0100, Thomas Fischbacher wrote:
>
snip...
> 
> Anyway, this leaves us with a very interesting question: how many people 
> actually do believe in the value of Ocaml? I, for myself, use it whenever 

snip...
>

I use Ocaml at work for writing test harnesses for our 'real'
applications that are in C++/Java. Perhaps a special case, but our main
tools are distributed servers (based on middleware messaging) that perform 
various pricing calculations. Using the native C interface for
themessaging combined with the correctness guaranteed by doing things in
a purely functional manner, gives us a prototype, a test
harness and a correctly implemented 'real' app typically quicker than
writing the whole thing in C++ first and then finding out certain assumptions
are completely wrong!

Of course it helps me become more proficient at Ocaml too :)

Ronnie

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Fri, 2005-02-04 at 05:06, Thomas Fischbacher wrote:

> Anyway, this leaves us with a very interesting question: how many people 
> actually do believe in the value of Ocaml? I, for myself, use it whenever 
> it is the most appropriate tool for a job (usually, when portability is 
> an issue). This is sometimes the case, but more often than not, LISP 
> turned out to be a better choice for what I do.

Well ..

[skaller@pelican] ~/links/flx/src>wc *.ml
  89737  342248 3223570 total

90K Camls here speak for themselves ..

Ocaml has four downsides from my viewpoint:

(a) interfacing to C isn't trivial
(b) native code compiler on x86 can't make a shared library

To a large extent these two factors are not only
the reason for those 90K lines (which implement a 
compiler) but also the reason I'll probably have to
bootstrap the compiler away from Ocaml.

(c) the Cathedral+Bazaar development
model of the language, about which I have mixed feelings.
This seems to be good for the core compiler, but gets in
the way of improving the other tools and the library.

(d) Not many Open Source developers know Ocaml,
so it is hard to get help on Open Source projects

However none of these factors relate to Ocaml as a *language*
on its own, they're all industrial concerns.

I also use C/C++ (for C/C++ compatibility -- lol!) 
and Python (for rapid development/scripting).

Felix aims to replace all of them (high performance
functional and procedural code with rapid 
prototyping/scripting harness and C/C++ compatibility),
but I wouldn't dream of building it without a high
level language such as Ocaml as the bootstrap.

So apart from being the build tool for the current
version, Ocaml is also the principle inspiration
for the design, which is another 'value' of Ocaml
that should not be discounted, and in keeping
with its role as a combined academic/research and
industrial language. Other languages (JoCaml, C/XDuce ..
many more see the Humps) would also credit Ocaml
not only as the build tool, but also a key source
of inspiration, and many use the Ocaml runtime
even though the source language is distinct.

On the flip side, a huge industrial user base
might be a signicant impediment to improvements
to Ocaml -- at present the INRIA team can assume
a client base fairly receptive to changes and willing
to give the implementors considerably latitude
in many areas.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] Estimating the size of the ocaml community

[chris.danx]

Thomas Fischbacher wrote:
> Yes, indeed. I even learned to know a few people who did an Ocaml-related 
> PhD which afterwards got totally absorbed by the idea that C were the 
> only true and proper programming language.
> 
> Huh.

Eww...

> 
> Anyway, this leaves us with a very interesting question: how many people 
> actually do believe in the value of Ocaml? I, for myself, use it whenever 
> it is the most appropriate tool for a job (usually, when portability is 
> an issue). This is sometimes the case, but more often than not, LISP 
> turned out to be a better choice for what I do.

Sometimes it's Ocaml, sometimes it's Erlang or Oz, sometimes  it's Ruby, 
etc.  Very rarely do I find C a good match for the problem - it takes a 
certain level of skill to not screw up with C, a level I don't currently 
possess.

I use OCaml as my language of choice for graphics work and some general 
purpose tasks.  It's got several benefits over some languages, the 
compiler is pretty good and the community is fairly substantial.  It has 
good library support and some decent tutorials, references.



Chris

Re: [Caml-list] Estimating the size of the ocaml community

[chris.danx]

skaller wrote:
> On Fri, 2005-02-04 at 05:06, Thomas Fischbacher wrote:
> 
> 
>>Anyway, this leaves us with a very interesting question: how many people 
>>actually do believe in the value of Ocaml? I, for myself, use it whenever 
>>it is the most appropriate tool for a job (usually, when portability is 
>>an issue). This is sometimes the case, but more often than not, LISP 
>>turned out to be a better choice for what I do.
> 
> 
> Well ..
> 
> [skaller@pelican] ~/links/flx/src>wc *.ml
>   89737  342248 3223570 total
> 
> 90K Camls here speak for themselves ..
> 
> Ocaml has four downsides from my viewpoint:
> 
> (a) interfacing to C isn't trivial
> (b) native code compiler on x86 can't make a shared library
> 
> To a large extent these two factors are not only
> the reason for those 90K lines (which implement a 
> compiler) but also the reason I'll probably have to
> bootstrap the compiler away from Ocaml.


I didn't realise the native code compiler on x86 couldn't do this.  What 
exactly is the problem?

For interfacing to C would it be helpful to create a tool for handling 
all the underlying stuff.  In Ada, binding to C is done through special 
compiler directives and it's pretty trivial to do.  OCaml isn't Ada or 
as close to C as Ada is, but I was thinking of something that allows 
descriptions in OCaml augmented with directives telling the tool how to 
handle C.  Running the tool over a script would generate the appropriate 
C code for interfacing with OCaml.

I'm not 100% sure of the details or the benefit, but it might be worth 
considering.


Regards,
Chris

Re: [Caml-list] Estimating the size of the ocaml community

[chris.danx]

Yaron Minsky wrote:
> I've been trying to come up with some estimates on the size of the ocaml
> community, and I'm wondering if others have come up with anything better.
> Here's what I have so far:


It is also used it TPL by Pierce and possibly the new advanced follow up 
book.  We use this book as a reference text on our Type Theory course at 
uni, but use Java and SableCC for our assignments.

Re: [Caml-list] Estimating the size of the ocaml community

[Jon Harrop]

On Thursday 03 February 2005 20:50, chris.danx wrote:
> For interfacing to C would it be helpful to create a tool for handling
> all the underlying stuff.

Do you mean like CamlIDL:

http://caml.inria.fr/camlidl/

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Thu, 3 Feb 2005, Frédéric Gava wrote:

> > Anyway, this leaves us with a very interesting question: how many people
> > actually do believe in the value of Ocaml? I, for myself, use it whenever
> > it is the most appropriate tool for a job (usually, when portability is
> > an issue). This is sometimes the case, but more often than not, LISP
> > turned out to be a better choice for what I do.

> What kinds of programs code with LISP could not be implemented (easely)
> using Ocaml ?

There are quite a few things which I don't like at all about ocaml:

(1) I by far do not have the flexibility in extending the language with 
own syntax which I have in Lisp.

(2) Speaking of syntax, there's a lot of unnecessary cruft in virtually 
any language besides LISP (or rather, Scheme).

(3) The type system is annoying. People claim it helps catching errors, 
but my impression is it only catches those which I would never make 
anyway. On the other hand, I cannot just have e.g. a function like 
POSITION-IF that returns a number or nil. (Either one has to work with 
exceptions, or wrap things up using the Maybe monad. Exception techniques 
may interfere badly with tail recursion in some cases.)

(4) There are a few other minor issues, such as a lack of 
multiple-value-bind, which I personally find slightly annoying, but 
not essential.

(5) It does not behave as expected wrt module interfaces, as these include 
md5 sums over source.

(6) I cannot easily COMPILE a function to fast machine code from the REPL.

(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla).

(8) There are quite some instances where Ocaml's syntax is 
counter-intuitive to the extent of becoming a source of ugly mistakes, 
due to interference with conventions people are used to from other 
languages. I do not talk about (p,q) as x vs. x as (p,q) (or x@(p,q)) - 
as everyone else (e.g. SML, Haskell) does it, but rather about issues 
like for x=0 to 3 counting 0,1,2,3, or "\010" meaning "\x0a" instead of 
"\x08", and such.

(9) It really annoys having +, +., and +/. Furthermore, it seems a bit 
inconsistent, as on the other hand, we have e.g. < and not </.

I know quite well that some people will consider some of these points 
actually as "good" features, and think the "problems" I face can be traced 
back to me being quite misguided about programming in general. For sure, I 
should not expect Ocaml to be LISP, as it isn't. But I don't do that. :-)

It's only that I experienced a few things in LISP as quite nice, and am a 
little bit annoyed when I cannot use them. But only a little bit. ;-) 
Still, Ocaml also has a few niceties that are missing in LISP. After all, 
it is still among my favourite languages. C++, Java, JavaScript certainly 
are not.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[chris.danx]

Jon Harrop wrote:
> On Thursday 03 February 2005 20:50, chris.danx wrote:
> 
>>For interfacing to C would it be helpful to create a tool for handling
>>all the underlying stuff.
> 
> 
> Do you mean like CamlIDL:
> 
> http://caml.inria.fr/camlidl/

I looked at it awhile ago, but it didn't seem maintained so I thought 
no one used it.  Does anyone use it?  If so, how do you find it?

Re: [Caml-list] Estimating the size of the ocaml community

[Nicolas Cannasse]

> > For interfacing to C would it be helpful to create a tool for handling
> > all the underlying stuff.
>
> Do you mean like CamlIDL:
>
> http://caml.inria.fr/camlidl/
>
> -- 
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.

IMHO, OCaml GC lacks C stack scanning. Is there a specific reason why it's
not implemented ? I would be happy to get rid of CAMLparams, CAMLlocals and
CAMLreturns...

Nicolas Cannasse

Re: [Caml-list] Estimating the size of the ocaml community

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 3, 2005, at 1:16 PM, Thomas Fischbacher wrote:
> (1) I by far do not have the flexibility in extending the language with
> own syntax which I have in Lisp.
>
I have to respectfully disagree with this: IMHO, entirely too much is 
made of Lisp's macros (as distinct from Scheme's hygenic macros)! With 
camlp4, I have the ability to go from any concrete syntax I have an 
expander for to O'Caml's AST and back. This is used to good effect in 
Graydon Hoare's One Day Compiler presentation.

> (2) Speaking of syntax, there's a lot of unnecessary cruft in virtually
> any language besides LISP (or rather, Scheme).
>
Well, sure, given that in Lisp you're writing the AST by hand. :-)

> (3) The type system is annoying. People claim it helps catching errors,
> but my impression is it only catches those which I would never make
> anyway. On the other hand, I cannot just have e.g. a function like
> POSITION-IF that returns a number or nil. (Either one has to work with
> exceptions, or wrap things up using the Maybe monad. Exception 
> techniques
> may interfere badly with tail recursion in some cases.)
>
I guess I don't see the problem with "option" or variants.

> (4) There are a few other minor issues, such as a lack of
> multiple-value-bind, which I personally find slightly annoying, but
> not essential.
>
I would agree with this.

> (5) It does not behave as expected wrt module interfaces, as these 
> include
> md5 sums over source.
>
This is a pain, yes, but given how powerful the module system is, and 
the fact that, e.g. inlining is done across modules, I'm willing to 
accept this.

> (6) I cannot easily COMPILE a function to fast machine code from the 
> REPL.
>
You may wish to try "Nativize." It's in the Humps.

> (7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" 
> bla).
>
I don't quite follow; is there something wrong with Printf?

> (8) There are quite some instances where Ocaml's syntax is
> counter-intuitive to the extent of becoming a source of ugly mistakes,
> due to interference with conventions people are used to from other
> languages. I do not talk about (p,q) as x vs. x as (p,q) (or x@(p,q)) -
> as everyone else (e.g. SML, Haskell) does it, but rather about issues
> like for x=0 to 3 counting 0,1,2,3, or "\010" meaning "\x0a" instead of
> "\x08", and such.
>
I was thrown by it for a while, too, but now I find it quite natural, 
and everything else doesn't seem to fit. Having said that, in my day 
job, "everything else" means C++. Enough said. :-)

> (9) It really annoys having +, +., and +/. Furthermore, it seems a bit
> inconsistent, as on the other hand, we have e.g. < and not </.
>
I think we all eagerly await G'Caml, don't we?

> I know quite well that some people will consider some of these points
> actually as "good" features, and think the "problems" I face can be 
> traced
> back to me being quite misguided about programming in general. For 
> sure, I
> should not expect Ocaml to be LISP, as it isn't. But I don't do that. 
> :-)
>
> It's only that I experienced a few things in LISP as quite nice, and 
> am a
> little bit annoyed when I cannot use them. But only a little bit. ;-)
> Still, Ocaml also has a few niceties that are missing in LISP. After 
> all,
> it is still among my favourite languages. C++, Java, JavaScript 
> certainly
> are not.
>
Amen, and thanks for the thorough, well-articulated points.

> -- 
> regards,               tf@cip.physik.uni-muenchen.de              (o_
>  Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
> (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
> (if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian 
> GNU)
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
Best regards,
Paul Snively

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iEYEARECAAYFAkICnpIACgkQO3fYpochAqLGqgCgopwZLe/i0GycSvfwSgRdTXPr
b0oAnAk4latQbVfuHO/lchmm96rI7xA4
=gLb/
-----END PGP SIGNATURE-----

Re: [Caml-list] Estimating the size of the ocaml community

[Bardur Arantsson]

On Thu, Feb 03, 2005 at 09:34:53PM +0000, chris.danx wrote:

> >http://caml.inria.fr/camlidl/

> I looked at it awhile ago, but it didn't seem maintained so I thought 
> no one used it.  Does anyone use it?  If so, how do you find it?

For wrapping trivial or almost-trivial C library interfaces it's great.

I've also *tried* (seriously) to use it for quite a few wrapper libraries
I've created, but invariably it ends up being too much work to get it to
act right, and I just end up writing custom C code (usually with a few
macros to cut down on copy&paste code).

Now I just don't bother anymore and go straight to C.

-- 
Bardur Arantsson
<bardur@imada.sdu.dk>
<bardur@scientician.net>

- "It was the best of times, it was the *blurst* of times?" You
stupid monkey!
                                  Montgomery Burns | The Simpsons

Re: [Caml-list] Estimating the size of the ocaml community

[josh]

Thomas Fischbacher wrote:

> There are quite a few things which I don't like at all about ocaml:

>(1) I by far do not have the flexibility in extending the language with 
>own syntax which I have in Lisp.
>  
>
But you do with camlp4.

>(2) Speaking of syntax, there's a lot of unnecessary cruft in virtually 
>any language besides LISP (or rather, Scheme).
>  
>
I'm going to leave this alone,  Lisp derived languages all have the 
Parenthesis problem that makes
them "ugly" as defined by a lot of people.

>(3) The type system is annoying. People claim it helps catching errors, 
>but my impression is it only catches those which I would never make 
>anyway. On the other hand, I cannot just have e.g. a function like 
>POSITION-IF that returns a number or nil. (Either one has to work with 
>exceptions, or wrap things up using the Maybe monad. Exception techniques 
>may interfere badly with tail recursion in some cases.)
>  
>
My response is contrived, but does not require monads or exceptions and 
does basically what you're asking for ( I think):

type position = Position of int | None;;

let position-if pos = match pos with
    Position x ->  if (x > 10) then
          Position x
    else
       None
|   None -> None;;

The type system is a tool that has many uses,  it has a side effect of 
catching errors.  The above type 'position' 
can be used by anyone and the developer would then know the range of 
possible values and code accordingly. 

>(4) There are a few other minor issues, such as a lack of 
>multiple-value-bind, which I personally find slightly annoying, but 
>not essential.
>  
>
You say yourself this is not essential. 

>(5) It does not behave as expected wrt module interfaces, as these include 
>md5 sums over source.
>  
>
I'm not sure your point on this one.

>(6) I cannot easily COMPILE a function to fast machine code from the REPL.
>  
>
This is true.

>(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla).
>  
>

I don't see how this and Printf are substantially different (except that 
Printf is type safe),
could you elaborate?

>(8) There are quite some instances where Ocaml's syntax is 
>counter-intuitive to the extent of becoming a source of ugly mistakes, 
>due to interference with conventions people are used to from other 
>languages. I do not talk about (p,q) as x vs. x as (p,q) (or x@(p,q)) - 
>as everyone else (e.g. SML, Haskell) does it, but rather about issues 
>like for x=0 to 3 counting 0,1,2,3, or "\010" meaning "\x0a" instead of 
>"\x08", and such.
>  
>
This is an idiomatic issue.   I find presence of gender specific 
suffixes in French to be a problem for me
because I'm used to the conventions of English.  That does not mean 
French is wrong,  it means I need to
learn French better.   

>(9) It really annoys having +, +., and +/. Furthermore, it seems a bit 
>inconsistent, as on the other hand, we have e.g. < and not </.
>  
>
I agree with you here.   This is an issue, but I don't know that it is a 
major problem.  Also,
sometimes I do find that it helps to think about the effects of working 
with floats vs. ints
especially wrt rounding problems and what not.

>I know quite well that some people will consider some of these points 
>actually as "good" features, and think the "problems" I face can be traced 
>back to me being quite misguided about programming in general. For sure, I 
>should not expect Ocaml to be LISP, as it isn't. But I don't do that. :-)
>
>It's only that I experienced a few things in LISP as quite nice, and am a 
>little bit annoyed when I cannot use them. But only a little bit. ;-) 
>Still, Ocaml also has a few niceties that are missing in LISP. After all, 
>it is still among my favourite languages. C++, Java, JavaScript certainly 
>are not.
>
>  
>
I think you've brought up your issues very succinctly and clearly.   I 
don't agree with all of them,  but you have
put forward issues that should be addressed (even if it is with 
documentation rather than language changes).

Thank you.

-jbs

Re: [Caml-list] Estimating the size of the ocaml community

[Bardur Arantsson]

On Thu, Feb 03, 2005 at 01:58:33PM -0800, Paul Snively wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1


> On Feb 3, 2005, at 1:16 PM, Thomas Fischbacher wrote:
> >(1) I by far do not have the flexibility in extending the language with
> >own syntax which I have in Lisp.

> I have to respectfully disagree with this: IMHO, entirely too much is 
> made of Lisp's macros (as distinct from Scheme's hygenic macros)! With 
> camlp4, I have the ability to go from any concrete syntax I have an 
> expander for to O'Caml's AST and back. This is used to good effect in 
> Graydon Hoare's One Day Compiler presentation.

<rant>
Camlp4 has its own problems which I discovered when writing a parser
generator:


- When using quotations to construct the AST there is often only one (and
usually quite counterintuitive) way to construct a particular AST
fragment. The error messages are incredibly obtuse and when the line
numbers don't work properly this can be a royal PITA to get right.


- There is AFACT no way to "generate" identifiers in generated code so
that they are guaranteed not to clash with identifiers in outer/inner
scopes.


- You cannot verify that the generated AST will actually be valid OCaml
(e.g. free of references to unbound variables) until the generated AST is
compiled. It's not a huge problem, but it means you have to test more for
syntactical(!) corner cases.


Personally, I'm hoping that MetaOCaml (or something similar) will make it
into standard OCaml... but I'm not holding my breath. Of course that
"only" solves the problem of how to generate code in a sane manner. It
doesn't really provide for an easier way to extend the syntax as such.
</rant>


> >(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" 
> >bla).

> I don't quite follow; is there something wrong with Printf?

It can only print simple values, not compound values such as records,
objects, etc... Well, alright, it can use a custom printer, but there
shouldn't really be any need to have to write custom printers for
e.g. records when it's patently obvious how they should be printed (in
the absence of a more specific format).

-- 
Bardur Arantsson
<bardur@imada.sdu.dk>
<bardur@scientician.net>

- That which does not kill you only makes you stranger.
                                MisterQueue | http://kuro5hin.org

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Thu, 3 Feb 2005, josh wrote:

> Thomas Fischbacher wrote:
> 
> > There are quite a few things which I don't like at all about ocaml:
> 
> >(1) I by far do not have the flexibility in extending the language with 
> >own syntax which I have in Lisp.
> >  
> >
> But you do with camlp4.

Well, I don't quite think so. But this would need a more detailed 
discussion. Maybe later, when I find time for this... But I think, at 
least the power of macrolet is a good point in favor of Lisp.

> >(2) Speaking of syntax, there's a lot of unnecessary cruft in virtually 
> >any language besides LISP (or rather, Scheme).
> >  
> >
> I'm going to leave this alone,  Lisp derived languages all have the 
> Parenthesis problem that makes
> them "ugly" as defined by a lot of people.

When I first encountered Lisp, I also found it "ugly", due to the 
parentheses. Only later, I learned to understand. One cannot and 
should not judge this peculiarity of Lisp from the viewpoint of an 
outsider.

I'm pretty sure (1) musical notation, (2) heavy-handed uses of tensor 
notation in supergravity, (3) any other comparable highly specialized 
notational system must look exceedingly scary to the uninitiated as well.

> >(3) The type system is annoying. People claim it helps catching errors, 
> >but my impression is it only catches those which I would never make 
> >anyway. On the other hand, I cannot just have e.g. a function like 
> >POSITION-IF that returns a number or nil. (Either one has to work with 
> >exceptions, or wrap things up using the Maybe monad. Exception techniques 
> >may interfere badly with tail recursion in some cases.)
> >  
> >
> My response is contrived, but does not require monads or exceptions and 
> does basically what you're asking for ( I think):
> 
> type position = Position of int | None;;

That is isomorphic to a straightforward application of the Maybe monad, 
I'd say. After all, you are just boxing up your int here. Furthermore, you 
have to define that particular type globally, as far as I understand it.

> >(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla).
> 
> I don't see how this and Printf are substantially different (except that 
> Printf is type safe),
> could you elaborate?

Erm, what do you do if you want to quickly debug-print a list of vectors 
of pairs?

> >(8) There are quite some instances where Ocaml's syntax is 
> >counter-intuitive to the extent of becoming a source of ugly mistakes, 
> >due to interference with conventions people are used to from other 
> >languages. I do not talk about (p,q) as x vs. x as (p,q) (or x@(p,q)) - 
> >as everyone else (e.g. SML, Haskell) does it, but rather about issues 
> >like for x=0 to 3 counting 0,1,2,3, or "\010" meaning "\x0a" instead of 
> >"\x08", and such.
> >
> This is an idiomatic issue.   I find presence of gender specific 
> suffixes in French to be a problem for me
> because I'm used to the conventions of English.  That does not mean 
> French is wrong,  it means I need to
> learn French better.   

But there is no reason for it to be there in this case.

In contrast, the other camel (perl) goes to great lengths to just behave 
the way people expect it, to the point of being somewhat inconsistent 
(e.g. > print "OK" while 0 < vs. > do{print "OK"} while 0 <).

> >(9) It really annoys having +, +., and +/. Furthermore, it seems a bit 
> >inconsistent, as on the other hand, we have e.g. < and not </.
> >  
> >
> I agree with you here.   This is an issue, but I don't know that it is a 
> major problem.  Also,
> sometimes I do find that it helps to think about the effects of working 
> with floats vs. ints
> especially wrt rounding problems and what not.

Well, yes, as I said, it's just annnoying, not a grave problem. Not having 
closures I would consider as a really grave and really bad thing. But the 
more such small annoyances a language has the less fun it will be.

> I think you've brought up your issues very succinctly and clearly.   I 
> don't agree with all of them,  but you have
> put forward issues that should be addressed (even if it is with 
> documentation rather than language changes).

Well, I'm not a seasoned ocaml expert, but rather a casual user with some 
real-world ocaml battlefield experience (who, accidentally, once learned 
SML and somehow perceives ocaml as kind of a funny dialect, such as 
austrian in comparison to german.) Hence, it may well be the case that I 
just did not know about a few key points I should have a closer look at, 
and I'm quite grateful for all comments that point me in the right 
direction.


Oh, by the way, there is one more thing which I consider a really
grave issue, which gave us quite a lot of grey hair already: Ocaml 
strings have this stupid limitation to 16 MB, which means in particular 
that if you serialize a truly large intermediate state of, say, a long 
and complicated calculation which accidentally got a bit larger than this 
limit (while you did not expect that), well...


-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Thu, Feb 03, 2005 at 10:16:33PM +0100, Thomas Fischbacher wrote:
> (7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla).

IIRC that dumps out the variable 'bla', right?  I wrote a trivial
little library to print out OCaml structures, which I've just checked
in and uploaded here:

http://merjis.com/developers/dumper

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Thu, 3 Feb 2005, Bardur Arantsson wrote:

> > >(7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" 
> > >bla).
> 
> > I don't quite follow; is there something wrong with Printf?
> 
> It can only print simple values, not compound values such as records,
> objects, etc... Well, alright, it can use a custom printer, but there
> shouldn't really be any need to have to write custom printers for
> e.g. records when it's patently obvious how they should be printed (in
> the absence of a more specific format).

Boy, it *does* suck if you just discovered a hairy problem and have to put 
all your time and energy into resolving this and then are 
annoyed/distracted/slowed down by the necessity to work on "ballast code",
like writing special-purpose debug-printing functions ad-hoc.

In Perl, one can at least use Data::Dumper for that purpose, as a 
substitute for Lisp's print/read consistency of structured data(*). 
Whenever I give a perl course, I make sure all my students do know how to 
use it for good.

(*) Which, by the way, is already 95% of what people recently 
"re-discovered" as XML, modulo unnecessarily cluttered syntax and the 
inability to serialize networked, self-referencing values on the one side, 
and i18n on the other.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Sylvain LE GALL]

On Wed, Feb 02, 2005 at 04:31:28PM -0500, Yaron Minsky wrote:
> 
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>   courses.  Any other places that teach the language?  Any ideas on how many
>   students go through these courses?
> 

Hello,

I know that a lot of course of Ecole Polytechnique ( X ) in IT use OCaml
as a support ( maybe it comes from the fact that some OCaml developper are
teaching here : Didier Remy, Luc Maranget... ). I learn OCaml there, and
i still use it on a daily basis / but not at work.

Regard
Sylvain Le Gall

ps : i don't have any problems concerning OCaml, i think it is a great
programming language, i thank the INRIA for giving us such a good tool.

Re: [Caml-list] Estimating the size of the ocaml community

[sejourne_kevin]

thx for the troll.

Kévin.
Regards.

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
> Oh, by the way, there is one more thing which I consider a really
> grave issue, which gave us quite a lot of grey hair already: Ocaml 
> strings have this stupid limitation to 16 MB, which means in particular 
> that if you serialize a truly large intermediate state of, say, a long 
> and complicated calculation which accidentally got a bit larger than this 
> limit (while you did not expect that), well...

Got to agree with you on this one ...  At least we'll soon all be
using 64 bit computers where OCaml doesn't suffer this limitation.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Michael Walter]

On Fri, 4 Feb 2005 00:22:47 +0100 (CET), Thomas Fischbacher wrote:
> When I first encountered Lisp, I also found it "ugly", due to the
> parentheses. Only later, I learned to understand. One cannot and
> should not judge this peculiarity of Lisp from the viewpoint of an
> outsider.
> 
> I'm pretty sure (1) musical notation, (2) heavy-handed uses of tensor
> notation in supergravity, (3) any other comparable highly specialized
> notational system must look exceedingly scary to the uninitiated as well.

I think part of the problem is that those are domain-specific
notations, whereas S-expressions are used for general purpose (in the
domain of expressing programs = data).

Differently put, in that they are syntax they try to cover a "broader"
(not in the "there are xxx musicians and yyy coders" sense) domain
than in what they are useful (the domain of generically representing
expressions).

A naive and not quite matching example of what I mean is that musical
notation isn't used for encoding sample data.

Some ex-developer of the Dylan language makes some interesting points
about S expressions in a response to Arc (in the feedback on Arc text
file on paulgraham.com).

Michael

Re: [Caml-list] Estimating the size of the ocaml community

[Jon Harrop]

On Thursday 03 February 2005 21:16, Thomas Fischbacher wrote:
> (3) The type system is annoying. People claim it helps catching errors,
> but my impression is it only catches those which I would never make
> anyway.

Static type checking is completely fundamental to OCaml. Consequently, I think 
that's a really silly thing to say here but your next comment implies that 
you don't know what static type checking is for:

> On the other hand, I cannot just have e.g. a function like 
> POSITION-IF that returns a number or nil. (Either one has to work with
> exceptions, or wrap things up using the Maybe monad. Exception techniques
> may interfere badly with tail recursion in some cases.)

I think you will find that "int option" does exactly what you want whilst also 
statically type checking the result.

Let me recite my personal experience with static type checking. A couple of 
years ago, C++ was my latest language. I developed a significant project in 
C++ until I realised that the core of my implementation was fundamentally 
flawed and needed rewriting in order to achieve my objectives. This rewrite 
would have taken over a month. Thus, I gave up. Later, I decided to learn 
ocaml and porting my project seemed like a worthy task. The ported code was 
1/4 as long and almost as fast. I've made two more fundamental changes since 
then, both of which would have been infeasible in C++.

When using C++, I always had to restrain myself from making major changes, as 
they were bound to break the program and were often irreparable. In contrast, 
when I make a fundamental change to the ocaml implementation, the static type 
checker immediately leads me to all of the new misuses of the altered code. 
This allows me to make much deeper changes without having to worry about 
spending months debugging the surrounding code. The last time I made such a 
change it took a day to get the program working again, rather than a month.

Thanks to all these major changes, the latest ocaml version is vastly faster 
than the old C++. :-)

> (4) There are a few other minor issues, such as a lack of
> multiple-value-bind, which I personally find slightly annoying, but
> not essential.

I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c = 1, 
2, 3".

> (9) It really annoys having +, +., and +/.

There is a trade-off between type checking and operator overloading. This has 
been discussed at great length before and a lot of interesting information 
can be found by perusing the mailing list archives.

I shall remain skeptical that GCaml improves upon this solution this until I 
get to write a decent-sized project in GCaml. I am keen to see GCaml though.

> Furthermore, it seems a bit 
> inconsistent, as on the other hand, we have e.g. < and not </.

The arithmetic operators have types '_a -> '_a -> '_a for some 'a whereas the 
comparisons have types 'a -> 'a -> bool for all 'a. This is because 
arithmetic operators are well-defined for some types (e.g. int and float) but 
there are well-defined comparison operators for all but some types (i.e. 
except closures). Hence the use of monomorphic and polymorphic types (and 
exceptions), respectively.

Again, this has already been discussed at length on the mailing list.

On Thursday 03 February 2005 23:22, Thomas Fischbacher wrote:
> > type position = Position of int | None;;
>
> That is isomorphic to a straightforward application of the Maybe monad,
> I'd say. After all, you are just boxing up your int here. Furthermore, you
> have to define that particular type globally, as far as I understand it.

Use the "'a option" type defined in Pervasives.

> > I don't see how this and Printf are substantially different (except that
> > Printf is type safe),
> > could you elaborate?
>
> Erm, what do you do if you want to quickly debug-print a list of vectors
> of pairs?

Use the top-level.

On Thursday 03 February 2005 23:39, Richard Jones wrote:
> On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
> > Oh, by the way, there is one more thing which I consider a really
> > grave issue, which gave us quite a lot of grey hair already: Ocaml
> > strings have this stupid limitation to 16 MB, which means in particular
> > that if you serialize a truly large intermediate state of, say, a long
> > and complicated calculation which accidentally got a bit larger than this
> > limit (while you did not expect that), well...
>
> Got to agree with you on this one ...  At least we'll soon all be
> using 64 bit computers where OCaml doesn't suffer this limitation.

Yes. In the mean time, I'm using lists of O(1)-length strings, which is 
working well.

I'd obviously like more comprehensive standard library and bindings to other 
libraries but, as far as the core language goes, I vote for (for these 
reasons):

1. Arbitrary-length strings and arrays. (robustness)
2. Version- and type-safe marshalling. (robustness)
3. Compiler warnings when run-time type errors may occur, e.g. when 
marshalling a data structure which might contain a closure. (robustness)
4. Extensible strings and arrays. (asymptotic complexity)
5. More pattern matching: [|1; 2; ...|] and [|...; 2; 1|]. (expressivity)
6. Dynamic code generation. (to ease compiler writing)
7. More optimisation, e.g. inlining across functors built-in to the compiler. 
(performance)

If there were a redesign, I'd ask for "string" as "char array" and 
monomorphisation of polymorphic functions. Perhaps the latter can be achieved 
with a preprocessor?

Anyhow, despite these few and minor shortcomings, OCaml is by far the best 
language I have ever come across.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.

[Caml-list] Estimating the size of the ocaml community

[Michael Walter]

On Fri, 4 Feb 2005 02:33:40 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > On the other hand, I cannot just have e.g. a function like
> > POSITION-IF that returns a number or nil. (Either one has to work with
> > exceptions, or wrap things up using the Maybe monad. Exception techniques
> > may interfere badly with tail recursion in some cases.)
>
> I think you will find that "int option" does exactly what you want whilst also
> statically type checking the result.
Although you can certainly disagree with the judgement (which I will
freely paraphrase with "using Maybe is inelegant"), I cannot see how
you are able to judge Thomas' knowledge of the usefulness of static
type checking based on a statement which you comment by partly
repeating what he said ;-)

> Let me recite my personal experience with static type checking. A couple of
> years ago, C++ was my latest language. I developed a significant project in
> C++ until I realised that the core of my implementation was fundamentally
> flawed and needed rewriting in order to achieve my objectives. This rewrite
> would have taken over a month. Thus, I gave up. Later, I decided to learn
> ocaml and porting my project seemed like a worthy task. The ported code was
> 1/4 as long and almost as fast. I've made two more fundamental changes since
> then, both of which would have been infeasible in C++.
Interesting. In my experience it's similarly simple to refactor in C++
as in languages with more sophisticated type systems (to answer the
obligatory question, yes, I'm working on large projects). I've had
similar experiences with dynamic languages like Scheme and Python,
though (compared to statically typed ones).

> When using C++, I always had to restrain myself from making major changes, as
> they were bound to break the program and were often irreparable. In contrast,
> when I make a fundamental change to the ocaml implementation, the static type
> checker immediately leads me to all of the new misuses of the altered code.
> This allows me to make much deeper changes without having to worry about
> spending months debugging the surrounding code. The last time I made such a
> change it took a day to get the program working again, rather than a month.
Are you using heavy casting and such without proper abstractions in
your C++ code? Pr what kind of changes did you want to make? How did
you feel that the static type checker of C++ didn't provide you with
similar help?

> Thanks to all these major changes, the latest ocaml version is vastly faster
> than the old C++. :-)
>
> > (4) There are a few other minor issues, such as a lack of
> > multiple-value-bind, which I personally find slightly annoying, but
> > not essential.
>
> I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c = 1,
> 2, 3".
It's a macro in Common Lisp (see [1]). In O'caml-ish syntax, it also
does "let a, b = 1, 2, 3" (3 is discarded) and "let a, b, c = 1, 2" (c
is bound to nil).

> > (9) It really annoys having +, +., and +/.
>
> There is a trade-off between type checking and operator overloading. This has
> been discussed at great length before and a lot of interesting information
> can be found by perusing the mailing list archives.
>
> I shall remain skeptical that GCaml improves upon this solution this until I
> get to write a decent-sized project in GCaml. I am keen to see GCaml though.
FWIW, I find this works lovely in Haskell. :-)

Michael

[1] http://www.lisp.org/HyperSpec/Body/mac_multiple-value-bind.html

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Fri, 2005-02-04 at 07:50, chris.danx wrote:

> > (b) native code compiler on x86 can't make a shared library

> I didn't realise the native code compiler on x86 couldn't do this.  What 
> exactly is the problem?

Xavier doesn't rate the work involved a high priority.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] Estimating the size of the ocaml community

[Ville-Pertti Keinonen]

On Thu, 2005-02-03 at 22:16 +0100, Thomas Fischbacher wrote:

> There are quite a few things which I don't like at all about ocaml:

I hope you don't mind getting yet another set of comments...

> (1) I by far do not have the flexibility in extending the language with 
> own syntax which I have in Lisp.

This is true.

> (2) Speaking of syntax, there's a lot of unnecessary cruft in virtually 
> any language besides LISP (or rather, Scheme).

Usually what someone considers "unnecessary cruft" is defined by what
they're used to.  People are used to the annoyances of the languages
they use the most and don't tend to notice them, but when using a less
familiar language, pay a lot of attention to anything that seems more
cumbersome.

As an obvious example, neither Common Lisp or Scheme have
pattern-matching.  Accessing data via pattern matching is often far more
convenient than via c[ad]+r, slot accessors etc.  While many Scheme
implementations do have pattern matching as an extension, the syntax is
more verbose and it doesn't give you the nice symmetry between
constructing and deconstructing values.

In my experience, unless you're using a lot of "ad hoc" data structures
or not checking for errors, OCaml is usually less verbose than Scheme.
When comparing to Common Lisp...it depends on how much magic you're
using.

> (6) I cannot easily COMPILE a function to fast machine code from the REPL.

A runtime for OCaml that would be more like Common Lisp implementations
or SML/NJ would be an interesting project.

I don't think it would be too difficult, either (based on experimenting
with replacing the asmcomp back-end).

> (7) I cannot easily (format t "DEBUG: compsite-thingy-bla-now-is ~A~%" bla).

This could also be addressed by a more advanced runtime that always
included the top-level.

Re: [Caml-list] Estimating the size of the ocaml community

[Frédéric Gava]

> On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
> > Oh, by the way, there is one more thing which I consider a really
> > grave issue, which gave us quite a lot of grey hair already: Ocaml
> > strings have this stupid limitation to 16 MB, which means in particular
> > that if you serialize a truly large intermediate state of, say, a long
> > and complicated calculation which accidentally got a bit larger than
this
> > limit (while you did not expect that), well...
>
> Got to agree with you on this one ...  At least we'll soon all be
> using 64 bit computers where OCaml doesn't suffer this limitation.
>
> Rich.
> Richard Jones, CTO Merjis Ltd.

Also agree with you.  This limitation is sometime a problem for me. I code a
library in Ocaml
for parallel computing, thus I always serialize values and I could not bench
programs which put on the networks, very big values. But this problem is a
problem of the implementation and not a problem of language design. Maybe in
the futur, this limitation would be deleted. "Int" are also limited (except
using num.cma) and so "string" are limited for  an access reason. Peraps in
the futur, we could serialize values to another things than string (another
data structure) and unmarshaled those sepcial data structures to
values....and having  only 4 functions:
to_channel: out_channel -> 'a -> extern_flags list -> unit
from_channel: in_channel -> 'a
to_serialize: 'a -> extern_flags list -> t
from_serialize: t -> 'a
where t is an abstract data type of marshaled values....

Regards,
Frédéric Gava

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Jon Harrop wrote:

> > (3) The type system is annoying. People claim it helps catching errors,
> > but my impression is it only catches those which I would never make
> > anyway.
> 
> Static type checking is completely fundamental to OCaml. Consequently, I think 
> that's a really silly thing to say here but your next comment implies that 
> you don't know what static type checking is for:

Well, I might want to differ here, but I should perhaps also add that I 
indeed do only know about as much about the structure of the 
Hindley-Milner-like type system of Ocaml as is the common subset of 
Haskell, SML/NJ and Ocaml.

Yes, it's fundamental to those languages, and indeed I originally thought 
this would be a great thing, years ago, when I came to SML/NJ from C++. 
Right now, after a few years of Lisp experience, my personal impression is 
that actually, it is more a hindrance than a help. But of course, one may 
always say that we Lisp hackers just are spoilt by our language in this 
aspect. By the way, Paul Graham seems not to like the ML family for about 
precisely the same reason.

One issue with the type system is that, looking closely, there are at 
least two (perhaps three) very different tasks it tries to do, which 
superficially look like being the same, but actually are very different, 
and indeed, in many situations, it may be much more appropriate to 
address them specifically and individually than with an unified approach.

(1) Prevent the programmer from "accidentally plugging an electrical 
shaver into a power high-voltage outlet".

(2) Give the compiler hints how to optimize certain manipulations in terms 
of machine instructions.

Concerning (1), from the machine point of view, there is no difference 
between a floatingpoint number representing a length in meters and a 
floatingpoint number representing a length in feet. Nevertheless, one 
should not blindly add the one to the other, as NASA by now surely can 
tell you. And indeed, the system of physical units, be it SI or something 
even more elaborate, exists precisely to prevent such problems, yet there 
are aspects of this "type system", which has proven its value, which can 
not be mapped to Hindley-Milner.

If I multiply a speed (in m/s) with a mass (in kg),
I get a momentum (in kg m/s), which I neither can sensibly add to a 
speed, or a mass. If I further consider a change in momentum with time, I 
automatically get something with units kg m/s^2, that is, a force.

Of course, I could introduce types for all intermediate quantities which I 
will encounter in a problem statically. However, there are many problems 
where I do not know a priori which quantities will appear with which 
powers, hence I would like to have this with full dynamical flexibility. 
Please prove me wrong if I am missing something here, but to me it seems 
that even for this simple "real-world type system" example, there is no 
way to directly map this to H.M. in the way explained here.

And this is only *one* example. There are many more, of structures that 
morally qualify as type systems, but cannot be related to H.M.

> > (4) There are a few other minor issues, such as a lack of
> > multiple-value-bind, which I personally find slightly annoying, but
> > not essential.
> 
> I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c = 1, 
> 2, 3".

Let's take a specific example.

* (/ 1234 100)

617/50
* (round 1234 100)

12
34

The division function in LISP returns one value. The ROUND function 
returns two. If I use it as in 

* (+ 5 (round 1234 100))

17

it behaves as if it were a function that gives me only the primary value. 
But if I want it, I also can bind and process the secondary (or even 
higher) extra values returned by that function.

So it's even more than "just returning more than one value without having 
to cons" (which already is quite nice - but this essentially can always be 
emulated via going to CPS, which establishes full call/return symmetry). 
It's about giviny gou extra choice. Either: "Nice that you can also 
provide me extra information, but I really don't care here", or: "I can 
as well make use of this other piece of information which you 
already obtained anyway." Same function, same call.

> > (9) It really annoys having +, +., and +/.
> 
> There is a trade-off between type checking and operator overloading. This has 
> been discussed at great length before and a lot of interesting information 
> can be found by perusing the mailing list archives.

Sure. I don't quite know what to think about Haskell's type classes, but 
superficially it feels quite much more convenient. Anyway, it may as well 
be here that the impression which one gets by working heavily with it is 
a different one, so I'll keep an eye on that but surely not take it as the 
only True Revelation.

> > > I don't see how this and Printf are substantially different (except that
> > > Printf is type safe),
> > > could you elaborate?
> >
> > Erm, what do you do if you want to quickly debug-print a list of vectors
> > of pairs?
> 
> Use the top-level.

That entirely misses the point!

I talked about getting debug traces from an involved run.

> Anyhow, despite these few and minor shortcomings, OCaml is by far the best 
> language I have ever come across.

Nice if it suits you well. I personally experience some friction with 
it, however.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Ville-Pertti Keinonen wrote:

> > (2) Speaking of syntax, there's a lot of unnecessary cruft in virtually 
> > any language besides LISP (or rather, Scheme).
> 
> Usually what someone considers "unnecessary cruft" is defined by what
> they're used to.  People are used to the annoyances of the languages
> they use the most and don't tend to notice them, but when using a less
> familiar language, pay a lot of attention to anything that seems more
> cumbersome.
> 
> As an obvious example, neither Common Lisp or Scheme have
> pattern-matching.  Accessing data via pattern matching is often far more
> convenient than via c[ad]+r, slot accessors etc.

Sure! But Lisp gives me the freedom to add it via a library. Which also 
kind of says that it's unnecessary to complicate the core language by 
putting in such a conceptually ad-hoc feature.

Of course, from the LISP point of view, virtually anything that's done by 
other languages is conceptually ad-hoc, and can easily be added by 
extending the language. ;-)

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Fri, Feb 04, 2005 at 10:04:20AM +0100, Fr?d?ric Gava wrote:
> But this problem is a problem of the implementation and not a
> problem of language design. Maybe in the futur, this limitation
> would be deleted.

It's a problem of the implementation, but one which looks hard to
change.  The reason it arises is because each OCaml value has a 4
byte[*] header, divided into a 1 byte tag, 2 bits for the GC, and the
remaining 22 bits to store the size of the value in words.  Since
strings are stored directly in the value (which is very efficient),
they are limited to 4 * (2^22 - 1) bytes ~ 16 MB in size.  Any other
representation would penalise the common case (short strings) - for
example, having strings represented as a (length, pointer) tuple would
cause an extra indirection; and having long strings represented with a
special "all 1s" length would penalise the code all over the place.

So not easy to fix.

Rich.

[*] On 32-bit platforms.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Fri, Feb 04, 2005 at 02:33:40AM +0000, Jon Harrop wrote:
> 5. More pattern matching: [|1; 2; ...|] and [|...; 2; 1|]. (expressivity)

And this pattern which could be used all the time in web programming:

 | "prefix" ^ str ->

8. Regular expressions in the language!

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Richard Jones wrote:

> 8. Regular expressions in the language!

There's a library for it. And indeed, looking at the evolution of perl, I 
would say that the way how regexps are integrated there is a mistake.

The problem is that they are static in original perl.


Last time I gave a course on perl, I found out that there is a very nice 
and convenient way to systematically explore many of its design mistakes: 
take language feature X (arrays, regexps, functions, whatever), and ask 
to yourself the question: how would you write a function that takes as 
argument a number N and generates N entities of the thingy under 
consideration that are provably different (and actually does prove this).

Perl's arrays are very different from arrays in almost any other language 
- they try to catch a natural-language "plural" concept. But when one 
wants to address "this collection" directly, instead of just "those 
values", one needs a different handle.

Original attempts to address such questions involved some - I'd say highly 
misguided - "symbolic reference to variable name" approaches. They more or 
less have been abandoned now, for good ("use strict"). By now, perl has 
an anonymous array constructor [].


Concerning regexps, one originally could make them dynamical only via

/$interpolation/

...but then, they have to be recompiled every time they are executed. 
Hence, people "added state to locations in the code" (as they 
previously did with ".." and such) and provided /o.

Of course, this also turned out to be stupid! Think about passing 
different regexps into a function.

So, by now, we *in addition* have

qr()

and some further quite ugly compiled-regexp-interpolation mechanism.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Olivier Andrieu]

 > Frédéric Gava [Fri, 4 Feb 2005]:
 > > On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher
 > > wrote:
 > > > Oh, by the way, there is one more thing which I consider a
 > > > really grave issue, which gave us quite a lot of grey hair
 > > > already: Ocaml strings have this stupid limitation to 16 MB,
 > > > which means in particular that if you serialize a truly large
 > > > intermediate state of, say, a long and complicated calculation
 > > > which accidentally got a bit larger than this limit (while you
 > > > did not expect that), well...
 > >
 > > Got to agree with you on this one ...  At least we'll soon all be
 > > using 64 bit computers where OCaml doesn't suffer this
 > > limitation.
 > >
 > > Rich.
 > > Richard Jones, CTO Merjis Ltd.
 > 
 > Also agree with you.  This limitation is sometime a problem for
 > me. I code a library in Ocaml for parallel computing, thus I always
 > serialize values and I could not bench programs which put on the
 > networks, very big values. 

AFAIK Marshal.{to,from}_channel isn't limited by the maximum string
length.

-- 
   Olivier

Re: [Caml-list] Estimating the size of the ocaml community

[Andreas Rossberg]

Thomas Fischbacher wrote:
> 
> One issue with the type system is that, looking closely, there are at 
> least two (perhaps three) very different tasks it tries to do, which 
> superficially look like being the same, but actually are very different, 
> and indeed, in many situations, it may be much more appropriate to 
> address them specifically and individually than with an unified approach.
> 
> (1) Prevent the programmer from "accidentally plugging an electrical 
> shaver into a power high-voltage outlet".

In my personal experience, this is absolutely essential when you go 
higher-order in non-trivial ways - dynamic type errors won't give you 
the slightest clue when you screw up some combinator plugging. 
(Incidentally, Lisp also isn't very well suited for higher-order 
programming, because of its syntax issues: no light-weight application 
syntax and currying.)

> (2) Give the compiler hints how to optimize certain manipulations in terms 
> of machine instructions.

The latter is actually the least important point. More significant are:

(3) Verified documentation. Provide a stylised language for describing 
interfaces, and have the compiler actually check these "comments", so 
that they never get out of date.

(4) Maintenance. Provide guidance when modifying a program non-locally 
by letting the compiler point out the locations of the minimum set of 
obliged changes.

(5) Abstraction. Enable the programmer to define her own abstract types, 
for compile-time encapsulation and invariant enforcement.

The latter is also known as "typeful programming" (cf. Luca Cardelli's 
seminal article of the same name). That is where advanced type systems 
really start to score, and what people with arguments of the sort "a 
type system only catches trivial errors" usually overlook completely.

Type abstraction may not be powerful enough to fully capture units, but 
it goes a long way. And you cannot seriously argue that something is 
useless because it does not cover everything.

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

Let's get rid of those possible thingies!  -- TB

Re: [Caml-list] The boon of static type checking

[Jon Harrop]

On Friday 04 February 2005 02:56, Michael Walter wrote:
> On Fri, 4 Feb 2005 02:33:40 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > The last time I made such a change it took a day to get
> > the program working again, rather than a month.
>
> Are you using heavy casting and such without proper abstractions in
> your C++ code?

No. The code is freely available here:

http://www.chem.pwf.cam.ac.uk/~jdh30/programming/opengl/smoke/index.html

> Pr what kind of changes did you want to make?

IIRC, one development was to change the core data structure from a list to a 
tree. The code to implement a simple tree is unwieldy in C++ (e.g. 1975 LOC 
in stl_tree.h and stl_map.h vs 198 LOC in map.ml). My ocaml implementation 
uses trees and graphs throughout now.

> How did  
> you feel that the static type checker of C++ didn't provide you with
> similar help?

As the C++ type system cannot represent (and, therefore, statically check) 
polymorphism properly, altering a generic data structure expressed using 
templates results in reams of errors, mostly pointing to wrong places. In 
contrast, the worst I get with ocaml is an error in the wrong place because a 
previous function has been inferred to have a wrong type. Even this problem 
is much less common and trivial to trace. Also, it would be even easier to 
solve with an IDE which threw up the inferred types.

As the C++ type system cannot represent (and, therefore, statically check) 
modules and variant types, shoehorning solutions into using class hierarchies 
and being forced to use pointers results in verbose code and weaker type 
checking. In contrast, the equivalent ocaml code is succinct and thoroughly 
checked. This brevity can also be attributed to the ability to pattern match.

Obviously such problems would have been virtually impossible to weed out had I 
chosen to use a language with dynamic type checking, which is precisely I why 
I left such languages at the door many years ago...

> > I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c
> > = 1, 2, 3".
>
> It's a macro in Common Lisp (see [1]). In O'caml-ish syntax, it also
> does "let a, b = 1, 2, 3" (3 is discarded) and "let a, b, c = 1, 2" (c
> is bound to nil).

These seem pretty pointless to me, but what about:

# let {a=a; b=b; c=_} = expr;;

or

# let x = expr in
  ... x.a ... x.b ...;;

and then

# let (a, b), c = expr, None;;

(if you must).

On Friday 04 February 2005 09:29, Thomas Fischbacher wrote:
> If I multiply a speed (in m/s) with a mass (in kg)...

Yes, absolutely! I believe you have correctly identified dimensionality as a 
very important and useful system of (phantom) types used in physics. The 
OCaml type system goes some way to allowing such things to be enforced. 
Dynamically typed languages do not. So how can you come to the conclusion 
than going from dynamic typing to OCaml's static typing is a step in the 
wrong direction?

> So it's even more than "just returning more than one value without having
> to cons" (which already is quite nice - but this essentially can always be
> emulated via going to CPS, which establishes full call/return symmetry).
> It's about giviny gou extra choice. Either: "Nice that you can also
> provide me extra information, but I really don't care here", or: "I can
> as well make use of this other piece of information which you
> already obtained anyway." Same function, same call.

Sure, but what's wrong with using fst and snd for pairs, and records instead 
of n-tuples? You get the same functionality and an explicit definition of 
what is happening with only a couple of extra key strokes.

> > Use the top-level.
>
> That entirely misses the point!
>
> I talked about getting debug traces from an involved run.

Which you can do from the top level. If you have to output the information 
from a running, native-code compiled binary then write the print and 
string_of functions yourself:

let string_of_list f l = "["^String.concat "; " (List.map f l)^"]"
let string_of_pair f (a, b) = "("^f a^", "^f b^")"
print_endline (string_of_list (string_of_pair string_of_int) x)

Considering the first two can be factored out of a wide variety of programs, 
it really isn't a huge amount of typing...

On Friday 04 February 2005 09:41, you wrote:
> On Fri, Feb 04, 2005 at 02:33:40AM +0000, Jon Harrop wrote:
> > 5. More pattern matching: [|1; 2; ...|] and [|...; 2; 1|]. (expressivity)
>
> And this pattern which could be used all the time in web programming:
>  | "prefix" ^ str ->
>
> 8. Regular expressions in the language!

Nooo! Got to stick to O(1) pattern matching, so you are allowed either of:

| "prefix" ^ ... -> expr
| ... ^ "suffix" -> expr

but neither of your suggestions. :-)

9. Complex number notation.

On Friday 04 February 2005 09:36, Thomas Fischbacher wrote:
> On Fri, 4 Feb 2005, Ville-Pertti Keinonen wrote:
> > As an obvious example, neither Common Lisp or Scheme have
> > pattern-matching.  Accessing data via pattern matching is often far more
> > convenient than via c[ad]+r, slot accessors etc.
>
> Sure! But Lisp gives me the freedom to add it via a library. Which also
> kind of says that it's unnecessary to complicate the core language by
> putting in such a conceptually ad-hoc feature.

That's obviously completely wrong and a blatant troll so I'll stop replying 
now.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Thu, Feb 03, 2005 at 10:16:33PM +0100, Thomas Fischbacher wrote:
[...]
> (3) The type system is annoying. People claim it helps catching errors, 
> but my impression is it only catches those which I would never make 
> anyway.
[...]

Well if it catches only errors you never make, you should
never had any warnings nor error messages from the type
system.
So, why is it annoying, if you never get a warning/error message?

Normally you should not be aware of the type system, because you
do not make type-system-errors.

?!


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
[...] 
> Oh, by the way, there is one more thing which I consider a really
> grave issue, which gave us quite a lot of grey hair already: Ocaml 
> strings have this stupid limitation to 16 MB, which means in particular 
> that if you serialize a truly large intermediate state of, say, a long 
> and complicated calculation which accidentally got a bit larger than this 
> limit (while you did not expect that), well...

Well, maybe there should be a BigStrings- or LongStrings-Module
introduced into OCaml-stdlib?

But: When you mean with "a long and complicated calculation"
using larger int/float-values you may use
the num-library.
E.g. in module Num there is a  string_of_num-function.
Do you really think, the results will be larger than 16MB?

Or what kind of computation do you think about?

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Thu, Feb 03, 2005 at 11:39:50PM +0000, Richard Jones wrote:
> On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher wrote:
> > Oh, by the way, there is one more thing which I consider a really
> > grave issue, which gave us quite a lot of grey hair already: Ocaml 
> > strings have this stupid limitation to 16 MB, which means in particular 
> > that if you serialize a truly large intermediate state of, say, a long 
> > and complicated calculation which accidentally got a bit larger than this 
> > limit (while you did not expect that), well...
> 
> Got to agree with you on this one ...  At least we'll soon all be
> using 64 bit computers where OCaml doesn't suffer this limitation.

Well, but even on those computers will be restrictions in the size.
And I'm sure that with more powerful computers, there will be
more ressource-needing applications/calculations/computations
and so maybe there will be another problem then (maybe it needs
some decades to reach that limit?).

Is the 16MB string-length really a hardware-dependency?
Maybe changing string-representation could help even
on 32 Bit machines to have not such a problem.
But maybe a BigStrings/LongStrings-module would do that
better (because changing the string-representation in the OCaml-core
may be a harder problem...?!)

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Frédéric Gava]

> AFAIK Marshal.{to,from}_channel isn't limited by the maximum string
> length.
>...
>    Olivier

OK. Right but you can not all the time used channels... For TCP/IP, that is
possible, but for low level libraries (as MPI, PVM, PUB etc...) you need
strings and you are blocked by this limitation (except if you read the
values from a file but in this case it is not a fast solution).

>It's a problem of the implementation, but one which looks hard to
>change.  The reason it arises is because each OCaml value has a 4
>byte[*] header, divided into a 1 byte tag, 2 bits for the GC, and the
>remaining 22 bits to store the size of the value in words.  Since
>strings are stored directly in the value (which is very efficient),
>they are limited to 4 * (2^22 - 1) bytes ~ 16 MB in size.
>...
>Richard Jones, CTO Merjis Ltd.
Sure it is a hard problem. But I thinks that in the futur (now my bench are
not bench of true applications but bench of the limits of the language,
values that exceed 16Mo are rare), true scientific applications will need to
serialize big values...(big graphs for example)


Frédéric Gava

Re: [Caml-list] Estimating the size of the ocaml community

[Richard Jones]

On Fri, Feb 04, 2005 at 12:14:31PM +0100, Fr?d?ric Gava wrote:
> >It's a problem of the implementation, but one which looks hard to
> >change.  The reason it arises is because each OCaml value has a 4
> >byte[*] header, divided into a 1 byte tag, 2 bits for the GC, and the
> >remaining 22 bits to store the size of the value in words.  Since
> >strings are stored directly in the value (which is very efficient),
> >they are limited to 4 * (2^22 - 1) bytes ~ 16 MB in size.
> Sure it is a hard problem. But I thinks that in the futur (now my bench are
> not bench of true applications but bench of the limits of the language,
> values that exceed 16Mo are rare), true scientific applications will need to
> serialize big values...(big graphs for example)

I've been thinking about this a bit more, and I'm not sure I
understand why the tag needs to be so large.  If you look at the "tag
space" now, it's something like this:

0	used for tuples, arrays, records
1-251	used for constructors (eg. Some, None)
252	marks strings
253 	marks floats
254	marks float arrays
255	marks structures with custom ops (lots of stuff, like Int32.t)

It's not clear to me why so much "tag space" is used for constructed
values, at the same time limiting you to around 250 different
constructors in a type definition.  Couldn't the constructor number be
encoded in the first field in the value (obviously shifting all the
subsequent fields along one, and making constructed values 4 bytes
larger)?  Then the tag could be reduced to a few bits, making strings
a few orders larger.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Olivier Andrieu]

 > Frédéric Gava [Fri, 4 Feb 2005]:
 > > AFAIK Marshal.{to,from}_channel isn't limited by the maximum
 > > string length.
 > >...
 > >    Olivier
 > 
 > OK. Right but you can not all the time used channels... For TCP/IP,
 > that is possible, but for low level libraries (as MPI, PVM, PUB
 > etc...) you need strings and you are blocked by this limitation
 > (except if you read the values from a file but in this case it is
 > not a fast solution).

If you're interfacing with a C library you have yet another option :
serialize to a malloc block. That's what these low level libraries
should use. 

,----[ intext.h ]
| CAMLextern void caml_output_value_to_malloc(value v, value flags,
|                                             /*out*/ char ** buf,
|                                             /*out*/ long * len);
| CAMLextern value caml_input_value_from_malloc(char * data, long ofs);
`----

-- 
   Olivier

Re: [Caml-list] Estimating the size of the ocaml community

[Marcin 'Qrczak' Kowalczyk]

Richard Jones <rich@annexia.org> writes:

> 0	used for tuples, arrays, records
> 1-251	used for constructors (eg. Some, None)
> 252	marks strings
> 253 	marks floats
> 254	marks float arrays
> 255	marks structures with custom ops (lots of stuff, like Int32.t)
>
> It's not clear to me why so much "tag space" is used for constructed
> values, at the same time limiting you to around 250 different
> constructors in a type definition.  Couldn't the constructor number be
> encoded in the first field in the value (obviously shifting all the
> subsequent fields along one, and making constructed values 4 bytes
> larger)?  Then the tag could be reduced to a few bits, making strings
> a few orders larger.

If all constructed values were larger, it would be a noticeable
overhead. For example a list of ints would take 4/3 times more space
than currently.

IMHO a better design would distinguish fixed size blocks from variable
length blocks and enlarge only the latter. For example:
- fixed size blocks: 15 bits of the tag, 15 bits of the size
  (assuming a 32-bit platform)
- variable size blocks (arrays and strings): a special value in the
  header, the actual length is in the next field

As for unifying strings with char arrays, it would make all array
accesses slower. They already have a performance hit because of float
arrays; in particular almost all functions from the Array module make
a conditional jump for float arrays in their inner loops.

IMHO it would be better if float arrays were a separate type, and the
type system would somehow allow writing code which is generic wrt. the
type of the sequence. Then more kinds of arrays could be added without
increasing the overhead for plain arrays, e.g. bool arrays as packed
bits.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Re: [Caml-list] Estimating the size of the ocaml community

[Gerd Stolpmann]

Richard Jones said:
> I've been thinking about this a bit more, and I'm not sure I
> understand why the tag needs to be so large.  If you look at the "tag
> space" now, it's something like this:
>
> 0	used for tuples, arrays, records
> 1-251	used for constructors (eg. Some, None)
> 252	marks strings
> 253 	marks floats
> 254	marks float arrays
> 255	marks structures with custom ops (lots of stuff, like Int32.t)
>
> It's not clear to me why so much "tag space" is used for constructed
> values, at the same time limiting you to around 250 different
> constructors in a type definition.  Couldn't the constructor number be
> encoded in the first field in the value (obviously shifting all the
> subsequent fields along one, and making constructed values 4 bytes
> larger)?  Then the tag could be reduced to a few bits, making strings a
> few orders larger.

Sure, this is an option, but I think the price is quite high. A number of
frequently used data structures would need a lot more memory, and would
become slower. For example lists. Currently, every list element needs
three words (header + contents + reference to next element). If the
variant tag is not part of the header, another word is needed = 33 %
more space. There are similar effects for many basic data
structures, including options, trees and hash tables.

>From a practical point of view, the non-polymorphic variants are still
part of the language because they are more efficient than the polymorphic
counterparts (which could fully replace the former, and for which there
is no limit for the number of constructors).

If one wanted really to improve the situation, it would be better to change
the representation of strings, and to encode the string length in the
first word after the header. This wastes much less memory (except in the
special case when you have many small strings), and is probably neutral
for the execution speed.

Gerd
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

Re: [Caml-list] Estimating the size of the ocaml community

[Richard W. M. Jones]

On Fri, Feb 04, 2005 at 01:51:36PM +0100, Gerd Stolpmann wrote:
> Sure, this is an option, but I think the price is quite high. A number of
> frequently used data structures would need a lot more memory, and would
> become slower. For example lists. Currently, every list element needs
> three words (header + contents + reference to next element). If the
> variant tag is not part of the header, another word is needed = 33 %
> more space. There are similar effects for many basic data
> structures, including options, trees and hash tables.

Actually, I wouldn't want to change lists.  Those currently have a tag
= 0, and it would important to leave those untouched for exactly the
reason you described.

Of course, now you've pointed out the flaw in my argument, which is
that lists would be handled differently from constructs :-)

> If one wanted really to improve the situation, it would be better to change
> the representation of strings, and to encode the string length in the
> first word after the header. This wastes much less memory (except in the
> special case when you have many small strings), and is probably neutral
> for the execution speed.

But then you'd need a special case to handle values-containing-
strings, vs. values-not-containing strings, because you'd always want
to have the size attribute of the header reflect the size of the data
in the value.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 10:29:53AM +0100, Thomas Fischbacher wrote:

[...]
> If I multiply a speed (in m/s) with a mass (in kg),
> I get a momentum (in kg m/s), which I neither can sensibly add to a 
> speed, or a mass. If I further consider a change in momentum with time, I 
> automatically get something with units kg m/s^2, that is, a force.
> 
> Of course, I could introduce types for all intermediate quantities which I 
> will encounter in a problem statically. However, there are many problems 
> where I do not know a priori which quantities will appear with which 
> powers, hence I would like to have this with full dynamical flexibility. 

So, you have to decide, what you want: Flexibility or not?
If you want clearly typed values, you can use a language
that supports it. If not, use a language that ignores types.

But as you said above: Yes, it's necessary to have distinct types that
doesn't match and are clearly distinct and incompatible to
avoid problems where mixing up different types would be a problem.

In your example: "a momentum (in kg m/s), which I neither can sensibly
 add to a speed, or a mass."

So strictly checking types is really helpful here.

In OCaml you can use the module system to be helpful here (abstract data types).
It is possible to define incompatible types, which are also can be restricted
by value and to raise exceptions from within that types.
And because of functors it's also possible to use the same structure
but by using signatures it can be done that the types are differing.

There is an example on this in the Ocaml-book from O'Reilley.
Look for subsection "Hiding Type Implementations" in section
"Modules and Information Hiding" in Chapter 14 ("Programming with Modules").


The type system of OCaml has helped me a lot in even smaller
programs to avoid problems that would be there, when using
languages like C, where the "type system" is very loosely,
would have caused many problems. Especially when using pointer-stuff,
many Segfaults may would have appeared in the program run
(and hopefully in the testing phase), where the type system has
stopped me.

How much more helpful will it be in larger/large projects!

I didn't believe that the type system really supports the programmer
until I have worked a while with it, and especially (as mentioned
by others here), when changing code that is older (and where you
may have forgotten a lot of the program's structure because it's too
long ago, when you touched the code the last time).

In the beginning I similar to you thought: "Well, people say it might
help, and so it might help... but I really find it annoying!".
Now I see: Well, it might be annoying, when you are new to it, but
I now can see *through experience* that it DOES help in programming.
Even in small programs it is helpful!


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 09:41:29AM +0000, Richard Jones wrote:
> On Fri, Feb 04, 2005 at 02:33:40AM +0000, Jon Harrop wrote:
> > 5. More pattern matching: [|1; 2; ...|] and [|...; 2; 1|]. (expressivity)
> 
> And this pattern which could be used all the time in web programming:
> 
>  | "prefix" ^ str ->
> 
> 8. Regular expressions in the language!
> 

9.: Pattern matching, that *really* is functional (seems to be necessary that it works
    like it is done in logical programming languages like Prolog or similar?
    I'm not familiar with Prolog, and maybe I'm wrong here to compare with these languages,
    so I will explain more elaborated what I mean...).

    Explanation: Pattern matches are like nested if's now in OCaml. The Pattern
    that matches first in the code, will be executed!!!
    This is NOT functional, this is imperative behaviour!
    If I change the pattern-matches in the code, the program may behave
    differently (depending on the data that will be matched)!
    
    Maybe there should be ANOTHER kind of pattern match, that does not rely
    on "which matching pattern comes first in the code executes", leaving the
    old/current pattern matching possibilities inside the language.
    But maybe something like "lmatch" (logical match), which does not executes
    the first matching pattern in the code but executes 
    "the ONLY ONE pattern that can match" (because otherwise it should be given an
    pattern match compilation error (where "match" instead of "lmatch" only gives a warning)).

    This also means that, when a general pattern is used twice, and one of them
    uses guards ("when"-clause in a pattern match), then the other pattern does
    only match, when the guard does NOT.
    (Or if there are more than one guard, that they will be checked too, or that a
    guard may be disallowed in such a kind of match.)
    And that it does not has any effect, if one of those pattern
    comes first in the source code (before the other pattern in the code appears).
    This also means to have a more powerful pattern-check on completeness.
    (Now it is not possible to check completelym when using "when" in a pattern match.)

I hope that this would be possible to integrate into OCaml (regarding the code as well
as theoretical aspects of the type-system itself).

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Gerd Stolpmann]

Richard W. M. Jones said:
>> If one wanted really to improve the situation, it would be better to
>> change the representation of strings, and to encode the string length
>> in the first word after the header. This wastes much less memory
>> (except in the special case when you have many small strings), and is
>> probably neutral for the execution speed.
>
> But then you'd need a special case to handle values-containing-
> strings, vs. values-not-containing strings, because you'd always want
> to have the size attribute of the header reflect the size of the data
> in the value.

AFAIK, only the garbarge collector accesses the size attribute in a
generic way. So a special case for strings would be needed. I guess
it is already there, because strings must be handled as opaque data.

Gerd
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 07:06:13AM +1100, skaller wrote:
> On Fri, 2005-02-04 at 05:06, Thomas Fischbacher wrote:
> 
> > Anyway, this leaves us with a very interesting question: how many people 
> > actually do believe in the value of Ocaml? I, for myself, use it whenever 
> > it is the most appropriate tool for a job (usually, when portability is 
> > an issue). This is sometimes the case, but more often than not, LISP 
> > turned out to be a better choice for what I do.
> 
> Well ..
> 
> [skaller@pelican] ~/links/flx/src>wc *.ml
>   89737  342248 3223570 total
> 
> 90K Camls here speak for themselves ..
> 
> Ocaml has four downsides from my viewpoint:
> 
> (a) interfacing to C isn't trivial
[...]

Well, compared to Perl, this task IS trivial in OCaml.

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 11:11:02AM +0100, Olivier Andrieu wrote:
>  > Frédéric Gava [Fri, 4 Feb 2005]:
>  > > On Fri, Feb 04, 2005 at 12:22:47AM +0100, Thomas Fischbacher
>  > > wrote:
>  > > > Oh, by the way, there is one more thing which I consider a
>  > > > really grave issue, which gave us quite a lot of grey hair
>  > > > already: Ocaml strings have this stupid limitation to 16 MB,
>  > > > which means in particular that if you serialize a truly large
>  > > > intermediate state of, say, a long and complicated calculation
>  > > > which accidentally got a bit larger than this limit (while you
>  > > > did not expect that), well...
>  > >
>  > > Got to agree with you on this one ...  At least we'll soon all be
>  > > using 64 bit computers where OCaml doesn't suffer this
>  > > limitation.
>  > >
>  > > Rich.
>  > > Richard Jones, CTO Merjis Ltd.
>  > 
>  > Also agree with you.  This limitation is sometime a problem for
>  > me. I code a library in Ocaml for parallel computing, thus I always
>  > serialize values and I could not bench programs which put on the
>  > networks, very big values. 
> 
> AFAIK Marshal.{to,from}_channel isn't limited by the maximum string
> length.

Some weeks ago I explored the Marshal-Module.
While doing some first-steps experiments form within the
toplevel, I got a crash with a SegFault.

IMHO Marshal-module should be removed from the Stdlib.
Or if it is intended to stay, it should be reimplemented,
so that it never can crash in this way!

It's too ugly to rely uon unreliable stuff...


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 01:51:36PM +0100, Gerd Stolpmann wrote:
[...] 
> If one wanted really to improve the situation, it would be better to change
> the representation of strings, and to encode the string length in the
> first word after the header. This wastes much less memory (except in the
> special case when you have many small strings), and is probably neutral
> for the execution speed.

Well, what is done inside the Buffer-module?
I have not looked inside, but appending strings
with Buffer-module is about 11 times faster than
using "^"-operator in a small program, that
uses string-append-operator ^in a lexer file (ocamllex);
as switching to Buffer-module this speedup was amazing...

Ciao,
   oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 01:43:04PM +0000, Richard W. M. Jones wrote:
 
[...]
> Actually, I wouldn't want to change lists.  Those currently have a tag
> = 0, and it would important to leave those untouched for exactly the
> reason you described.
[...]

Some months ago I googled for Ocaml ans lists (or something similar)
and found a paper on OCaml's list implementation, compared to
"vlists" (whatever a vlist may be).
I didn't read the paper completely, but at a glance - if I remember correctly -,
the vlists would be about 10 times faster than OCaml's current list-implementation...

... why not re-implementing the Lists as those vlists?

(Maybe as a module, if it is too much effort to change the OCaml-core)


Ciao,
   Oliver

Re: [Caml-list] The boon of static type checking

[Damien Doligez]

On Feb 4, 2005, at 11:26, Jon Harrop wrote:

> Also, it would be even easier to
> solve with an IDE which threw up the inferred types.

O'Caml has it:

   ocamlc -dtypes

and (in emacs)

   M-x caml-types-show-types

-- Damien

Re: [Caml-list] Estimating the size of the ocaml community

[Frédéric Gava]

Hi,

is it this paper ?
http://icwww.epfl.ch/publications/documents/IC_TECH_REPORT_200244.pdf

> ... why not re-implementing the Lists as those vlists?
> (Maybe as a module, if it is too much effort to change the OCaml-core)
Vlist mixed arrays and list (if I have understand the paper, it is a list of
arrays) and are a thus another data structure. but a powerfull data
structure and many ideas could be taken from this paper. I think we could
code this data-structure in Ocaml.

Frédéric

Re: [Caml-list] Estimating the size of the ocaml community

[Damien Doligez]

> On Thu, Feb 03, 2005 at 11:39:50PM +0000, Richard Jones wrote:
>> Got to agree with you on this one ...  At least we'll soon all be
>> using 64 bit computers where OCaml doesn't suffer this limitation.

On Feb 4, 2005, at 11:58, Oliver Bandel wrote:
> Well, but even on those computers will be restrictions in the size.

On 64-bit computers, the maximum string length is 2^56-9 bytes.

> And I'm sure that with more powerful computers, there will be
> more ressource-needing applications/calculations/computations
> and so maybe there will be another problem then (maybe it needs
> some decades to reach that limit?).

If Moore's law holds until then, and starting from a gigabyte now,
it will take about 40 years before you get a machine powerful enough
to run into that limit.  And the transistors of that machine will be
smaller than protons.

I hope we'll get 128-bit machines before then.

-- Damien

Re: [Caml-list] Estimating the size of the ocaml community

[sejourne_kevin]

Oliver Bandel a écrit :
> 9.: Pattern matching, that *really* is functional (seems to be necessary that it works
>     like it is done in logical programming languages like Prolog or similar?

Something like this could be fun (just like Prolog):

(*caml way*)
let test = function
     [(1,a);b;(3,c);(4,d)] ->Printf.printf "%d %d %d \n" a c d; b
   | _ -> failwith "Unification Impossible"
;;
(*half-prolog way*)
let test [(1,a);b;(3,c);(4,d)] =  Printf.printf "%d %d %d \n" a c d; b
and test _ = failwith "Unification Impossible"
;;

The second isn't allow, but it isn't a partial match.

With a logic match, Ocaml could be functionnal, imperative, object and 
logic. Just need a dynamic syntax to have the power of Prolog with the 
power of OCaml... cool. The problem with the logic
match (* | "prefix"^str -> *) is that ^ isn't a constructor but a 
function. I think, the logic match can't be determinist. IHMO, Prolog 
can do it just because all data are term(s) as all 'function'.

Regards,
Kévin

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Andreas Rossberg wrote:

> > (1) Prevent the programmer from "accidentally plugging an electrical 
> > shaver into a power high-voltage outlet".
> 
> In my personal experience, this is absolutely essential when you go 
> higher-order in non-trivial ways - dynamic type errors won't give you 
> the slightest clue when you screw up some combinator plugging. 

Here, I might disagree. Pretty much of what I've been doing in LISP 
so far involved higher order functions in nontrivial ways, to the extent 
of passing anonymous functions which are themselves passed into anonymous 
functions. I never experienced any serious difficulty with it.

But that might perhaps be just because I previously got used to deep 
higher-order programming by doing a lot of SML/NJ.

> (Incidentally, Lisp also isn't very well suited for higher-order 
> programming, because of its syntax issues: no light-weight application 
> syntax and currying.)

Yes, it required some getting used to it, and ML syntax looks somewhat 
nicer here. But this I do not experience as a big issue. Whatever I can do 
in terms of currying in ML I can just as well do in Lisp.

> > (2) Give the compiler hints how to optimize certain manipulations in terms 
> > of machine instructions.
> 
> The latter is actually the least important point. More significant are:

Depends. For quite many applications, speed is an issue. After all, many 
people today go in the direction of doing low-level stuff in C, 
implementing functionality in form of a library, and using Perl or Python
as a high level scripting language for flexibility.

Of course, it's somewhat more convenient not to have such an artificial 
barrier in the system. This can be achieved, with a language that is both 
highly performant and flexible. Both Lisp and Ocaml satisfy this 
criterion, and hence are quite cool systems.

> Type abstraction may not be powerful enough to fully capture units, but 
> it goes a long way. And you cannot seriously argue that something is 
> useless because it does not cover everything.

I don't say it's useless. I just say that as it is it's useless _for me_
personally. I don't want to speak for anyone else here. I'm pretty sure 
many people out there will benefit from ocaml's type system. I, however, 
do not.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 06:21:15PM +0100, Frdric Gava wrote:
> Hi,
> 
> is it this paper ?
> http://icwww.epfl.ch/publications/documents/IC_TECH_REPORT_200244.pdf
> 

Yes, I think that's the paper I meant.


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 06:27:11PM +0100, Damien Doligez wrote:
> 
> 
> >On Thu, Feb 03, 2005 at 11:39:50PM +0000, Richard Jones wrote:
> >>Got to agree with you on this one ...  At least we'll soon all be
> >>using 64 bit computers where OCaml doesn't suffer this limitation.
> 
> On Feb 4, 2005, at 11:58, Oliver Bandel wrote:
> >Well, but even on those computers will be restrictions in the size.
> 
> On 64-bit computers, the maximum string length is 2^56-9 bytes.

OK, that's enough until next summer (I mean 2006) ;-)


[...]
> 
> If Moore's law holds until then, and starting from a gigabyte now,
> it will take about 40 years before you get a machine powerful enough
> to run into that limit.  And the transistors of that machine will be
> smaller than protons.

Well, Quarks and subQuarks or something?

> 
> I hope we'll get 128-bit machines before then.

Well... it's some decades ago (I think in the mid-80ies), there was an article
about a 128-Bit-processor, very soon to be available on the chip-market.
But I don't know if that article was on an april issue of the magazine.


Ciao,
   Oliver


> 
> -- Damien
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

-- 
"Here at michigan state university, my computational linguistics professor
 had us learn ocaml for the class and we used it exclusively. I like it so
 much better than c++! Hope this helps." (Jeff Shaw on caml-list)

Re: [Caml-list] The boon of static type checking

[Jon Harrop]

On Friday 04 February 2005 17:02, Damien Doligez wrote:
> On Feb 4, 2005, at 11:26, Jon Harrop wrote:
> > Also, it would be even easier to
> > solve with an IDE which threw up the inferred types.
>
> O'Caml has it:
>
>    ocamlc -dtypes
>
> and (in emacs)
>
>    M-x caml-types-show-types

I've tried this before and have never managed to get it to work. What are 
these supposed to do and is there anything I should have installed to get 
them to work?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 06:32:00PM +0100, sejourne_kevin wrote:
> Oliver Bandel a écrit :
> >9.: Pattern matching, that *really* is functional (seems to be necessary 
> >that it works
> >    like it is done in logical programming languages like Prolog or 
> >    similar?
> 
> Something like this could be fun (just like Prolog):
> 
> (*caml way*)
> let test = function
>     [(1,a);b;(3,c);(4,d)] ->Printf.printf "%d %d %d \n" a c d; b
>   | _ -> failwith "Unification Impossible"
> ;;
> (*half-prolog way*)
> let test [(1,a);b;(3,c);(4,d)] =  Printf.printf "%d %d %d \n" a c d; b
> and test _ = failwith "Unification Impossible"
> ;;

The second one ("half-prolog way") looks a littlebid like Haskell's
syntax.

What I mean is, that your

 (*caml way*)
 let test = function
     [(1,a);b;(3,c);(4,d)] ->Printf.printf "%d %d %d \n" a c d; b
   | _ -> failwith "Unification Impossible"
 ;;

would work equally for all input data, if written in the opposite order
of pattern-match code-lines:

 (*caml way*)
 let test = function
     _ -> failwith "Unification Impossible"
   | [(1,a);b;(3,c);(4,d)] ->Printf.printf "%d %d %d \n" a c d; b
 ;;

And this, because in a functional setting it does not matter,
which expression comes first: it's always the same result
for the same input data, independent of the order of lines of code.


Now (but in Haskell it's the same) it is NOT independent
of which comes first.

This was a mayjor problem of understanding Pattern Matches,
especially because all people said (in books and papers too!)
that pattern matching belongs to the functional world.

I now can use OCaml pattern matches without problems,
but in the first time I was very annoyed about saying
that this is a functional language feature, when it
really not is.

So, maybe the documentation and the papers and books
should not call it functional pattern matching, but
pattern matching (or imperative pattern matching).

As OCaml has in it's concept that it also uses OO-features and imperative
features, there is no problem for me to accept the
pattern matching features as they are now.
But I like it to say it, how it is (not, how people want to
show it, even if it is differently).

And IMHO such a lmatch (logical match) or fmatch (functional match)
should be added to the OCaml-Core. (If possible.)


[...]
> With a logic match, Ocaml could be functionnal, imperative, object and 
> logic.

Yes, that's fine. :)

I think only Oz can compete here (but as far as I know it
is not as efficient/performant as OCaml).


> Just need a dynamic syntax to have the power of Prolog with the 
> power of OCaml... cool. The problem with the logic
> match (* | "prefix"^str -> *) is that ^ isn't a constructor but a 
> function. I think, the logic match can't be determinist. IHMO, Prolog 
> can do it just because all data are term(s) as all 'function'.

Hmhhh, so you think there are theoretical problems to implement such thing?!


Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Christophe TROESTLER]

On Fri, 4 Feb 2005, Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE> wrote:
> 
> > > Erm, what do you do if you want to quickly debug-print a list of
> > > vectors of pairs?

What's wrong with camldebug ?

ChriS

Re: [Caml-list] Estimating the size of the ocaml community

[Karl Zilles]

Christophe TROESTLER wrote:

 > What's wrong with camldebug ?


Since we're bitching about everything anyway, how about:

*) No conditional breakpoints
*) No watch expressions

ocamldebug works very well for debugging unexpected exceptions in my 
code, but when I wanted to trace the behavior of a specific function 
running on specific data, it was very painful to get to the right place.

1) set breakpoint
2) run
3) p variable
4) if not there yet, goto 2

yuck.  Am I missing something?  What do other people do?  Besides adding 
a conditional to their program to give them a place to set a breakpoint.

Re: [Caml-list] The boon of static type checking

[Christophe TROESTLER]

On Fri, 4 Feb 2005, Jon Harrop <jon@jdh30.plus.com> wrote:
> 
> On Friday 04 February 2005 17:02, Damien Doligez wrote:
> >
> >    ocamlc -dtypes
> >    M-x caml-types-show-types
> 
> I've tried this before and have never managed to get it to work. What are 
> these supposed to do and is there anything I should have installed to get 
> them to work?

Can you be more specific?  Which one does not work -- and possibly
what error messages do you get?  (The emacs command shortcut is C-cC-t).

ChriS

Re: [Caml-list] The boon of static type checking

[Jon Harrop]

On Friday 04 February 2005 20:38, Christophe TROESTLER wrote:
> > >    ocamlc -dtypes
> > >    M-x caml-types-show-types
> Can you be more specific?  Which one does not work -- and possibly
> what error messages do you get?

Sorry, I meant what does "ocamlc -dtypes" do? I can't find it in the man pages 
or on-line docs.

When I do "M-x caml-types-show-types" and hit enter, emacs just adds "[No 
match]" and beeps.

I have never been very happy with emacs' editing of ocaml. I often find that 
it randomly starts to indent incorrectly (as if the code were in a comment), 
comments are incorrectly syntax highlighted and have some code on which it 
indents wrongly every time.

> (The emacs command shortcut is C-cC-t).

I have no idea what that means, but I just tried it and emacs inserted 
"try\n\nwith". :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Jon Harrop wrote:

> > How did  
> > you feel that the static type checker of C++ didn't provide you with
> > similar help?
> 
> As the C++ type system cannot represent (and, therefore, statically check) 
> polymorphism properly, altering a generic data structure expressed using 
> templates results in reams of errors, mostly pointing to wrong places.

I think the problem indeed is that in C++, the way how things that are 
easy in Ocaml have to be done via templates is both quite clumsy, 
error-prone, and furthermore a hell lot of unnecessary work.

> Obviously such problems would have been virtually impossible to weed out had I 
> chosen to use a language with dynamic type checking, which is precisely I why 
> I left such languages at the door many years ago...

At least for Lisp, its dynamic type checking does include a lot of static 
type analysis as well. Perhaps not as nice as that of ocaml, but certainly 
at the level one can also expect to get e.g. from C/C++. Just make use of 
(declare ...), compile functions and don't ignore warnings.

As for static type analysis: the Lisp way is: if it turns out to be useful 
for a specific problem, it could always be added as a library. Sure it 
would be nice if there were consensus about one single library which 
provides this for those people who want to use it in lisp.

> On Friday 04 February 2005 09:29, Thomas Fischbacher wrote:
> > If I multiply a speed (in m/s) with a mass (in kg)...
> 
> Yes, absolutely! I believe you have correctly identified dimensionality as a 
> very important and useful system of (phantom) types used in physics.

It's occasionally useful. We physicists only use it when there really is 
danger of confusion, but adjust our units in such a way that no spurious 
conversion as to be performed if this only clutters formulae and gets in 
the way.

In high energy physics, we define time, length, and charge units relative 
to the eV, setting hbar = c = e = 1. ("Natural units") Some even set pi=1, 
but that is an entirely different story...

> The 
> OCaml type system goes some way to allowing such things to be enforced. 
> Dynamically typed languages do not. So how can you come to the conclusion 
> than going from dynamic typing to OCaml's static typing is a step in the 
> wrong direction?

Dynamic typing is more flexible. My proposal is that in the best of all 
worlds, static typing should be completely optional, (Of course, if one 
doesn't use it, one will lose quite a lot of further possibilities. But as 
a programmer I'd rather like to have the choice, instead of being forced. 
That, by the way, is one of the nicer aspects of the perl philosophy.)

> > So it's even more than "just returning more than one value without having
> > to cons" (which already is quite nice - but this essentially can always be
> > emulated via going to CPS, which establishes full call/return symmetry).
> > It's about giviny gou extra choice. Either: "Nice that you can also
> > provide me extra information, but I really don't care here", or: "I can
> > as well make use of this other piece of information which you
> > already obtained anyway." Same function, same call.
> 
> Sure, but what's wrong with using fst and snd for pairs, and records instead 
> of n-tuples? You get the same functionality and an explicit definition of 
> what is happening with only a couple of extra key strokes.

In most cases: I have to wrap up my thoughts in a situation where I know 
things could work much nicer. In some cases: it's really ugly to write 
an ocaml equivalent to LISP code that uses multiple-value to avoid 
consing.

But, as I said, this is a minor issue, just about as annoying as the fact 
that in Scheme, one has to work with #t and #f instead of nil and non-nil, 
and that one is not guaranteed that (car nil) = (cdr nil) = nil, which 
also frequently turns out to be very convenient.

> > > Use the top-level.
> >
> > That entirely misses the point!
> >
> > I talked about getting debug traces from an involved run.
> 
> Which you can do from the top level. If you have to output the information 
> from a running, native-code compiled binary then write the print and 
> string_of functions yourself:
> 
> let string_of_list f l = "["^String.concat "; " (List.map f l)^"]"
> let string_of_pair f (a, b) = "("^f a^", "^f b^")"
> print_endline (string_of_list (string_of_pair string_of_int) x)
> 
> Considering the first two can be factored out of a wide variety of programs, 
> it really isn't a huge amount of typing...

When I do algorithmically involved stuff, I frequently pretty soon reach 
the stage where I pass around structures of hash tables of structures and 
vectors of structures of vectors of numbers, say. I personally did 
experience it as painful to have to write specialized print functions for 
stuff like that. And this is an important issue, I think, as every 
language has its dark corners of things that would be useful and 
important, but people just don't do it as it is ugly and clumsy to 
express. If one such dark corner is getting information in one particular 
way about what's really going on deep down in the program, this is 
alarming.

> > > As an obvious example, neither Common Lisp or Scheme have
> > > pattern-matching.  Accessing data via pattern matching is often far more
> > > convenient than via c[ad]+r, slot accessors etc.
> >
> > Sure! But Lisp gives me the freedom to add it via a library. Which also
> > kind of says that it's unnecessary to complicate the core language by
> > putting in such a conceptually ad-hoc feature.
> 
> That's obviously completely wrong and a blatant troll so I'll stop replying 
> now.

You know nothing about the true way of the lambda. Absolutely *nothing*.


;;;; A simple example showing how to do - in principle - structural
;;;; matching in LISP in a way inspired by ML/Haskell
;;;;
;;;; Dear reader, please first look at the examples close to the end.
;;;;
;;;; (C) 2005 Dr. Thomas Fischbacher


(defstruct 
  (constructor
   (:print-function
    (lambda (obj stream depth)
      (declare (ignore depth))
      (format stream "#<~A~S>"
	      (string-downcase (symbol-name (constructor-type obj)))
	      (coerce (constructor-args obj) 'list)))))
  type
  args)

(defun joker-p (x)
  (and (symbolp x)
       (let ((n (symbol-name x)))
	 (>= (length n) 1)
	 (eql (schar n 0) #\?))))

(defvar _constructor-match-macros
  (make-hash-table :test 'eq))

(defun _instantiate-match (val lhs rhs failure &key (joker-p #'joker-p))
  (if (funcall joker-p lhs)
      ;; Case I: Joker match
      `(let ((,lhs ,val))
	 ,rhs)
    (let ((cmm
	   (if (consp lhs)
	       (gethash (car lhs) _constructor-match-macros)
	     nil)))
      (if cmm
	  ;; Case II: Constructor match
	  (funcall cmm val (cdr lhs) rhs failure :joker-p joker-p)
	;; Case III: "otherwise"
	(if (eq lhs 't)
	    rhs
	  ;; Case IV: immediate match
	  `(if (eql ,lhs ,val)
	       ,rhs
	     ,failure))))))

(defun _make-arg-bindings (sym-args nr-arg rest-params rhs failure
				    &key (joker-p #'joker-p))
  (if (null rest-params)
      rhs
    (_instantiate-match `(aref ,sym-args ,nr-arg) (car rest-params)
        (_make-arg-bindings sym-args (1+ nr-arg) (cdr rest-params)
			    rhs failure :joker-p joker-p)
	failure :joker-p joker-p)))


(defun make&register-constructor-matcher (cname nr-params)
  (let ((cmm
	 #'(lambda (val params rhs failure &key joker-p)
	     (let ((len-params (length params))
		   (sym-fail (gensym "fail-"))
		   (sym-args (gensym "args-")))
	       (if (or (not (listp params))
		       (/= len-params nr-params))
		   (error "Bad constructor match: ~A expects ~D args, got: ~S" cname nr-params params))
	       `(labels ((,sym-fail ()
			    ,failure))
		  (if (not (eq (constructor-type ,val) ',cname))
		      (,sym-fail)
		    (let ((,sym-args (constructor-args ,val)))
		      ,(_make-arg-bindings sym-args 0 params rhs `(,sym-fail) :joker-p joker-p))))))))
    (setf (gethash cname _constructor-match-macros) cmm)
    (setf (symbol-function cname)
	  #'(lambda (&rest args)
	      (let ((v-args (coerce args '(simple-array * (*)))))
		(if (/= (length v-args) nr-params)
		    (error "Constructor ~A is ~D-ary. Got args: ~S" cname nr-params args)
		  (make-constructor :type cname
				    :args (coerce args '(simple-array * (*)))))))))
    t)

(defun _match (var list-cases &key
		   sym-val
		   (joker-p #'joker-p))
  (if (null list-cases)
      nil
    (let* ((case-1 (car list-cases))
	   (lhs-1 (car case-1))
	   (rhs-1 `(progn ,@(cdr case-1)))
	   (sym-val* (if sym-val sym-val (gensym "val-")))
	   (body 
	    (_instantiate-match sym-val* lhs-1 rhs-1
				(_match var (cdr list-cases)
					:sym-val sym-val*
					:joker-p joker-p))))
      (if sym-val
	  body
	`(let ((,sym-val* ,var))
	   ,body)))))

(defmacro match ((var &key (joker-p #'joker-p)) &rest list-cases)
  (_match var list-cases :joker-p joker-p :sym-val nil))

;; ==========

(make&register-constructor-matcher 'fruit 1)
(make&register-constructor-matcher 'branch 2)

(defun all-fruits (tree)
  (match (tree)
    ((fruit ?x) (list ?x))
    ((branch ?x ?y)
	 (append (all-fruits ?x)
	         (all-fruits ?y)))))


;;; Believe it or not: we can also use this framework with built-in
;;; data types:

(setf (gethash 'cons _constructor-match-macros)
      #'(lambda (val params rhs failure &key joker-p)
	  (let ((len-params (length params))
		(sym-fail (gensym "fail-"))
		(sym-args (gensym "args-")))
	    (if (/= 2 len-params)
		(error "CONS takes two matching args, got: ~S" params))
	    `(labels ((,sym-fail () ,failure))
	       (if (not (consp ,val))
		   (,sym-fail)
		 (let ((,sym-args (coerce (list (car ,val) (cdr ,val))
					  '(simple-array * (*)))))
		   ;; Clearly, if we were serious here, we would not do
		   ;; such a stupid thing as making a vector from a cons cell
		   ;; (so that we can use the above interface),
		   ;; but use a more specialized variant, say,
		   ;; _make-cons-arg-bindings...
		   ,(_make-arg-bindings sym-args 0 params rhs
					`(,sym-fail) :joker-p joker-p)))))))



;;; === Example #1 ===

(defun all-fruits (tree)
  (match (tree)
    ((fruit ?x) (list ?x))
    ((branch ?x ?y)
	 (append (all-fruits ?x)
	         (all-fruits ?y)))))

(defun tree-is-double-branch (tree)
  (match (tree)
   ((branch (branch ?a1 ?a2) (branch ?b1 ?b2)) t)
   (t nil)))

#|
Log:

* (branch (fruit 'big-apple) (branch (fruit 'small-apple) (fruit 'red-apple)))

#<branch(#<fruit(BIG-APPLE)>
         #<branch(#<fruit(SMALL-APPLE)> #<fruit(RED-APPLE)>)>)>

* (all-fruits (branch (fruit 'big-apple)
                      (branch (fruit 'small-apple)
                              (fruit 'red-apple))))

(BIG-APPLE SMALL-APPLE RED-APPLE)

* (tree-is-double-branch (fruit 123))

NIL

* (tree-is-double-branch (branch (branch (fruit 'apple) (fruit 'pear))
				 (branch (fruit 'banana) (fruit 'potato))))

T
|#

;;; === Example 2 ===

(defun my-reverse (list)
  (labels
      ((walk (done rest)
	 (match (rest)
	   (nil done)
	   ((cons ?head ?tail)
	    (walk (cons ?head done) ?tail)))))
    (walk nil list)))

#|
Log:

* (my-reverse '(1 2 3 4 5))

(5 4 3 2 1)

* (my-reverse '())

NIL

|#

;; xx
;;   don't meddle with the affairs of lisp wizards, for you are
;;   crunchy, and good with ketchup!
;; xx


-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Basile STARYNKEVITCH]

Le Thu, Feb 03, 2005 at 07:34:15PM +0100, Frédéric Gava écrivait/wrote:
> Hi,
> 
> > Anyway, this leaves us with a very interesting question: how many people
> > actually do believe in the value of Ocaml? I, for myself, use it whenever
> > it is the most appropriate tool for a job (usually, when portability is
> > an issue). This is sometimes the case, but more often than not, LISP
> > turned out to be a better choice for what I do.

> What kinds of programs code with LISP could not be implemented (easely)
> using Ocaml ?

The main feature of Lisp that Ocaml does not have is the
meta-programming ability. This not only includes the powerful macro
system of Common Lisp (but Ocaml has Camlp4) but above all the ability
to genreate code at runtime.

The MetaOcaml extension of Ocaml (see http://metaocaml.org/ for
details) has a typeful meta-programming ability (which should be
stronger than that of Common Lisp, mostly because its type system
guarantee types of generated programs): howevefr the current
implementation does not garbage-collect the generated programs, which
make using it awkward.

I hope I am grossly right  - I may be wrong in the details, not being
a MetaOcaml expert.

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Oliver Bandel wrote:

> > Oh, by the way, there is one more thing which I consider a really
> > grave issue, which gave us quite a lot of grey hair already: Ocaml 
> > strings have this stupid limitation to 16 MB, which means in particular 
> > that if you serialize a truly large intermediate state of, say, a long 
> > and complicated calculation which accidentally got a bit larger than this 
> > limit (while you did not expect that), well...
> 
> Well, maybe there should be a BigStrings- or LongStrings-Module
> introduced into OCaml-stdlib?

Well, there is something for opaque binary data, but the problem is that 
not all functions one would like to have on them are readily available.

> But: When you mean with "a long and complicated calculation"
> using larger int/float-values you may use
> the num-library.

No, I actually meant serializing an approximation-to-a-continuation in 
long running symbolic calculations that accumulate quite a sizable heap of 
expressions representing terms, say for checkpointing.

> E.g. in module Num there is a  string_of_num-function.
> Do you really think, the results will be larger than 16MB?

In my case, I indeed had precisely this problem of some serializations 
failing due to data breaking the 16MB limit.

Oh, by the way, I also have indications that at least for 3.07, there is a 
bug in serializing and re-serializing hash tables. Unfortunately, my test 
case is quite complicated, and I so far could not strip it down to 
something more useful for debuggers.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Oliver Bandel wrote:

> On Thu, Feb 03, 2005 at 10:16:33PM +0100, Thomas Fischbacher wrote:
> [...]
> > (3) The type system is annoying. People claim it helps catching errors, 
> > but my impression is it only catches those which I would never make 
> > anyway.
> [...]
> 
> Well if it catches only errors you never make, you should
> never had any warnings nor error messages from the type
> system.
> So, why is it annoying, if you never get a warning/error message?
> 
> Normally you should not be aware of the type system, because you
> do not make type-system-errors.

Because the type system occasionally forces me to write code in funny 
ways, as I cannot "sometimes return an integer, sometimes a symbol" from a 
function, say. I would have to wrap this up.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Christophe TROESTLER wrote:

> On Fri, 4 Feb 2005, Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE> wrote:
> > 
> > > > Erm, what do you do if you want to quickly debug-print a list of
> > > > vectors of pairs?
> 
> What's wrong with camldebug ?

There are many different aspects to debugging, and not all of them are 
related to a debugger.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Christophe TROESTLER]

On Fri, 4 Feb 2005, Jon Harrop <jon@jdh30.plus.com> wrote:
> 
> Sorry, I meant what does "ocamlc -dtypes" do? I can't find it in the
> man pages or on-line docs.

It generates *.annot files that emacs can use to display the types.

>  When I do "M-x caml-types-show-types" and hit enter, emacs just
> adds "[No match]" and beeps.

This is strange, the message should be:
  No annotation file. You should compile with option "-dtypes".

(you are working with the latest version of the tools, don't you)

> I have never been very happy with emacs' editing of ocaml. I often
> find that it randomly starts to indent incorrectly (as if the code
> were in a comment), comments are incorrectly syntax highlighted and
> have some code on which it indents wrongly every time.

Do you use the standard OCaml mode or Tuareg
(http://www-rocq.inria.fr/%7eacohen/tuareg/)?  I personally use the
latter and I do not have such problems.

> I have no idea what that means, but I just tried it and emacs inserted 
> "try\n\nwith". :-)

It means "push CTRL-c then CTRL-c" is a shortcut for "M-x
caml-types-show-types" (you did C-ct).

ChriS

Re: [Caml-list] The boon of static type checking

[Christophe TROESTLER]

On Fri, 4 Feb 2005, Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE> wrote:
> 
> When I do algorithmically involved stuff, I frequently pretty soon
> reach the stage where I pass around structures of hash tables of
> structures and vectors of structures of vectors of numbers, say. I
> personally did experience it as painful to have to write specialized
> print functions for stuff like that. [...]

To Camlp4 knowledgeable people : is Camlp4 able to automatically
generate such printers ?

ChriS

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Fri, 4 Feb 2005, Thomas Fischbacher wrote:

(...)

> > That's obviously completely wrong and a blatant troll so I'll stop replying 
> > now.
> 
> You know nothing about the true way of the lambda. Absolutely *nothing*.

I have to apologize for this post. Evidently, being called a troll did 
make me more than quite a bit... furious.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Jon Harrop]

On Friday 04 February 2005 22:11, Christophe TROESTLER wrote:
> (you are working with the latest version of the tools, don't you)

Latest Debian Sarge. The commands should have been "M-x caml-types-show-type" 
and "push CTRL-c then CTRL-t". Having compiled with -dtypes, these work. 
However, I can't figure out how to display whole types (it only displays the 
first 70 chars or so).

> Do you use the standard OCaml mode or Tuareg
> (http://www-rocq.inria.fr/%7eacohen/tuareg/)?  I personally use the
> latter and I do not have such problems.

I just took advantage of a fresh Debian install on my laptop and installed 
Tuareg. It is quite broken under emacs (in the same way as my desktop) but 
xemacs is better. That indentation bug is still there though.

Specifically, in the structure of a module, after a bunch of definitions, I 
have a comment. The first lines of all member definitions after that are all 
incorrectly indented by zero characters (instead of four). I haven't been 
able to boil the example down and I can't give anyone the code, 
unfortunately. :-(

Thanks for your help though!

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Sat, 2005-02-05 at 03:00, Oliver Bandel wrote:

>     Explanation: Pattern matches are like nested if's now in OCaml. The Pattern
>     that matches first in the code, will be executed!!!
>     This is NOT functional, this is imperative behaviour!

No. If chains are perfectly functional .. in fact control
transfer is little more than lazy evaluation.

What you are *actually* complaining about is loss of transparency.
When you write

	if A then .. else if B then ..

the *actual* guard on the  second case isn't B, but

	B and not A

therefore the order of writing matters. So you cannot
transparently reorder the branches.

What you're *actually* asking for is probably a match construction
that guarrantees the branches are mutually exclusive so that
the order of writing is irrelevant.

In particular, there is a related construction that
executes *all* matching cases, and the mutually exclusive
branches match is a special case of that which only
takes one branch. In particular, a parallel match,
which executes all the branches, possibly concurrently,
would work well when the branches are exclusive..
(since no concurrency is required .. :)

In fact, Ocaml 'match' syntax is chosen to do 20 quite
distinct operations with one syntax: i.e. it is just
a convenience. The compiler tries to unravel it
to produce better code -- but the programmer
does not actually know how well it will perform
without heavy analysis.

More discrete constructions would give the programmer
much more idea of the actual semantics and implementation,
BUT it would then be much harder -- less transparent --
to modify the code.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Shivkumar Chandrasekaran]

On Feb 4, 2005, at 4:58 PM, Jon Harrop wrote:

> Specifically, in the structure of a module, after a bunch of 
> definitions, I
> have a comment. The first lines of all member definitions after that 
> are all
> incorrectly indented by zero characters (instead of four). I haven't 
> been
> able to boil the example down and I can't give anyone the code,
> unfortunately. :-(
>

This happens to me all the time with the standard emacs ocaml mode. 
When it does I first switch to fundamental-mode and then back again to 
caml-mode. This usually fixes it up. May be there is a simpler way to 
re-start it (until the bug is fixed).

--shiv--

Re: [Caml-list] Estimating the size of the ocaml community

[skaller]

On Sat, 2005-02-05 at 03:12, Oliver Bandel wrote:

> > 
> > (a) interfacing to C isn't trivial
> [...]
> 
> Well, compared to Perl, this task IS trivial in OCaml.

But it is very difficult compared to C++, where basically
you can just write

	extern "C" { .. }

or Felix where you bascially just write

	sin: double -> double;

to interface the 'sin' function. In Ocaml, the
Ocaml code is just like that too, but you have to
write wrapper glue (in Felix you don't usually),
and the glue goes in another file and is written
in C not Ocaml.

All of this makes 'trivial' interfacing rather
cumbersome, and 'extensive' interfacing a lot
of work.

So this is a downside whose impact depends on
how much C code you need for your application.

Typically with Ocaml, a lot of C libraries
are a waste of time, since you can do
the same code in Ocaml quite easily.
EG why bother with a lame XML parser library
done for C .. when Ocaml is so good at parsers
anyhow, it is probably easier to write your
own XML parser in Ocaml than bother interfacing
to a C library -- besides which you'd want
to think about making your application much simpler
using (C/X)Duce anyhow .. :)

Nevertheless a large issue in *adopting* a new
language is how to handle migration and with an
existing large code base binding to C is a
real industrial issue. The problem is that
for small apps, where a complete rewrite in
Ocaml makes sense, there's no great incentive
to use a better language. It is only for large
scale applications where the superiority of
strong typing, GC, HOFs etc etc really count
that you'd consider a complete technology
change and it is precisely in those cases that
migration paths do matter. Catch 22 :)


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Jacques Garrigue]

From: Damien Doligez <damien.doligez@inria.fr>
> On Feb 4, 2005, at 11:26, Jon Harrop wrote:
> 
> > Also, it would be even easier to
> > solve with an IDE which threw up the inferred types.
> 
> O'Caml has it:
> 
>    ocamlc -dtypes
> 
> and (in emacs)
> 
>    M-x caml-types-show-types

Or open your source with OCamlBrowser.
(Type checking is done by ocamlbrowser itself, and uses the same
infrastructure as -dtypes; thanks Damien)

Jacques Garrigue

Re: [Caml-list] The boon of static type checking

[Remi Vanicat]

On Fri, 04 Feb 2005 23:27:42 +0100 (CET), Christophe TROESTLER
<Christophe.Troestler@umh.ac.be> wrote:
> On Fri, 4 Feb 2005, Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE> wrote:
> >
> > When I do algorithmically involved stuff, I frequently pretty soon
> > reach the stage where I pass around structures of hash tables of
> > structures and vectors of structures of vectors of numbers, say. I
> > personally did experience it as painful to have to write specialized
> > print functions for stuff like that. [...]
> 
> To Camlp4 knowledgeable people : is Camlp4 able to automatically
> generate such printers ?
> 

Yes. In fact there is IoXML for xml parser and printer that can be found at
http://pauillac.inria.fr/~ddr/IoXML/
one could change it for non XML custom printer easily (I belive)

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 11:01:02PM +0100, Thomas Fischbacher wrote:
> 
> On Fri, 4 Feb 2005, Oliver Bandel wrote:
> 
> > > Oh, by the way, there is one more thing which I consider a really
> > > grave issue, which gave us quite a lot of grey hair already: Ocaml 
> > > strings have this stupid limitation to 16 MB, which means in particular 
> > > that if you serialize a truly large intermediate state of, say, a long 
> > > and complicated calculation which accidentally got a bit larger than this 
> > > limit (while you did not expect that), well...
> > 
> > Well, maybe there should be a BigStrings- or LongStrings-Module
> > introduced into OCaml-stdlib?
> 
> Well, there is something for opaque binary data, but the problem is that 
> not all functions one would like to have on them are readily available.
[...]

What and where?

Ciao,
   Oliver

Re: [Caml-list] Estimating the size of the ocaml community

[Oliver Bandel]

On Fri, Feb 04, 2005 at 11:02:49PM +0100, Thomas Fischbacher wrote:
> 
> On Fri, 4 Feb 2005, Oliver Bandel wrote:
> 
> > On Thu, Feb 03, 2005 at 10:16:33PM +0100, Thomas Fischbacher wrote:
> > [...]
> > > (3) The type system is annoying. People claim it helps catching errors, 
> > > but my impression is it only catches those which I would never make 
> > > anyway.
> > [...]
> > 
> > Well if it catches only errors you never make, you should
> > never had any warnings nor error messages from the type
> > system.
> > So, why is it annoying, if you never get a warning/error message?
> > 
> > Normally you should not be aware of the type system, because you
> > do not make type-system-errors.
> 
> Because the type system occasionally forces me to write code in funny 
> ways, as I cannot "sometimes return an integer, sometimes a symbol" from a 
> function, say. I would have to wrap this up.
> 
[...]

...well....

type sometimes_t = Integer of int | One_symbol | Another_symbol

let look_inside thing = match thing with
      Integer i      -> print_endline ("Got an int! " ^ string_of_int i)
    | One_symbol     -> print_endline "Got ONE symbol"
    | Another_symbol -> print_endline "Got ANOTHER symbol"


...isn't that nice?!


Ciao,
   Oliver

Why can't types and exceptions be nested (was: Re: [Caml-list] Estimating the size of the ocaml community)

[Richard Jones]

On Sat, Feb 05, 2005 at 02:14:18PM +0100, Oliver Bandel wrote:
> ...well....
> 
> type sometimes_t = Integer of int | One_symbol | Another_symbol

Another annoyance of OCaml is that 'type' definitions (and exception
defns for that matter) can't be nested.  I'm a big big fan of nested
functions, and sometimes I want to return a type which is only used
briefly between two nested functions.  Instead the type has to go
right at the start of the outer function, which may be many pages of
code away.  This reduces readability.

Is there a reason why types (and exceptions) can't appear nested?  I
suppose that a nested type might "escape" the scope where it appears,
but then surely it becomes an opaque type, just like types hidden in
modules.  The reason why exceptions cannot be nested is slightly more
understandable, because the runtime appears to build up a global list
of exceptions, but I'm sure there's some workaround.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: Why can't types and exceptions be nested (was: Re: [Caml-list] Estimating the size of the ocaml community)

[Basile STARYNKEVITCH]

Le Sat, Feb 05, 2005 at 04:37:32PM +0000, Richard Jones écrivait/wrote:
> On Sat, Feb 05, 2005 at 02:14:18PM +0100, Oliver Bandel wrote:
> > ...well....
> > 
> > type sometimes_t = Integer of int | One_symbol | Another_symbol
> 
> Another annoyance of OCaml is that 'type' definitions (and exception
> defns for that matter) can't be nested.  I'm a big big fan of nested
> functions, and sometimes I want to return a type which is only used
> briefly between two nested functions. 

You can use the let module syntax for that, eg (the example is silly,
but it works)

# let pubf x = 
   let module Internal = struct
     type brief_t = { a: string; b: int }
     let fun1 x = {a= string_of_int x; b= x+2 }
     let rec fun2 i = if i<=0 then [] else fun1 i :: (fun2 (i-1))
     let f x = List.map (fun {a=s; b=n} -> s,n) (fun2 x)
   end 
  in Internal.f x;;

# pubf 4;;
- : (string * int) list = [("4", 6); ("3", 5); ("2", 4); ("1", 3)]


Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

Re: Why can't types and exceptions be nested (was: Re: [Caml-list] Estimating the size of the ocaml community)

[Oliver Bandel]

On Sat, Feb 05, 2005 at 04:37:32PM +0000, Richard Jones wrote:
> On Sat, Feb 05, 2005 at 02:14:18PM +0100, Oliver Bandel wrote:
> > ...well....
> > 
> > type sometimes_t = Integer of int | One_symbol | Another_symbol
> 
> Another annoyance of OCaml is that 'type' definitions (and exception
> defns for that matter) can't be nested.  I'm a big big fan of nested
> functions, and sometimes I want to return a type which is only used
> briefly between two nested functions.  Instead the type has to go
> right at the start of the outer function, which may be many pages of
> code away.  This reduces readability.

What does "nested types" mean?

Can you explain, what this is?

How would a nested OCaml-type looks like,
if the compiler would allow it?

Example please.

Ciao,
   Oliver

Re: [Caml-list] The boon of static type checking

[Michael Walter]

On Fri, 4 Feb 2005 10:26:55 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > Are you using heavy casting and such without proper abstractions in
> > your C++ code?
> 
> No. The code is freely available here:
> 
> http://www.chem.pwf.cam.ac.uk/~jdh30/programming/opengl/smoke/index.html
Unfortunately I don't really have time to check that out to an
adequate extent :(

> > Pr what kind of changes did you want to make?
> 
> IIRC, one development was to change the core data structure from a list to a
> tree. The code to implement a simple tree is unwieldy in C++ (e.g. 1975 LOC
> in stl_tree.h and stl_map.h vs 198 LOC in map.ml). My ocaml implementation
> uses trees and graphs throughout now.
Hmm, ok.

> > How did
> > you feel that the static type checker of C++ didn't provide you with
> > similar help?
> 
> As the C++ type system cannot represent (and, therefore, statically check)
> polymorphism properly, altering a generic data structure expressed using
> templates results in reams of errors, mostly pointing to wrong places. In
> contrast, the worst I get with ocaml is an error in the wrong place because a
> previous function has been inferred to have a wrong type. Even this problem
> is much less common and trivial to trace. Also, it would be even easier to
> solve with an IDE which threw up the inferred types.
Hrm.. it handles both subtyping and ad-hoc polymorphism. I agree, with
templates the error messages are not easy to read (it gets a lot
better with experience, but I understand that that is not an
argument).

> As the C++ type system cannot represent (and, therefore, statically check)
> modules and variant types, shoehorning solutions into using class hierarchies
> and being forced to use pointers results in verbose code and weaker type
> checking. In contrast, the equivalent ocaml code is succinct and thoroughly
> checked. This brevity can also be attributed to the ability to pattern match.
Admittedly the lack of modules is a bit of a pain (although one can do
very tricks by combing #include + templates to work around the lack of
macros :-). Also, the lack of algebraic data types/variants (besides
pointers a.k.a. T option;) in the core language is certainly bit
annoying. boost::variant<> appears to solve that problem very well,
though.

> Obviously such problems would have been virtually impossible to weed out had I
> chosen to use a language with dynamic type checking, which is precisely I why
> I left such languages at the door many years ago...
Although I'm using Python for a lot of my scripting purposes, I
definitely prefer statically typed languages for mid-size to larger
projects as well. Maybe I'm just weak, but the type system gives me
much (I second that other post which mentioned that static typing is
not only about type checking, but also about "compiler-verified code
documentation" and much more). :-)

> > > I'm not sure what "multiple-value-bind" is. I'd have guessed "let a, b, c
> > > = 1, 2, 3".
> >
> > It's a macro in Common Lisp (see [1]). In O'caml-ish syntax, it also
> > does "let a, b = 1, 2, 3" (3 is discarded) and "let a, b, c = 1, 2" (c
> > is bound to nil).
> 
> These seem pretty pointless to me, but what about:
> 
> # let {a=a; b=b; c=_} = expr;;
> 
> or
> 
> # let x = expr in
>   ... x.a ... x.b ...;;
> 
> and then
> 
> # let (a, b), c = expr, None;;
> 
> (if you must).
I was merely explaining its semantics (giving you a free google, so to
say ;-), without any judgement about its usefulness compared to O'caml
alternatives.

Regards,
Michael

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

As this discussion got a bit heated up, it's perhaps appropriate to make a 
step backwards and ask the question: what is all this about, actually.

First of all, I strongly suppose most people will agree with me that one 
peculiarity of the Ocaml community is that most of its members are 
quite multi-lingual, which I somewhat doubt e.g. with the Java community.

This is very similar to perl, so it is perhaps appropriate to compare the 
role of ocaml to that of perl. Perl tried to integrate, and to build 
bridges. It not only inherits a lot from other languages and tools, but 
indeed is even such a good replacement for some of them (awk, sed, to 
some extent the shell) that they are even more or less obsoleted by perl: 
virtually anything one would want to do in awk can be done more easily, 
and nicer, in perl.

While ocaml also inherits a lot from other languages, it is not and 
does not try to be a glue language similar to perl. It has its own 
philosophy, which one might or might not like, but independent of this, 
even those people who have good reason not to believe in some of the ideas 
central to ocaml, such as e.g. Hindley-Milner typing, or matching as 
an integral part of the language, will from time to time consider it as a 
highly useful tool to build solutions to some problems, even if they do 
not think about making ocaml their primary medium for expressing 
algorithmic ideas. Personally, I see the following quite good reasons to 
do something in ocaml:

(1) Portability.

(2) A good compiler.

(3) The ability to create comparatively small standalone programs.

(4) Availability of essential constructions, such as closures.

(5) Availability of useful libraries.

I think the points why I believe ocaml will never win over a noticeable 
share of especially the lisp community are clear now: there are some 
quirks of the language that in the long run make working with it less fun 
for lisp programmers than working with lisp - as they are regarded as a 
conceptual step backwards in that community. Nevertheless, they will be 
glad ocaml exists and will occasionally use it provided the language does 
not hurt them too much. There are a few things I experienced as such a 
nuisiance in the past I just had to talk to some people about that, at 
some point. Alas, this is what happened on the list - sorry if annoyed a 
few readers with that, but from the response I think it seems as if
quite some of these issues not only I experienced as unnecessarily 
ugly. Some of them which may be improved perhaps should be improved.

If I were to limit myself to naming only one ugly side of ocaml which I 
would like to see changed, this would be the unavailability of automatical 
printers for complicated composite nested data structures. That is, an 
equivalent of perl's Data::Dumper. Say, an extension of Printf so that one 
can use "%v" for generating such output.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] Estimating the size of the ocaml community

[Thomas Fischbacher]

On Sat, 5 Feb 2005, Oliver Bandel wrote:

> > Well, there is something for opaque binary data, but the problem is that 
> > not all functions one would like to have on them are readily available.
> [...]
> 
> What and where?

One can abuse bigarray for this.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Erik de Castro Lopo]

On Sun, 6 Feb 2005 01:02:42 +0100 (CET)
Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE> wrote:

> (1) Portability.
> 
> (2) A good compiler.
> 
> (3) The ability to create comparatively small standalone programs.
> 
> (4) Availability of essential constructions, such as closures.

The features I *REALLY* love in O'caml are pattern matching and higher
order functions (particularly currying).

> (5) Availability of useful libraries.

I would add:

  (6) Its far harder to shoot yourself in the foot using O'caml than
      it is in C or C++. In particular, in O'caml comapred to C++, if 
      it compiles, its far more likely to work.

> I think the points why I believe ocaml will never win over a noticeable 
> share of especially the lisp community 

Those guys are probably a lost cause :-).

> are clear now: there are some 
> quirks of the language that in the long run make working with it less fun 
> for lisp programmers than working with lisp

I'm a refugee from Python (among other languages) although I still do
use Python for some scripting tasks where O'caml is overkill. My big 
gripe with Python results from its dynamic typing. A large class of 
errors which are compile time errors in O'caml are run time errors in 
Python. I believe that Lisp is also (mostly) dynamically typed.

However, I find it interesting to look at O'caml from the perspective of
the Blub paradox:

    http://c2.com/cgi/wiki?BlubParadox

which holds Lisp as being the closest approximation to a superset of all
other languages. The main feature of Lisp which supposed puts it in this 
position is Lisp macros. I also hear that higher order functions are not
used as much in Lisp as they are in O'caml and that this is because of
Lisp's more lax type checking.

Drawing a long bow here, I would postulate that a language with O'caml's
HOF and strict typing and Lisp like macros, might be able to knock Lisp
off its perch. Maybe Nemerle (not that I've used it):

    http://www.nemerle.org/

is a language that is getting close to this goal.

> If I were to limit myself to naming only one ugly side of ocaml which I 
> would like to see changed, this would be the unavailability of automatical 
> printers for complicated composite nested data structures. 

I agree. It may be possible to address this with Nemerle's macro capabilities
or even camlp4.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"... there's something really scary about a language (C++) where
copying state from one object to another is this complicated"
-- Richard Gillam

Re: [Caml-list] The boon of static type checking

[Richard Jones]

On Sun, Feb 06, 2005 at 01:02:42AM +0100, Thomas Fischbacher wrote:
> If I were to limit myself to naming only one ugly side of ocaml which I 
> would like to see changed, this would be the unavailability of automatical 
> printers for complicated composite nested data structures. That is, an 
> equivalent of perl's Data::Dumper.

Try: http://merjis.com/developers/dumper

It's a Data::Dumper equivalent for OCaml.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] The boon of static type checking

[Erik de Castro Lopo]

On Sun, 6 Feb 2005 01:34:21 +0000
Richard Jones <rich@annexia.org> wrote:

> On Sun, Feb 06, 2005 at 01:02:42AM +0100, Thomas Fischbacher wrote:
> > If I were to limit myself to naming only one ugly side of ocaml which I 
> > would like to see changed, this would be the unavailability of automatical 
> > printers for complicated composite nested data structures. That is, an 
> > equivalent of perl's Data::Dumper.
> 
> Try: http://merjis.com/developers/dumper
> 
> It's a Data::Dumper equivalent for OCaml.

Oh, that looks nice. Any chance of getting that in the standard
library? ;-)

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I invented the term Object-Oriented, and I can tell you I
did not have C++ in mind." -- Alan Kay

Re: Why can't types and exceptions be nested (was: Re: [Caml-list] Estimating the size of the ocaml community)

[skaller]

On Sun, 2005-02-06 at 03:37, Richard Jones wrote:

> Is there a reason why types (and exceptions) can't appear nested?  

This kind of lack of transparency is annoying. The main reason
is probably historical..

Felix allows anything to be nested anywhere,
modules, type definitions, etc can all be put
inside functions, it uses a unified namespace like C++.
[You can even put expressions inside types, using
the 'typeof()' operator]

Ocaml has separate namespaces for types
and variables. A module wraps both, which is why
you actually CAN nest types in functions in Ocaml,
but you have to use a local module to do it.
A new feature added to solve the problem you
mention, although not entirely transparently.

Whilst this kind of quirkery is annoying,
that's about all it is -- annoying. It isn't
really a show stopper.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Marcin 'Qrczak' Kowalczyk]

Richard Jones <rich@annexia.org> writes:

> Try: http://merjis.com/developers/dumper
>
> It's a Data::Dumper equivalent for OCaml.

"Note that there is not enough information at run time to print
complete types. However we try to guess at various structures
(like lists)."

I always associated guessing with Perl...

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Sun, 6 Feb 2005, Erik de Castro Lopo wrote:

> > (5) Availability of useful libraries.
> 
> I would add:
> 
>   (6) Its far harder to shoot yourself in the foot using O'caml than
>       it is in C or C++. In particular, in O'caml comapred to C++, if 
>       it compiles, its far more likely to work.

Well, yes, but these - I suppose - are more or less completely out of 
discussion here. :-)

> which holds Lisp as being the closest approximation to a superset of all
> other languages. The main feature of Lisp which supposed puts it in this 
> position is Lisp macros. I also hear that higher order functions are not
> used as much in Lisp as they are in O'caml and that this is because of
> Lisp's more lax type checking.
> 
> Drawing a long bow here, I would postulate that a language with O'caml's
> HOF and strict typing and Lisp like macros, might be able to knock Lisp
> off its perch. Maybe Nemerle (not that I've used it):

What if I added optional(!) strict typing to lisp?

Concerning HOF, I don't have a clear picture what a nice way to have 
something like that for lisp would be. Implementation wise, one would not 
want to map e.g.

fun x y -> x

to

fun x -> fun y -> y

that is, (lambda (x) (lambda (y) x)),

but rather have currying work as a certain form of partial application. 
This might interfere somewhat badly with lisp's idea of optional and 
keyword args, 

>     http://www.nemerle.org/

Oh. Great. Another language. Another occasion to repeat lots of dumb 
mistakes, another reason to re-invent a lot of wheels.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Sun, 6 Feb 2005, Richard Jones wrote:

> On Sun, Feb 06, 2005 at 01:02:42AM +0100, Thomas Fischbacher wrote:
> > If I were to limit myself to naming only one ugly side of ocaml which I 
> > would like to see changed, this would be the unavailability of automatical 
> > printers for complicated composite nested data structures. That is, an 
> > equivalent of perl's Data::Dumper.
> 
> Try: http://merjis.com/developers/dumper
> 
> It's a Data::Dumper equivalent for OCaml.

Pretty nice! Now, can this be made part of the core language, with a 
special %? sequence for printf?

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Radu Grigore]

On Fri, 4 Feb 2005 10:26:55 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:

> The code to implement a simple tree is unwieldy in C++ (e.g. 1975 LOC
> in stl_tree.h and stl_map.h vs 198 LOC in map.ml).

The implementation in stl_tree is not a "simple" tree. The difference
in size is also because the STL implementation is more efficient. For
one thing RB trees are better balanced than HB(2) trees. Another
observation is that fold on maps is not tail recursive. True, the
stack will probably never go above 40 calls but it is a problem if you
want to accumulate large structures. Yet another problem is the
missing cardinal function. I have a StringMap with about 200000: it
takes about 3 minutes (!!!) to get its length using a fold. That would
take something like 1 millisecond in C++.

I'm a bit annoyed right now with OCaml's Map because I'm writting a
tool where I need to construct big associative tables from strings to
other data. An implementation with Hashtbl makes the program work in 1
minute. The problem is that the next execution phase needs to fold
over the tables in increasing order of keys. Simple, no? Switch from
Hashtbl to Map. Right. Now the same program doesn't finish executing
in 3 hours. I would have expected a running time of about 20-30
minutes.

Maybe a hand-written lexical-tree will be good enough.

-- 
regards,
 radu
http://rgrig.idilis.ro/

Re: [Caml-list] The boon of static type checking

[Christophe TROESTLER]

On Sat, 5 Feb 2005, Remi Vanicat <remi.vanicat@gmail.com> wrote:
> 
> On Fri, 04 Feb 2005 23:27:42 +0100 (CET), Christophe TROESTLER
> <Christophe.Troestler@umh.ac.be> wrote:
> > On Fri, 4 Feb 2005, Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE> wrote:
> > >
> > > When I do algorithmically involved stuff, I frequently pretty soon
> > > reach the stage where I pass around structures of hash tables of
> > > structures and vectors of structures of vectors of numbers, say. I
> > > personally did experience it as painful to have to write specialized
> > > print functions for stuff like that. [...]
> > 
> > To Camlp4 knowledgeable people : is Camlp4 able to automatically
> > generate such printers ?
> > 
> 
> Yes. In fact there is IoXML for xml parser and printer that can be found at
> http://pauillac.inria.fr/~ddr/IoXML/
> one could change it for non XML custom printer easily (I belive)

My concern is with the types: if you want to "print x", you somehow
need to know the type of "x"... which is not available to camlp4.
However, I was thinking that maybe using the .annot file, camlp4 could
generate a good-enough printer (functions, abstract types, objects
being still opaque of course).  Such a system should be configurable
because I suppose some people would be happy with, say hashes, to be
<abstr> while others may want a textual representation.

ChriS

Re: [Caml-list] The boon of static type checking

[Gerd Stolpmann]

Am Sonntag, den 06.02.2005, 12:22 +0200 schrieb Radu Grigore:
> On Fri, 4 Feb 2005 10:26:55 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> 
> > The code to implement a simple tree is unwieldy in C++ (e.g. 1975 LOC
> > in stl_tree.h and stl_map.h vs 198 LOC in map.ml).
> 
> The implementation in stl_tree is not a "simple" tree. The difference
> in size is also because the STL implementation is more efficient. For
> one thing RB trees are better balanced than HB(2) trees. Another
> observation is that fold on maps is not tail recursive. True, the
> stack will probably never go above 40 calls but it is a problem if you
> want to accumulate large structures. Yet another problem is the
> missing cardinal function. I have a StringMap with about 200000: it
> takes about 3 minutes (!!!) to get its length using a fold. That would
> take something like 1 millisecond in C++.
> 
> I'm a bit annoyed right now with OCaml's Map because I'm writting a
> tool where I need to construct big associative tables from strings to
> other data. An implementation with Hashtbl makes the program work in 1
> minute. The problem is that the next execution phase needs to fold
> over the tables in increasing order of keys. Simple, no? Switch from
> Hashtbl to Map. Right. Now the same program doesn't finish executing
> in 3 hours. I would have expected a running time of about 20-30
> minutes.
> 
> Maybe a hand-written lexical-tree will be good enough.

I think you are a bit unfair, and it seems you did not analyse your
problem well enough to get a good solution.

The philosophy of the ocaml standard library is to provide light-weight
data structures that can be easily extended to one's needs. If you come
to the conclusion that a Map with cardinality is your optimal structure,
simply construct it:

module MakeMapWithCard (Ord : Map.OrderedType) =
struct
  module M = Map.Make(Ord)

  type key = M.key
  type t = int * M.t   (* cardinality, map *)

  let empty = (0, M.empty)

  let add key x (card,m) =
    if M.mem x m then
      (card,m)
    else
      (card+1, M.add x m)

  ...
end

You need not to program another balanced tree, just wrap it around the
available implementation. (The best is that the resulting module is
still compatible with the Map module of the standard library.)

The other point is that the hash tables, balanced trees etc. in ocaml
are just implementations of the common algorithms. There is no optimal
container that works best for all needs. Not in ocaml, not in C++, not
in any other language.

For your problem, I would guess that a hash table (in phase 1) plus
sorting (in phase 2) is the relatively best solution (from your
description). That avoids a lot of overhead compared to Map, especially
memory management consumes much less time.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

Re: [Caml-list] The boon of static type checking

[skaller]

On Sun, 2005-02-06 at 23:16, Gerd Stolpmann wrote:

> For your problem, I would guess that a hash table (in phase 1) plus
> sorting (in phase 2) is the relatively best solution (from your
> description). That avoids a lot of overhead compared to Map, especially
> memory management consumes much less time.

If you know something of the distribution of your keys,
which are strings, you can also make this much faster
by indexing using some suitable monotonic function
on the string prefix, and only sorting equivalent
strings.

EG, 64K word array of lists, indexed by first two
bytes of the string, then 64K sorts.

If your keys are not well distributed on the first
two bytes, use a monotonic hashing function.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Jon]

On Feb 6 2005, Radu Grigore wrote:
> On Fri, 4 Feb 2005 10:26:55 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > The code to implement a simple tree is unwieldy in C++ (e.g. 1975 LOC
> > in stl_tree.h and stl_map.h vs 198 LOC in map.ml).
> 
> The implementation in stl_tree is not a "simple" tree. The difference
> in size is also because the STL implementation is more efficient.

This is a much smaller effect compared to the verbosity imposed by inherent 
inefficiencies of the C++ language though.

> For one thing RB trees are better balanced than HB(2) trees.

The implementation details should be considered secondarily to the 
functionality provided, IMHO. Thus, I would consider the ability of the 
(functional) ocaml Set and Map to fork lineages to be more important. There 
might be an imperative RB-tree ocaml implementation hanging around 
somewhere if you want to make a more accurate comparison...

> Another observation is that fold on maps is not tail recursive.

But the depth of recursion on the stack is O(ln_2 n), IIRC.

> True, the
> stack will probably never go above 40 calls but it is a problem if you
> want to accumulate large structures.

I would like to think that your stack will be big enough to fit 40 
recursive calls if you expect your computer to handle trillion-element 
maps!

> Yet another problem is the missing cardinal function.

An arbitrary number of functions are "missing". You can't expect INRIA to 
implement all infinity of them for you! :-)

As someone else has posted, you can easily supplement the current Map with 
code to keep track of the number of mappings with a good complexity and 
reasonable efficiency.

A reason not to implement the cardinal function is the overhead of having 
counters in the nodes of the tree or the cost of testing for membership 
with every add/remove.

> I have a StringMap with about 200000: it
> takes about 3 minutes (!!!) to get its length using a fold.

I guess this poor performance is due to cache incoherence but, of course, 
this is the wrong data structure for the job.

> That would
> take something like 1 millisecond in C++.

The STL will probably take <<1ms because the STL's size() is probably O(1) 
whereas Map's fold is O(n). In contrast, forking lineages is probably O(n) 
with the STL (requiring a copy) and O(1) with ocaml's Map.

> I'm a bit annoyed right now with OCaml's Map because I'm writting a
> tool where I need to construct big associative tables from strings to
> other data. An implementation with Hashtbl makes the program work in 1
> minute. The problem is that the next execution phase needs to fold
> over the tables in increasing order of keys. Simple, no? Switch from
> Hashtbl to Map. Right. Now the same program doesn't finish executing
> in 3 hours. I would have expected a running time of about 20-30
> minutes.
> Maybe a hand-written lexical-tree will be good enough.

You seem to be complaining about poor performance when you know you are 
using the wrong data structure. Talk about unreasonable expectations. :-)

IIRC, the exact data structure you want is already on the hump. HTH.

Cheers,
Jon.

Re: [Caml-list] The boon of static type checking

[Radu Grigore]

On Sun, 06 Feb 2005 09:32:19 -0800 (PST), Jon <jdh30@cam.ac.uk> wrote:

> Thus, I would consider the ability of the
> (functional) ocaml Set and Map to fork lineages to be more important.

By "fork lineages" you mean keeping "old" versions of the map around?
I never needed that but I agree it is cute and that it is likely that
I'll need it sometime soon.

> > True, the
> > stack will probably never go above 40 calls but it is a problem if you
> > want to accumulate large structures.
> 
> I would like to think that your stack will be big enough to fit 40
> recursive calls if you expect your computer to handle trillion-element
> maps!

In the worst case (most unbalanced) 40 corresponds to a few million
keys, not trillions. If I haven't made a mistake the minimum number of
keys in a (OCaml) Map with height h is given by the recurrence:
T(h)=1+T(h-1)+T(h-3).

> > Yet another problem is the missing cardinal function.
> An arbitrary number of functions are "missing". You can't expect INRIA to
> implement all infinity of them for you! :-)

Considering the fact that the code in set.ml and map.ml looks like it
is copy&pasted I guess asking for some consistency in the interface is
not unreasonable. In any case copy&pasting the cardinal function
wouldn't provide better performance (I think).

> The STL will probably take <<1ms because the STL's size() is probably O(1)
> whereas Map's fold is O(n). In contrast, forking lineages is probably O(n)
> with the STL (requiring a copy) and O(1) with ocaml's Map.

I haven't actually tested with STL but the implementation of size() is
indeed a simple return. Do you have an example where forking lineages
is useful? As I said, I don't doubt there are situations where it is
useful; just that right now I'm having trouble coming up with a
realistic example.

> You seem to be complaining about poor performance when you know you are
> using the wrong data structure. Talk about unreasonable expectations. :-)

I am exploring possibilities right now. My only "complaint" is that
switching from Hashtbl to Map for a dictionary of about 200000 keys
decreases the performance a LOT! I would have expected a factor of
20-30 but it seems to be a lot more: probably due to memory management
(as Gerd Stolpmann notices) due to the functional nature of Map.

> IIRC, the exact data structure you want is already on the hump. HTH.

Thanks, I'll search for it.

-- 
regards,
 radu
http://rgrig.idilis.ro/

Re: [Caml-list] The boon of static type checking

[Radu Grigore]

On Sun, 06 Feb 2005 06:59:52 -0800 (PST), skaller
<skaller@users.sourceforge.net> wrote:
> If you know something of the distribution of your keys,
> which are strings, you can also make this much faster
> by indexing using some suitable monotonic function
> on the string prefix, and only sorting equivalent
> strings.

This is a nice idea that crossed my mind. If a simpler (to code)
solution won't work I'll definitely try it.

-- 
regards,
 radu
http://rgrig.idilis.ro/

Re: [Caml-list] The boon of static type checking

[skaller]

On Mon, 2005-02-07 at 04:28, Jon wrote:
> On Feb 6 2005, Radu Grigore wrote:
> > On Fri, 4 Feb 2005 10:26:55 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > > The code to implement a simple tree is unwieldy in C++ (e.g. 1975 LOC
> > > in stl_tree.h and stl_map.h vs 198 LOC in map.ml).
> > 
> > The implementation in stl_tree is not a "simple" tree. The difference
> > in size is also because the STL implementation is more efficient.
> 
> This is a much smaller effect compared to the verbosity imposed by inherent 
> inefficiencies of the C++ language though.

Curious what you think those are. 

g++ seems to generate better
code than ocamlopt for similar simple problems
(see Alioth for quantitative evidence given silly
set of sample 'problems')

IMHO the single major inefficiency in C++ is also a source
of efficiency -- lack of a garbage collector.

OTOH Ocaml has a massive inefficiency C++ does not,
namely boxing, and ocaml tools currently do not 
seem to be very good at unboxing.

Ocaml tools do much better with tail calls than g++,
but I don't see that this is an intrinsic fault
in C++: the 'callee pops arguments' gets in the
way with separate compilation, but not
for inline functions.

Again, C++ provides inline functions which
provide a way Ocaml does not have so easily 
for optimising.

Felix is a C++ code generatore which provides many
of the features of C++ which are clumbsy to encode
such as sum types and closures, does tail call
optimisation, and also provides a garbage collector. 
It currently appears to outperform the ocaml bytecode interpreter,
whereas the x86 native code compiler ocamlopt generates
faster code on average.

It is hard to say that Felix code 'is faster than C++'
given it actually generates it.

So I'm quite interested in what inefficiencies C++ might
have compared to ocaml -- feel free to identify not only
'intrinsic' inefficiency of the languages, but also
problems in the compilation models, and difficulties
in generating good code that are not necessarily
intrinsic. (EG I would like to hear a comment
that tail-rec optimisation whilst not 'intrinsically impossible'
in C++ is hard to do, if that is your belief)

One further comment: Ocaml and C++ share a serious impediement
to efficiency -- eager evaluation. In fact lazy evaluation
can also be inefficient. Which is why Felix is moving
towards an 'unspecified evaluation' strategy.
In fact the optimiser already assumes purity/termination,
there's a way to enforce eagerness, but I have no way
to enforce laziness at the moment :(

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[skaller]

On Mon, 2005-02-07 at 04:28, Jon wrote:

> You seem to be complaining about poor performance when you know you are 
> using the wrong data structure. Talk about unreasonable expectations. :-)

But this misses the most important advantage of STL,
namely the ability to use multiple data structures
with the same algorithms.

In the first order Ocaml functors do that too,
but in practice they don't seem to work nearly as well.

For higher order problems, both systems seem to
collapse -- C++ from ad hoc behaviour, and Ocaml
from complexity, constraints, and limitations
on expressiveness.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[skaller]

On Mon, 2005-02-07 at 09:26, Radu Grigore wrote:
> Do you have an example where forking lineages
> is useful? 

Sure -- in a compiler a Map representing the symbol table
works well with recusive analysis, since when you
pop out of a scope, the symbols in the old scope
just 'remain' as they were and the ones added
in the inner scope just 'disappear'.

I use this feature of lists to analyse graphs
using recursive descent all the time, using
the list to track the current path to prevent
infinite recursion by identifying uplinks
(weak pointers).

So yes, the persistence is very useful in a wide
variety of circumstances.

I dare say, database programmers would kill for
a functional database .. of course programmers
have been using CVS for a while .. even C++ people :)

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Erik de Castro Lopo]

On Mon, 7 Feb 2005 00:30:12 +0200
Radu Grigore <radugrigore@gmail.com> wrote:

> On Sun, 06 Feb 2005 06:59:52 -0800 (PST), skaller
> <skaller@users.sourceforge.net> wrote:
> > If you know something of the distribution of your keys,
> > which are strings, you can also make this much faster
> > by indexing using some suitable monotonic function
> > on the string prefix, and only sorting equivalent
> > strings.
> 
> This is a nice idea that crossed my mind. If a simpler (to code)
> solution won't work I'll definitely try it.

Sounds a little like a simplified version of a TRIE:

    http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/Trie/

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"The one thing that reading these five books has hammered home is how
much C++ has turned into 3 languages stuck in a bag fighting to get
out. Low C++, High C++, and Generic C++."

Re: [Caml-list] The boon of static type checking

[Brian Hurt]

Probably a bad idea, but I've got to jump in here.

Full disclosure: I *hate* C++.  Mainly because I've actually written real 
programs in it.  The next time I have to use C++ in any sort of serious 
way I'm registering c++sucks.com and starting a website to catalog all the 
different ways C++ sucks.  Feel free to stop reading at this point.

On 7 Feb 2005, skaller wrote:

> On Mon, 2005-02-07 at 04:28, Jon wrote:
> > On Feb 6 2005, Radu Grigore wrote:
> > > On Fri, 4 Feb 2005 10:26:55 +0000, Jon Harrop <jon@jdh30.plus.com> wrote:
> > > > The code to implement a simple tree is unwieldy in C++ (e.g. 1975 LOC
> > > > in stl_tree.h and stl_map.h vs 198 LOC in map.ml).
> > > 
> > > The implementation in stl_tree is not a "simple" tree. The difference
> > > in size is also because the STL implementation is more efficient.
> > 
> > This is a much smaller effect compared to the verbosity imposed by inherent 
> > inefficiencies of the C++ language though.
> 
> Curious what you think those are. 

Let's see.

Ocaml:
val map : ('a -> 'b) -> 'a list -> 'b list

C++:

template<class a, class b> list<b>& list::map(b& (*)(const a&), 
const list<a>&);

I'm not 100% sure that's correct- I think there needs to be a typename in 
there somewhere.  C++'s syntax has gotten so horrid even the compiler has 
a hard time figuring out what's a return type vr.s what's a function name.

Using templates for universal types is a bad idea, even ignoring the code 
duplication evils.

> 
> g++ seems to generate better
> code than ocamlopt for similar simple problems
> (see Alioth for quantitative evidence given silly
> set of sample 'problems')

Yep.  And, conservatively, 10 times as much effort has gone into the gcc
optimizer as the Ocaml optimizer.  Possibly 100 times.  For, according to
Alioth, about a 10% improvement.  It's only with gcc 3.x that C++ managed
to beat Ocaml on performance.

I note with humor that the big new optimization in GCC is the SSA-Tree 
form- "Single Static Assignment".  The idea behind SSA is that you can 
only assign a variable a value when you create it, you can not change it 
latter.  Once you express C++ in SSA, it's a lot easier to apply a lot of 
optimizations to it.  Of course, the more I look at SSA, the more it looks 
like a functional language to me.  So, in effect, the GCC optimization 
strategy is to convert the C++ into a functional language, and then 
optimize the functional language.  

> 
> IMHO the single major inefficiency in C++ is also a source
> of efficiency -- lack of a garbage collector.

It's a source of efficiency on the small scale- it's easy to write a 1,000 
line program with hand allocation.  Rather harder to write a 10,000 line 
program, and a major bitch to write a 100,000 line program without garbage 
collection.

> 
> OTOH Ocaml has a massive inefficiency C++ does not,
> namely boxing, and ocaml tools currently do not 
> seem to be very good at unboxing.

This is also a big efficiency for Ocaml, for two reasons.  First, it 
encourages code reuse.  Second, Ocaml only needs one implementation of a 
function for all types.  C++'s template system, to unbox everything, 
duplicates code like crazy- generally, a new implementation for every 
type.

> 
> Again, C++ provides inline functions which
> provide a way Ocaml does not have so easily 
> for optimising.

Don't assume that inlining is optimization.  Actually, it generally isn't.  
Having actually timed it on modern hardware, a function call costs like 
2-3 clock cycles these days.  Plus 1-2 clock cycles per argument.  This is 
compared to the 10-30 clock cycles a mispredicted branch costs, the 20+ 
clock cycles an L1 cache miss/L2 cache hit costs, and the 100-350+ clock 
cycles of an L2 cache miss/memory fetch.

The model people use to guess what makes code go faster is still based on
the 8086.  Count up the number of instructions you'll execute (possibly
making an allowance for "expensive" instructions like divide and square
root), and that's an approximation for how much time the program will
take.  Fewer instructions = faster program.  The fact that this model 
hasn't been true for two decades hasn't detracted from it's popularity.

Inlining code increases code size, vastly increasing the number of cache
misses.  I've seen the executable size of C++ code *triple* by adding two
words to the source code (virtual inline on a constructor).  I agree
that's an extreme case- but in most cases inlining is just avoiding a 2-3
clock cycle cost by instead incurring a 100-350+ clock cycle cost.

What little inlining is a good idea can be done by the compiler, 
especially by Ocaml which will inline across module boundaries.  But Mel 
is alive and well and probably coding in C++, and what fun is the compiler 
performing these optimizations when we can perfom them as well.  Most 
programmers still think they're working in Turbo C++ 1.0 which didn't 
optimize.  Hint: I've yet to meet a compiler that couldn't turn x/32 into 
x >> 5.

> So I'm quite interested in what inefficiencies C++ might
> have compared to ocaml -- feel free to identify not only
> 'intrinsic' inefficiency of the languages, but also
> problems in the compilation models, and difficulties
> in generating good code that are not necessarily
> intrinsic. (EG I would like to hear a comment
> that tail-rec optimisation whilst not 'intrinsically impossible'
> in C++ is hard to do, if that is your belief)

Actually, g++ does do tail call optimization (in the 3.x tree).  It's 
actually not that hard to do, just not that beneficial (for C++).

Brian

Re: [Caml-list] The boon of static type checking

[Michael Walter]

On Sun, 6 Feb 2005 23:34:02 -0600 (CST), Brian Hurt <bhurt@spnz.org> wrote:
> Probably a bad idea, but I've got to jump in here.
> 
> Full disclosure: I *hate* C++.  Mainly because I've actually written real
> programs in it.  The next time I have to use C++ in any sort of serious
> way I'm registering c++sucks.com and starting a website to catalog all the
> different ways C++ sucks.  Feel free to stop reading at this point.
:-)

> ...
> > g++ seems to generate better
> > code than ocamlopt for similar simple problems
> > (see Alioth for quantitative evidence given silly
> > set of sample 'problems')
> 
> Yep.  And, conservatively, 10 times as much effort has gone into the gcc
> optimizer as the Ocaml optimizer.  Possibly 100 times.  For, according to
> Alioth, about a 10% improvement.  It's only with gcc 3.x that C++ managed
> to beat Ocaml on performance.
More effort having gone into gcc and better performance of gcc are
arguments pro gcc, right? ;-)

> > IMHO the single major inefficiency in C++ is also a source
> > of efficiency -- lack of a garbage collector.
> 
> It's a source of efficiency on the small scale- it's easy to write a 1,000
> line program with hand allocation.  Rather harder to write a 10,000 line
> program, and a major bitch to write a 100,000 line program without garbage
> collection.
Personally I like it that in C++ you actually have the choice to use
appropriate garbage collection schemes when you desire to do (yep,
multiple kind of GCs for different subsystems/data/... is a win).
Makes it easier with > 1,000,000 line programs :-)

> > OTOH Ocaml has a massive inefficiency C++ does not,
> > namely boxing, and ocaml tools currently do not
> > seem to be very good at unboxing.
> 
> This is also a big efficiency for Ocaml, for two reasons.  First, it
> encourages code reuse.  Second, Ocaml only needs one implementation of a
> function for all types.  C++'s template system, to unbox everything,
> duplicates code like crazy- generally, a new implementation for every
> type.
Very true. Technically this would not be very difficult in C++,
though. There's a certain trade off you have to make for either way.

> > Again, C++ provides inline functions which
> > provide a way Ocaml does not have so easily
> > for optimising.
> 
> Don't assume that inlining is optimization.  Actually, it generally isn't.
> Having actually timed it on modern hardware, a function call costs like
> 2-3 clock cycles these days.  Plus 1-2 clock cycles per argument.  This is
> compared to the 10-30 clock cycles a mispredicted branch costs, the 20+
> clock cycles an L1 cache miss/L2 cache hit costs, and the 100-350+ clock
> cycles of an L2 cache miss/memory fetch.
Inlining for very small functions generally is an optimization.

> What little inlining is a good idea can be done by the compiler,
Yep, usually the "inline when appropriate" compiler switch + something
like__forceinline for very small functions (for paranoia reasons)
seems to be the way to go in my experience.

Michael

Re: [Caml-list] Estimating the size of the ocaml community

[Sven Luther]

On Wed, Feb 02, 2005 at 04:31:28PM -0500, Yaron Minsky wrote:
> I've been trying to come up with some estimates on the size of the ocaml
> community, and I'm wondering if others have come up with anything better.
> Here's what I have so far:

I don't know if it is interesting for what you need, but the debian popularity
contest :

  http://popcon.debian.org/

shows ocaml starting at position 1858 :

  #rank name                            inst  vote   old recent no-files (maintainer)
  1858  ocaml-base-nox                   743   238   396   109     0 (Sven Luther)                   

But this may be biased by the split of ocaml between different packages,
ocaml-base-nox is the runtime without X related libraries. The most used
packages (adduser for the per inst sorting) is around 6000, so this would mean
that about 10% install ocaml stuff, since inst is : 

  #<inst> is the number of people who installed this package;

Naturally, the results are probably biased by the way popularity contest is
run. popularity contest (popcon) is a package which you can install but which
is not installed by default, and where you can opt-in into the mechanism,
which sends (weekly ?) emails about the installed packages to the debian
popularity-contest. Still, this means that at least 743 people have it
installed, that 238 "use this package regularly", and 109 have recently
upgraded it. No idea about how the "use this package regularly" numbers are
calculated though.

Hope this kind of info is helpful to your estimates ?

Friendly,

Sven Luther

Re: [Caml-list] Estimating the size of the ocaml community

[Johann Spies]

On Wed, Feb 02, 2005 at 04:31:28PM -0500, Yaron Minsky wrote:
> 
> - Some schools teach ocaml.  Brown and Caltech apparently have intro ocaml
>   courses.  Any other places that teach the language?  Any ideas on how many
>   students go through these courses?

Do you know about any university which offers distant learning courses
in Programming or Computer Science and also teaches Ocaml?

In Souh Africa, where I am, Ocaml is a largely unkown language.

Regards
Johann
-- 
Johann Spies          Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch

     "But the LORD is in his holy temple; let all the earth 
      keep silence before him."           Habakkuk 2:20 

Re: [Caml-list] The boon of static type checking

[Ville-Pertti Keinonen]

On Sun, 2005-02-06 at 23:34 -0600, Brian Hurt wrote:

> optimizations to it.  Of course, the more I look at SSA, the more it looks 
> like a functional language to me.  So, in effect, the GCC optimization 

While the single-assignment aspect of SSA could be considered
"functional", representing control flow using blocks and branches can't.

> Don't assume that inlining is optimization.  Actually, it generally isn't.  

Note that for OCaml, more aggressive inlining could be a significant
improvement, not because it would eliminate calls, but because it could
eliminate closures.  By more aggressive I mean more capable, not just
cranking up the -inline parameter.

Obviously this doesn't apply to C++.

Re: [Caml-list] The boon of static type checking

[Marcin 'Qrczak' Kowalczyk]

Brian Hurt <bhurt@spnz.org> writes:

> Hint: I've yet to meet a compiler that couldn't turn x/32 into 
> x >> 5.

Actually this is incorrect when x is a signed type (and might be
negative).

Strictly speaking, the sign of the quotient when either argument
is negative is implementation-defined in C++, but GCC prefers to be
consistent (it's the sign of the dividend when idiv is used, but
shifting would yield the sign of the divisor).

This means that when I care about performance and perform division
of a number that I know is non-negative by a number which might
be a constant power of 2, I cast the divisor to an unsigned type.
The same applies to remainder.

> Actually, g++ does do tail call optimization (in the 3.x tree).  It's 
> actually not that hard to do, just not that beneficial (for C++).

It is hard:

- With the default C/C++ calling convention it's impossible if
  parameters of the callee take more space than parameters of the
  caller.

- On x86 in PIC it would make calls from extern functions to some
  static functions slower. Because the callee assumes that %ebx allows
  to find data of our module, yet *our* caller in general assumes that
  we will restore %ebx. Instead of making these functions slower for
  all calls (by setting up and restoring %ebx in the callee too), GCC
  doesn't perform tail call optimization in this case.

- It requires from the compiler to infer that addresses of our local
  variables don't leak to code which might use them while the
  tail-called function is running.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Re: [Caml-list] The boon of static type checking

[Igor Pechtchanski]

On Mon, 7 Feb 2005, Michael Walter wrote:

> On Sun, 6 Feb 2005 23:34:02 -0600 (CST), Brian Hurt <bhurt@spnz.org> wrote:
> > Probably a bad idea, but I've got to jump in here.
> >
> > Full disclosure: I *hate* C++.  Mainly because I've actually written real
> > programs in it.  The next time I have to use C++ in any sort of serious
> > way I'm registering c++sucks.com and starting a website to catalog all the
> > different ways C++ sucks.  Feel free to stop reading at this point.
> :-)

As someone who has background in compiler optimizations (of Java, not C++,
but they are similar enough in the areas below), I'd like to address one
of Brian's points.

> > > Again, C++ provides inline functions which
> > > provide a way Ocaml does not have so easily
> > > for optimising.
> >
> > Don't assume that inlining is optimization.  Actually, it generally isn't.
> > Having actually timed it on modern hardware, a function call costs like
> > 2-3 clock cycles these days.  Plus 1-2 clock cycles per argument.  This is
> > compared to the 10-30 clock cycles a mispredicted branch costs, the 20+
> > clock cycles an L1 cache miss/L2 cache hit costs, and the 100-350+ clock
> > cycles of an L2 cache miss/memory fetch.
> Inlining for very small functions generally is an optimization.
>
> > What little inlining is a good idea can be done by the compiler,
> Yep, usually the "inline when appropriate" compiler switch + something
> like__forceinline for very small functions (for paranoia reasons)
> seems to be the way to go in my experience.

FWIW, I agree with Brian that inlining in itself is most often not an
optimization at all.  However, the main power of inlining is that it
enables the compiler to apply intraprocedural optimizations globally.
Consider a huge complex dispatch function that, when inlined, boils down
to one method call (due to, e.g., constant propagation).  Most modern
compilers also do specialization if code bloat due to inlining is an issue
(I don't know off-hand if g++ does).
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

Re: [Caml-list] The boon of static type checking

[skaller]

On Mon, 2005-02-07 at 21:57, Ville-Pertti Keinonen wrote:
> On Sun, 2005-02-06 at 23:34 -0600, Brian Hurt wrote:
> 
> > optimizations to it.  Of course, the more I look at SSA, the more it looks 
> > like a functional language to me.  So, in effect, the GCC optimization 
> 
> While the single-assignment aspect of SSA could be considered
> "functional", representing control flow using blocks and branches can't.

Yeah it can, it has been proven SSA is equivalent to
a purely functional representation. Branches are done with CPS.
Sorry I can't find the paper: the paper was actually written
to explain *why* SSA is easy to analyse.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Ville-Pertti Keinonen]

On Tue, 2005-02-08 at 03:58 +1100, skaller wrote:
> On Mon, 2005-02-07 at 21:57, Ville-Pertti Keinonen wrote:
> > 
> > While the single-assignment aspect of SSA could be considered
> > "functional", representing control flow using blocks and branches can't.
> 
> Yeah it can, it has been proven SSA is equivalent to
> a purely functional representation. Branches are done with CPS.
> Sorry I can't find the paper: the paper was actually written
> to explain *why* SSA is easy to analyse.

It's kind of equivalent (IIRC SSA can be transformed to CPS, but (full)
CPS can't be transformed trivially into SSA), but I still think SSA is
not functional in style.  Blocks are an imperative concept.

SSA also does nothing to address the interesting parts of compiling
functional languages - dealing with functions and calls.

Re: [Caml-list] The boon of static type checking

[skaller]

On Mon, 2005-02-07 at 21:57, Ville-Pertti Keinonen wrote:
> On Sun, 2005-02-06 at 23:34 -0600, Brian Hurt wrote:
> 
> > optimizations to it.  Of course, the more I look at SSA, the more it looks 
> > like a functional language to me.  So, in effect, the GCC optimization 
> 
> While the single-assignment aspect of SSA could be considered
> "functional", representing control flow using blocks and branches can't.
> 
> > Don't assume that inlining is optimization.  Actually, it generally isn't.  
> 
> Note that for OCaml, more aggressive inlining could be a significant
> improvement, not because it would eliminate calls, but because it could
> eliminate closures. 

Well, Felix can eliminate direct calls, and without
any complex flow control. This is done precisely
to eliminate closures, since in Felix the overhead
is quite large. In addition, the code is much smaller.
For example, this code:

for {i=0;} {i<10} {i++;} { 
  for(j=0} ...
    for {k=0}

consisting of 8 or so nested loops, where 'for'
is actually a HOF, and curried functions are
represented by a function which returns
the closure of a nested function.

This code takes a LONG time to run without
optimisation -- it has to create 4 closures
to do a loop .. and in the inner loop
that's expensive!

However since all the arguments are manifest,
the whole thing can be inlined, resulting in 
a chain of conditional gotos with some increments
which runs 100-1000 times faster and is 20 times
smaller.

> Obviously this doesn't apply to C++.

Sure it does -- although C++ doesn't have proper
function closures, it does have other
related facilities -- applicative objects,
and methods for example. What it does
lack is lexical scoping, meaning you have
to construct closures by hand (or use Felix
which does it for you :).

In some senses, in C++ inlinling is used to 
eliminate abstraction and turn typed code
into untyped code (after type checking),
where Ocaml would use a different technique.

So perhaps inlining in Ocaml 'isn't usually
an optimisation' but in C++ it is mandatory.
Not inlining at all isn't even marginally acceptable:
without it you'd have to use casts as in C,
and forget OO style abstraction (eg get/set methods)
because it would impact performance.

In addition, note that function calls can cost
a lot more than just a CALL machine instruction:
don't forget functions have arguments ... and
also use registers.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Ken Rose]

Brian Hurt wrote:

> I note with humor that the big new optimization in GCC is the SSA-Tree 
> form- "Single Static Assignment".  The idea behind SSA is that you can 
> only assign a variable a value when you create it, you can not change it 
> latter.  Once you express C++ in SSA, it's a lot easier to apply a lot of 
> optimizations to it.  Of course, the more I look at SSA, the more it looks 
> like a functional language to me.  

The thought has occurred to others, as well.  See
www.cs.princeton.edu/~appel/papers/ssafun.pdf

  - ken

Re: [Caml-list] The boon of static type checking

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 7, 2005, at 8:58 AM, skaller wrote:

> Yeah it can, it has been proven SSA is equivalent to
> a purely functional representation. Branches are done with CPS.
> Sorry I can't find the paper: the paper was actually written
> to explain *why* SSA is easy to analyse.
>
 From a reply to a post I made on <http://www.lambda-the-ultimate.org>, 
at <http://lambda-the-ultimate.org/node/view/511#comment-4021>:

"A Correspondence between Continuation-Passing Style and Static Single 
Assignment" at <http://mumble.net/~kelsey/papers/cps-ssa.ps.gz>, and 
"SSA is Functional Programming" at 
<http://www.cs.princeton.edu/~appel/papers/ssafun.pdf>.
>
> -- 
> John Skaller, mailto:skaller@users.sf.net
> voice: 061-2-9660-0850,
> snail: PO BOX 401 Glebe NSW 2037 Australia
> Checkout the Felix programming language http://felix.sf.net
>
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
Best regards,
Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iEYEARECAAYFAkIHq+YACgkQO3fYpochAqLoHQCgsXHXbnGKKaZsn0irNPoX7hX2
DkkAoLB9wmglgErs4Ayj6SS6KrUt4P+5
=zN17
-----END PGP SIGNATURE-----

Re: [Caml-list] The boon of static type checking

[skaller]

On Tue, 2005-02-08 at 03:58, skaller wrote:
> On Mon, 2005-02-07 at 21:57, Ville-Pertti Keinonen wrote: 
> > 
> > While the single-assignment aspect of SSA could be considered
> > "functional", representing control flow using blocks and branches can't.
> 
> Yeah it can, it has been proven SSA is equivalent to
> a purely functional representation. Branches are done with CPS.
> Sorry I can't find the paper: the paper was actually written
> to explain *why* SSA is easy to analyse.

Actually, here is the paper:

http://citeseer.ist.psu.edu/appel98ssa.html


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Damien Doligez]

On Feb 5, 2005, at 01:58, Jon Harrop wrote:

> Latest Debian Sarge. The commands should have been "M-x 
> caml-types-show-type"

My mistake, sorry.

> However, I can't figure out how to display whole types (it only 
> displays the
> first 70 chars or so).

Open the buffer named *caml-types* in a new window, the types are 
displayed
there in addition to the minibuffer.

You can also activate the "resize minibuffer mode" of emacs.

-- Damien

Re: [Caml-list] The boon of static type checking

[Brian Hurt]

On Mon, 7 Feb 2005, Michael Walter wrote:

> On Sun, 6 Feb 2005 23:34:02 -0600 (CST), Brian Hurt <bhurt@spnz.org> wrote:
> > Probably a bad idea, but I've got to jump in here.
> > 
> > Full disclosure: I *hate* C++.  Mainly because I've actually written real
> > programs in it.  The next time I have to use C++ in any sort of serious
> > way I'm registering c++sucks.com and starting a website to catalog all the
> > different ways C++ sucks.  Feel free to stop reading at this point.
> :-)
> 
> > ...
> > > g++ seems to generate better
> > > code than ocamlopt for similar simple problems
> > > (see Alioth for quantitative evidence given silly
> > > set of sample 'problems')
> > 
> > Yep.  And, conservatively, 10 times as much effort has gone into the gcc
> > optimizer as the Ocaml optimizer.  Possibly 100 times.  For, according to
> > Alioth, about a 10% improvement.  It's only with gcc 3.x that C++ managed
> > to beat Ocaml on performance.
> More effort having gone into gcc and better performance of gcc are
> arguments pro gcc, right? ;-)

If the 10-30% performance advantage (best case) is the difference between 
success and failure, then maybe.  Of course, going to a professional C/C++ 
complier like Intel's cc, or IBM's xlc, will buy you another 5-10% over 
GCC, as they've put maybe 10x more effort into their compilers than has 
gone into gcc.


This is, of course, assuming that a) you are falling into the best case
situation, and b) you'd have implemented the same algorithm in both cases,
and c) time to implement is irrelevent.  Of course, if time to implement
really is irrelevent, than going to hand tuned assembly will buy you 
another 10-30%, generally, and occassionally 2x performance (SSE/Altivec 
optimizations).

> 
> > > IMHO the single major inefficiency in C++ is also a source
> > > of efficiency -- lack of a garbage collector.
> > 
> > It's a source of efficiency on the small scale- it's easy to write a 1,000
> > line program with hand allocation.  Rather harder to write a 10,000 line
> > program, and a major bitch to write a 100,000 line program without garbage
> > collection.
> Personally I like it that in C++ you actually have the choice to use
> appropriate garbage collection schemes when you desire to do (yep,
> multiple kind of GCs for different subsystems/data/... is a win).
> Makes it easier with > 1,000,000 line programs :-)

Yes!  Having a choice means you can fuck it up!

And I disbeleive the "makes it easier with large programs" statement.  
It's contrary to all evidence I've seen, and all my experience.  The 
complexity of a program is, I've postulated, a function of the number of 
interactions between different parts of the code.  And that therefor the 
innate complexity approximately scales with the square of the number of 
lines of code- so a 10,000 line program is 100 times as complicated as a 
1,000 line program.  Brooks has evidence of this as well.

So the trick to managing complexity is limiting the interactions (to just 
the interactions needed).  Unexpected/unintended interactions are 
generally called "bugs".  As a side note, this is one of the really nice 
things about applicative semantics.

Now, if there are multiple different "memory management domains", that 
require different behaviors, you are now introducing new interactions to 
the program.  This is introducing complexity. 

A classic example of this problem in action.  I actually encountered this 
in real code (of course, this is the distilled example, the real example 
was spread out over a few tens of thousands of lines of code):

#include <string>
#include <iostream>

class base {
    public:
        virtual char * getName(void) = 0;
};
                                                                                
class exA : public base {
    public:
        char * getName(void) { return "exA"; }
};
                                                                                
class exB : public base {
    private:
        char * name;
    public:
        exB() {
            name = new char[4];
            strcpy(name, "exB");
        }
        virtual ~exB() { delete[] name; }
        char * getName(void) { return name; }
};

class exC : public base {
    public:
        char * getName(void) {
           char * retval = new char[4];
           strcpy(retval, "exC");
           return retval;
        }
};

void breakMe(base * ptr) {
    char * name = ptr->getName();
    delete ptr;
    std::cout << "Object name was \"" << name << "\".\n";
    delete[] name;
}
                                                                                



> > Don't assume that inlining is optimization.  Actually, it generally isn't.
> > Having actually timed it on modern hardware, a function call costs like
> > 2-3 clock cycles these days.  Plus 1-2 clock cycles per argument.  This is
> > compared to the 10-30 clock cycles a mispredicted branch costs, the 20+
> > clock cycles an L1 cache miss/L2 cache hit costs, and the 100-350+ clock
> > cycles of an L2 cache miss/memory fetch.
> Inlining for very small functions generally is an optimization.

Very small functions, yes.  But it's less of an optimization than people 
think, and (especially in C++) it gets way overused.

Allowing the programmer to force some functions to be inlined is right up 
there with allowing the programmer to force some variables to be stored in 
registers in usefullness.

Brian

Re: [Caml-list] The boon of static type checking

[Brian Hurt]

On Mon, 7 Feb 2005, Marcin 'Qrczak' Kowalczyk wrote:

> Brian Hurt <bhurt@spnz.org> writes:
> 
> > Hint: I've yet to meet a compiler that couldn't turn x/32 into 
> > x >> 5.
> 
> Actually this is incorrect when x is a signed type (and might be
> negative).

I've just compiled the code:
signed long foo(signed long x) {
    return x/32;
}

with gcc -O1 (gcc version 3.2.2, Redhat 9.0 default for the x86), and got 
the assembly language output:
foo:
        pushl   %ebp
        movl    %esp, %ebp
        movl    8(%ebp), %eax
        testl   %eax, %eax
        jns     .L2
        addl    $31, %eax
.L2:
        sarl    $5, %eax
        leave
        ret

Note the use of a sarl instruction, instead of a div instruction.

By the same logic, compiling:

let foo x = x / 32;;

under Ocamlopt (3.08.1, x86 on Redhat) we get the function:
camlEx2__foo_57:
.L100:
        sarl    $1, %eax
        testl   %eax, %eax
        jge     .L101
        addl    $31, %eax
.L101:  sarl    $5, %eax
        lea     1(%eax, %eax), %eax
        ret

While it's not technically a >> operator, a shift operator (as opposed to 
a divide) is being used.

Brian

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Sat, 12 Feb 2005, Brian Hurt wrote:

> And I disbeleive the "makes it easier with large programs" statement.  
> It's contrary to all evidence I've seen, and all my experience.  The 
> complexity of a program is, I've postulated, a function of the number of 
> interactions between different parts of the code.  And that therefor the 
> innate complexity approximately scales with the square of the number of 
> lines of code- so a 10,000 line program is 100 times as complicated as a 
> 1,000 line program.  Brooks has evidence of this as well.

I don't think this is true. It certainly is for spaghetti code, but isn't 
it just the essence of structured programming to avoid having complexity 
scale like (lines)^2?

There are both quite general and strong reasons why one 
should expect the complexity of programs of roughly the same "style" 
(whatever one has to invent to make a proper, meaningful notion out of 
this) to obey a scaling law of the form

 [nontrivial interactions] ~ [lines]^N

but not necessarily with an integer exponent. I furthermore strongly 
suppose that this exponent should depend a lot on the programmer.

> Very small functions, yes.  But it's less of an optimization than people 
> think, and (especially in C++) it gets way overused.
> 
> Allowing the programmer to force some functions to be inlined is right up 
> there with allowing the programmer to force some variables to be stored in 
> registers in usefullness.

Sure. Never forget that inlining increases the amount of memory and cache 
bandwidth needed for getting the code into the CPU.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[skaller]

On Sun, 2005-02-13 at 02:22, Brian Hurt wrote:
[inlining isn't usually a win]

I think it is language and context dependent.

Felix code (actual client program):

Without inlining:

$ wc -l hw.cpp hw.hpp
   14499 hw.cpp
    6818 hw.hpp
   21317 total

$ ls -l hw.o
-rw-r--r--  1 gchilds  unknown  831492 11 Feb 14:58 hw.o

With inlining

$ wc -l hw.cpp hw.hpp
    4264 hw.cpp
    1336 hw.hpp
    5600 total$ ls -l hw.o
-rw-r--r--  1 gchilds  unknown  116172 11 Feb 14:49 hw.o

4 -> 1 source code compression, 8 -> 1 object code
compression mainly due to inlining .. isn't a win??

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Brian Hurt]

On Sat, 12 Feb 2005, Thomas Fischbacher wrote:

> 
> On Sat, 12 Feb 2005, Brian Hurt wrote:
> 
> > And I disbeleive the "makes it easier with large programs" statement.  
> > It's contrary to all evidence I've seen, and all my experience.  The 
> > complexity of a program is, I've postulated, a function of the number of 
> > interactions between different parts of the code.  And that therefor the 
> > innate complexity approximately scales with the square of the number of 
> > lines of code- so a 10,000 line program is 100 times as complicated as a 
> > 1,000 line program.  Brooks has evidence of this as well.
> 
> I don't think this is true. It certainly is for spaghetti code, but isn't 
> it just the essence of structured programming to avoid having complexity 
> scale like (lines)^2?

Structured programming just has a different constant factor.  Also, what
sort of programming you're doing also changes the constant factors.  
Brooks himself noticed this- that compilers seemed to be about 3 times as 
difficult per LOC as normal programs, and operating systems about 3 times 
more difficult still.  Not sure if this still holds.

> 
> There are both quite general and strong reasons why one 
> should expect the complexity of programs of roughly the same "style" 
> (whatever one has to invent to make a proper, meaningful notion out of 
> this) to obey a scaling law of the form
> 
>  [nontrivial interactions] ~ [lines]^N
> 
> but not necessarily with an integer exponent. I furthermore strongly 
> suppose that this exponent should depend a lot on the programmer.

Obviously N > 1.  I'd also argue that N <= 2.  But I think N is closer to 
2 than to 1, i.e. N > 1.5.

Assume 1,000 lines = 1 day of work (I generally toss off a thousand line 
program in a day)- how long does a 10,000 line program take?  With N=2, 
the 10KLOC program takes about 100 days, or 5 man-months.  You're right, 
that's long.  With N=1.5, it takes ~31 days, or 6 weeks.  This is closer.  
With N=1.75, it takes ~56 days (11 weeks).  Assuming 5 days/week and 20 
days/month.  So, you're right- an N in the range of 1.5-1.75 sounds about 
right.

Note that with N=1.5, a 100,000 program takes 1,000 man-days, or 50 
man-months (4 man-years), and a 1,000,000 line program takes man 
centuries.

The important point is the scaling is exponential, not linear.

Brian

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Sat, 12 Feb 2005, Brian Hurt wrote:

> Note that with N=1.5, a 100,000 program takes 1,000 man-days, or 50 
> man-months (4 man-years), and a 1,000,000 line program takes man 
> centuries.
> 
> The important point is the scaling is exponential, not linear.

Sorry, that's power-law scaling.

Exponential would mean that it's of the form a*exp(x/b), with some 
dimensionful constant a.

power-law scaling is the only behaviour that can be expected from 
scale-invariant systems. That is, take some complex system which may well 
be determined by staggeringly complicated short-distance effects (say, 
intra-orbital quantum interaction between magnetic atoms - can it get 
any worse than that?).

Then, look at this system at larger and larger scales. Try to find a way 
to describe it which allows you to perform a scale transformation, that 
is, look at interactions/interrelations between clusters, in such a way 
that the scale-transformed system can be described in a formally 
equivalent way to the original system, only with other interaction 
parameters.

Then, study the flow of your system parameters under many many 
re-scalings. There are different types of behaviour, the most simple cases
one can expect are:

(i) Some parameters blow up.

(ii) Some parameters vanish.

(iii) Some parameters reach non-trivial fixed points.

If you have (i), this means - more or less - your system doesn't scale. We 
will not consider this any further.

(ii) means that at very large scales, a lot of the special characteristics 
drop out, only those that can exhibit proper scaling behaviour survive. 
Namely those of (iii). Interestingly, one finds that frequently, one can 
easily enumerate and fully classify those few effects that survive 
scaling. This leads to the interesting observation that quite many systems 
that may be determined by wildly different micro-effects show precisely 
the same macroscopic behaviour.

All in all, power-law behaviour is what should be normally expected for 
questions that do not have an obvious characteristic scale. What's the 
typical size of a software project? Here, I'd expect power-law behaviour, 
as there is no natural answer.

Indeed:

grep Installed-Size /var/lib/dpkg/available|perl -pe 'm/: (\d+)/;$h[$1/100]++}{$n=0;$_=join "\n",map{$n++." ".(0+$_)}@h[1..100]'>/tmp/a;echo -e 'set logscale x\nset logscale y\nplot "/tmp/a" with impulses, 2600*x**-1.25,1000*exp(-x/20)\npause 20'|gnuplot /proc/self/fd/0

See what I mean? Exponential behaviour *does* have a characteristic scale: 
the size increase over which the number of projects is reduced by 1/2.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Michael Walter]

On Sat, 12 Feb 2005 09:22:10 -0600 (CST), Brian Hurt <bhurt@spnz.org> wrote:
> On Mon, 7 Feb 2005, Michael Walter wrote:
> 
> > On Sun, 6 Feb 2005 23:34:02 -0600 (CST), Brian Hurt <bhurt@spnz.org> wrote:
> > > Probably a bad idea, but I've got to jump in here.
> > >
> > > Full disclosure: I *hate* C++.  Mainly because I've actually written real
> > > programs in it.  The next time I have to use C++ in any sort of serious
> > > way I'm registering c++sucks.com and starting a website to catalog all the
> > > different ways C++ sucks.  Feel free to stop reading at this point.
> > :-)
> >
> > > ...
> > > > g++ seems to generate better
> > > > code than ocamlopt for similar simple problems
> > > > (see Alioth for quantitative evidence given silly
> > > > set of sample 'problems')
> > >
> > > Yep.  And, conservatively, 10 times as much effort has gone into the gcc
> > > optimizer as the Ocaml optimizer.  Possibly 100 times.  For, according to
> > > Alioth, about a 10% improvement.  It's only with gcc 3.x that C++ managed
> > > to beat Ocaml on performance.
> > More effort having gone into gcc and better performance of gcc are
> > arguments pro gcc, right? ;-)
> 
> If the 10-30% performance advantage (best case) is the difference between
> success and failure, then maybe.  Of course, going to a professional C/C++
> complier like Intel's cc, or IBM's xlc, will buy you another 5-10% over
> GCC, as they've put maybe 10x more effort into their compilers than has
> gone into gcc.
> 
> This is, of course, assuming that a) you are falling into the best case
> situation, and b) you'd have implemented the same algorithm in both cases,
> and c) time to implement is irrelevent.  Of course, if time to implement
> really is irrelevent, than going to hand tuned assembly will buy you
> another 10-30%, generally, and occassionally 2x performance (SSE/Altivec
> optimizations).
Time to implement is obviously relevant.

> > > > IMHO the single major inefficiency in C++ is also a source
> > > > of efficiency -- lack of a garbage collector.
> > >
> > > It's a source of efficiency on the small scale- it's easy to write a 1,000
> > > line program with hand allocation.  Rather harder to write a 10,000 line
> > > program, and a major bitch to write a 100,000 line program without garbage
> > > collection.
> > Personally I like it that in C++ you actually have the choice to use
> > appropriate garbage collection schemes when you desire to do (yep,
> > multiple kind of GCs for different subsystems/data/... is a win).
> > Makes it easier with > 1,000,000 line programs :-)
> 
> Yes!  Having a choice means you can fuck it up!
Sure. That's part of the game, trading the "shooting yourself in the
lag" factor versus the benefits you get from it.

> And I disbeleive the "makes it easier with large programs" statement.
I was talking about that it's easier to write a > 1,000,000 line
program (possibly partially) with GC than without GC.

> It's contrary to all evidence I've seen, and all my experience.  The
> complexity of a program is, I've postulated, a function of the number of
> interactions between different parts of the code.  And that therefor the
> innate complexity approximately scales with the square of the number of
> lines of code- so a 10,000 line program is 100 times as complicated as a
> 1,000 line program.  Brooks has evidence of this as well.
I sense bad abstractions.

> Now, if there are multiple different "memory management domains", that
> require different behaviors, you are now introducing new interactions to
> the program.  This is introducing complexity.
And reducing complexity for all the code which uses GC'ed memory
management. Again, a tradeoff.

> [example feat. wrong abstractions & shooting yourself in the foot is fun]

> > > Don't assume that inlining is optimization.  Actually, it generally isn't.
> > > Having actually timed it on modern hardware, a function call costs like
> > > 2-3 clock cycles these days.  Plus 1-2 clock cycles per argument.  This is
> > > compared to the 10-30 clock cycles a mispredicted branch costs, the 20+
> > > clock cycles an L1 cache miss/L2 cache hit costs, and the 100-350+ clock
> > > cycles of an L2 cache miss/memory fetch.
> > Inlining for very small functions generally is an optimization.
> 
> Very small functions, yes.  But it's less of an optimization than people
> think, and (especially in C++) it gets way overused.
I don't think so. From my experience basically noone is using
__forceinline except for "very small functions" (on a probably mislead
attempt to outsmart the compiler), and everyone lets the compiler
decide which functions to inline.

What I'm saying is that choosing a language is a tradeoff, and the
kind of tradeoff C++ gives you can be a very good one (if not the
best) for particular problem domains. You can see evidence for such a
domain in the time spent on improving already very good compilers :-)

Michael

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Sat, 12 Feb 2005, Michael Walter wrote:

> What I'm saying is that choosing a language is a tradeoff, and the
> kind of tradeoff C++ gives you can be a very good one (if not the
> best) for particular problem domains.

Which would be for example?

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Tony Edgin]

On Sun, 13 Feb 2005 14:12, Thomas Fischbacher wrote:
> On Sat, 12 Feb 2005, Michael Walter wrote:
> > What I'm saying is that choosing a language is a tradeoff, and the
> > kind of tradeoff C++ gives you can be a very good one (if not the
> > best) for particular problem domains.
>
> Which would be for example?

An obvious example is code reuse.  For certain application domains, like for 
instance, military simulation, many libraries of C++ code have been written.  
Thus, for military simulation, C++ would be a good choice for reducing time 
to market.

Tony

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Sun, 13 Feb 2005, Tony Edgin wrote:

> On Sun, 13 Feb 2005 14:12, Thomas Fischbacher wrote:
> > On Sat, 12 Feb 2005, Michael Walter wrote:
> > > What I'm saying is that choosing a language is a tradeoff, and the
> > > kind of tradeoff C++ gives you can be a very good one (if not the
> > > best) for particular problem domains.
> >
> > Which would be for example?
> 
> An obvious example is code reuse.  For certain application domains, like for 
> instance, military simulation, many libraries of C++ code have been written.  
> Thus, for military simulation, C++ would be a good choice for reducing time 
> to market.

Could you give a specific example, but *please* one that is not related to 
killing people?

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Brian Hurt]

On Sat, 12 Feb 2005, Michael Walter wrote:

> > And I disbeleive the "makes it easier with large programs" statement.
> I was talking about that it's easier to write a > 1,000,000 line
> program (possibly partially) with GC than without GC.

OK.  I misunderstood you.  Sorry.

> > Very small functions, yes.  But it's less of an optimization than people
> > think, and (especially in C++) it gets way overused.
> I don't think so. From my experience basically noone is using
> __forceinline except for "very small functions" (on a probably mislead
> attempt to outsmart the compiler), and everyone lets the compiler
> decide which functions to inline.

You've had better experiences that I have, obviously.  I've met one too 
many programmers who said, in effect, "inlining a function makes it go 
faster, so I try to inline lots of my functions!"

> 
> What I'm saying is that choosing a language is a tradeoff, and the
> kind of tradeoff C++ gives you can be a very good one (if not the
> best) for particular problem domains. You can see evidence for such a
> domain in the time spent on improving already very good compilers :-)
> 

Actually, most of the time was spent improving the C compiler.  And, 
inthe case of Intel, IBM, etc., the Fortran compiler (less so with GCC).   
The C++ compiler got brought along for the ride.  There are good 
historical reasons why Ocaml doesn't use the GCC back end, but it'd be an 
interesting experiment to port Ocaml to the GCC back end and see how well 
it'd do.  Were I to write a new language, I'd definately target the GCC 
backend.

Brian

Re: [Caml-list] The boon of static type checking

[Michael Walter]

On Sat, 12 Feb 2005 20:27:56 -0600 (CST), Brian Hurt <bhurt@spnz.org> wrote:
> You've had better experiences that I have, obviously.  I've met one too
> many programmers who said, in effect, "inlining a function makes it go
> faster, so I try to inline lots of my functions!"
Ouch :-)

> > What I'm saying is that choosing a language is a tradeoff, and the
> > kind of tradeoff C++ gives you can be a very good one (if not the
> > best) for particular problem domains. You can see evidence for such a
> > domain in the time spent on improving already very good compilers :-)
> Actually, most of the time was spent improving the C compiler.  [...]
That's true, my statement should have read "C (or C++)".

Cheers,
Michael

Re: [Caml-list] The boon of static type checking

[Daniel Heck]

On Sun, 13 Feb 2005 03:12:03 +0100 (CET) Thomas Fischbacher wrote:


> > An obvious example is code reuse.  For certain application domains, like for 
> > instance, military simulation, many libraries of C++ code have been written.  
> > Thus, for military simulation, C++ would be a good choice for reducing time 
> > to market.
> 
> Could you give a specific example, but *please* one that is not related to 
> killing people?

Having seen you start this very discussion on another mailing list,
would you *please* consider taking this question to a list that is
dedicated to C++, just for a change? Frankly, your only reason for
subscribing to this ML seems to be to extol the virtues of Lisp and to
bash C++, which is a nuisance for everyone who reads it in the hope of
learning about OCaml...

Thanks,
Daniel

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Sun, 13 Feb 2005, Daniel Heck wrote:

> > Could you give a specific example, but *please* one that is not related to 
> > killing people?
> 
> Having seen you start this very discussion on another mailing list,
> would you *please* consider taking this question to a list that is
> dedicated to C++, just for a change?

(1) I had to search a bit through my memories, but you are right in this 
point: this discussion also came up once on one other list I'm active on, 
which is (a) non-public and (b) on which a very broad range of topics are 
covered. Just had a check: my last article on that list was an explanation 
from a physicist's point of view of the infeasibility of using a research 
reactor's enriched uranium to build a nuclear weapon, after that question 
arouse. The next-to-last was personal experience concerning notebook 
repairs. My last message before that was about college fees in germany. We 
would have to go back in time through considerably more than a dozen of 
other topics that came up and where I posted a comment before we
reach that single one programming language thread that arouse during 
the last five years.

Perhaps only an independent member of both lists may objectively judge 
this, but to me it seems a bit as if you just picked out that one single 
discussion out of so many I've been involved in, furthermore from a 
non-public list - so that no one can check, to make me appear in a bad 
light. I really don't want to claim that this is bad intention from your 
side, especially as I would not expect members of that other list to 
spread libel, but you should be able to understand that, taking above 
facts into account, it actually has to look a lot like such from my 
perspective.

(2) Concerning the objective claim that some of the C++ related postings 
on this list by me (and others) were a bit off-topic, you are right. Just 
as the discussion about state in Haskell, say. It might well be that some
people consider this inappropriate to a larger extent, and some to a 
lesser. My personal point of view on this issue is that ocaml is a fringe 
language, and so one cannot reasonably do "just ocaml", but it is 
important to also look left and right, see what other people who come 
from different languages are lacking, and what they find great about 
ocaml. The perl community is especially great in listening to and learning 
from other communities, incorporating useful approaches in an 
unbureaucratic way (even if they sometimes choose inappropriate approaches 
which they later have to correct). At least, that was, I'd say, the 
primary key to perl's success: the ability to listen and understand.

> Frankly, your only reason for
> subscribing to this ML seems to be to extol the virtues of Lisp and to
> bash C++, which is a nuisance for everyone who reads it in the hope of
> learning about OCaml...

If this is your personal impression, I fear, you totally must have missed 
the point in many of my postings!

Let's concentrate on "the Lisp issue": yes, I would describe myself as a 
mostly Lisp guy. Nonwithstanding, I have done existing, real, working, 
free, known, large applications in ocaml. Concerning more recent 
discussions here, I tried to give a somewhat balanced view what aspects 
of ocaml I - as a lisp hacker - both especially love and especially 
dislike - you can check that in the archive.

Ocaml is a new language, and as every new language, it first of all has to 
justify why it is appropriate to destroy synergy effects: every new
language introduces barriers. Imagine you want to solve a problem which 
has two complex aspects for which libraries exist, but unfortunately, the 
one is written in, say, python, and the other one in sml/nj. Great 
situation. Besides this, every new language requires the 
re-implementation of a lot of core functionality in the form of 
libraries, which introduces lots of opportunities for both security 
problems and bad design, and burns a lot of human work.

I think ocaml does have a score of features that justify its existence, 
see an earlier posting of mine that gives detailed reasons.

But the discussion also showed that there seem to be widespread deep 
misconceptions concerning one simple question: what ideas *truly require* 
the invention of a new language, as they can not be added on top of an 
existing system? After all, we have perl, pike, php, python, rexx, ruby, 
scheme, tom, tcl, and many many more. Typically, these started out as "a 
quick small elegant solution to a specific problem" that required full 
programming flexibility. Gradually, people realized that they needed X 
plus support for more data types, then IPC (networking), database 
access, threads, various mime support, then... So, they all became more or 
less functionally equivalent (with different ugly quirks in the different 
systems), with the one distinguishing feature of nothing more than 
their indivuduality, that is, they cannot easily talk to one another. 
I consider this quite unfortunate, but perhaps not everyone will. 
Could it have been avoided, and if, how, and what can we learn for the 
future? I think the key to all this is the question: does X really require 
the introduction of a new programming language, or can we implement X as a 
library on top of an existing system? People just too hastily jump on the 
wagon of building a new language.

As I saw it as evident in one case that practically no one would believe 
me otherwise, I showed in one posting - by explicit construction -
that it is very well possible to add pattern matching to a language 
(which happened to be lisp, as it's the most extensible one) as a library. 
Hence constructor pattern matching support evidently does *not* belong to 
the set of properties that inevitably require the construction of an 
entire new system from scratch. Was this relevant to ocaml? For the 
following reason I strongly think so: whoever wants to introduce ocaml 
for a new project usually has to give a good justification for this.
I occasionally get into precisely this situation myself. And I 
prefer to then use reasons that convince because they are true, and 
stay away from those which merely are easily believed but wrong.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Michael Walter]

Your argument regarding Lisp and O'caml ignores the fact that
programming languages are to a large part about syntax - for obviously
valid reasons like accessability, maintainability, expressiveness,
etc.

I feel I've mentioned that so many times it should be in some FAQ ;o)

Michael


On Sun, 13 Feb 2005 19:28:42 +0100 (CET), Thomas Fischbacher
<Thomas.Fischbacher@physik.uni-muenchen.de> wrote:
> On Sun, 13 Feb 2005, Daniel Heck wrote:
> 
> > > Could you give a specific example, but *please* one that is not related to
> > > killing people?
> >
> > Having seen you start this very discussion on another mailing list,
> > would you *please* consider taking this question to a list that is
> > dedicated to C++, just for a change?
> 
> (1) I had to search a bit through my memories, but you are right in this
> point: this discussion also came up once on one other list I'm active on,
> which is (a) non-public and (b) on which a very broad range of topics are
> covered. Just had a check: my last article on that list was an explanation
> from a physicist's point of view of the infeasibility of using a research
> reactor's enriched uranium to build a nuclear weapon, after that question
> arouse. The next-to-last was personal experience concerning notebook
> repairs. My last message before that was about college fees in germany. We
> would have to go back in time through considerably more than a dozen of
> other topics that came up and where I posted a comment before we
> reach that single one programming language thread that arouse during
> the last five years.
> 
> Perhaps only an independent member of both lists may objectively judge
> this, but to me it seems a bit as if you just picked out that one single
> discussion out of so many I've been involved in, furthermore from a
> non-public list - so that no one can check, to make me appear in a bad
> light. I really don't want to claim that this is bad intention from your
> side, especially as I would not expect members of that other list to
> spread libel, but you should be able to understand that, taking above
> facts into account, it actually has to look a lot like such from my
> perspective.
> 
> (2) Concerning the objective claim that some of the C++ related postings
> on this list by me (and others) were a bit off-topic, you are right. Just
> as the discussion about state in Haskell, say. It might well be that some
> people consider this inappropriate to a larger extent, and some to a
> lesser. My personal point of view on this issue is that ocaml is a fringe
> language, and so one cannot reasonably do "just ocaml", but it is
> important to also look left and right, see what other people who come
> from different languages are lacking, and what they find great about
> ocaml. The perl community is especially great in listening to and learning
> from other communities, incorporating useful approaches in an
> unbureaucratic way (even if they sometimes choose inappropriate approaches
> which they later have to correct). At least, that was, I'd say, the
> primary key to perl's success: the ability to listen and understand.
> 
> > Frankly, your only reason for
> > subscribing to this ML seems to be to extol the virtues of Lisp and to
> > bash C++, which is a nuisance for everyone who reads it in the hope of
> > learning about OCaml...
> 
> If this is your personal impression, I fear, you totally must have missed
> the point in many of my postings!
> 
> Let's concentrate on "the Lisp issue": yes, I would describe myself as a
> mostly Lisp guy. Nonwithstanding, I have done existing, real, working,
> free, known, large applications in ocaml. Concerning more recent
> discussions here, I tried to give a somewhat balanced view what aspects
> of ocaml I - as a lisp hacker - both especially love and especially
> dislike - you can check that in the archive.
> 
> Ocaml is a new language, and as every new language, it first of all has to
> justify why it is appropriate to destroy synergy effects: every new
> language introduces barriers. Imagine you want to solve a problem which
> has two complex aspects for which libraries exist, but unfortunately, the
> one is written in, say, python, and the other one in sml/nj. Great
> situation. Besides this, every new language requires the
> re-implementation of a lot of core functionality in the form of
> libraries, which introduces lots of opportunities for both security
> problems and bad design, and burns a lot of human work.
> 
> I think ocaml does have a score of features that justify its existence,
> see an earlier posting of mine that gives detailed reasons.
> 
> But the discussion also showed that there seem to be widespread deep
> misconceptions concerning one simple question: what ideas *truly require*
> the invention of a new language, as they can not be added on top of an
> existing system? After all, we have perl, pike, php, python, rexx, ruby,
> scheme, tom, tcl, and many many more. Typically, these started out as "a
> quick small elegant solution to a specific problem" that required full
> programming flexibility. Gradually, people realized that they needed X
> plus support for more data types, then IPC (networking), database
> access, threads, various mime support, then... So, they all became more or
> less functionally equivalent (with different ugly quirks in the different
> systems), with the one distinguishing feature of nothing more than
> their indivuduality, that is, they cannot easily talk to one another.
> I consider this quite unfortunate, but perhaps not everyone will.
> Could it have been avoided, and if, how, and what can we learn for the
> future? I think the key to all this is the question: does X really require
> the introduction of a new programming language, or can we implement X as a
> library on top of an existing system? People just too hastily jump on the
> wagon of building a new language.
> 
> As I saw it as evident in one case that practically no one would believe
> me otherwise, I showed in one posting - by explicit construction -
> that it is very well possible to add pattern matching to a language
> (which happened to be lisp, as it's the most extensible one) as a library.
> Hence constructor pattern matching support evidently does *not* belong to
> the set of properties that inevitably require the construction of an
> entire new system from scratch. Was this relevant to ocaml? For the
> following reason I strongly think so: whoever wants to introduce ocaml
> for a new project usually has to give a good justification for this.
> I occasionally get into precisely this situation myself. And I
> prefer to then use reasons that convince because they are true, and
> stay away from those which merely are easily believed but wrong.
> 
> --
> regards,               tf@cip.physik.uni-muenchen.de              (o_
>  Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
> (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
> (if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Sun, 13 Feb 2005, Michael Walter wrote:

> Your argument regarding Lisp and O'caml ignores the fact that
> programming languages are to a large part about syntax - for obviously
> valid reasons like accessability, maintainability, expressiveness,
> etc.
> 
> I feel I've mentioned that so many times it should be in some FAQ ;o)

With a parser generator (take zebu, for example) and, say,
SET-DISPATCH-MACRO-CHARACTER, I just as well can give you any syntax you 
want on top of lisp. But I think you understand if I don't post code 
that explicitly demonstrates how to do that now.

So, syntax just as well is "nothing more than a library". Once the 
mechanics is there, I can easily place any arbitrary notation on top of 
that. If you want, I can make my pattern matching in lisp look exactly 
like ocaml pattern matching.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Michael Walter]

On Sun, 13 Feb 2005 22:42:29 +0100 (CET), Thomas Fischbacher
<Thomas.Fischbacher@physik.uni-muenchen.de> wrote:
> 
> On Sun, 13 Feb 2005, Michael Walter wrote:
> 
> > Your argument regarding Lisp and O'caml ignores the fact that
> > programming languages are to a large part about syntax - for obviously
> > valid reasons like accessability, maintainability, expressiveness,
> > etc.
> >
> > I feel I've mentioned that so many times it should be in some FAQ ;o)
> 
> With a parser generator (take zebu, for example) and, say,
> SET-DISPATCH-MACRO-CHARACTER, I just as well can give you any syntax you
> want on top of lisp. But I think you understand if I don't post code
> that explicitly demonstrates how to do that now.

This has obvious restrictrions in Common Lisp (you even mentioned one
of them in UPPERCASE-LETTERS :). The fact that few people actually
extend the syntax of CL beyond mere S-expressions also indicates that
(the usual counter goes like "we are happy with S-expressions", which
I believe is not the entire story :). [1]

I can imagine, though, that there might eventually be a language (or
environment), which gets rid of some of those restrictions, which is
one of the reasons why I've a.. more open attitude to new programming
languages and environments :) [2,3]

Michael

[1] It works great for embedding XML into CL, though :-)
http://blog.leetspeak.org/wp-content/xmlhack.png
[2] e.g. Logix, see http://logix.livelogix.com/
[3] e.g. IP, see google &
http://www.aisto.com/roeder/paper/IntentionalProgramming.ppt

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Sun, 13 Feb 2005, Michael Walter wrote:

> > > I feel I've mentioned that so many times it should be in some FAQ ;o)
> > 
> > With a parser generator (take zebu, for example) and, say,
> > SET-DISPATCH-MACRO-CHARACTER, I just as well can give you any syntax you
> > want on top of lisp. But I think you understand if I don't post code
> > that explicitly demonstrates how to do that now.
> 
> This has obvious restrictrions in Common Lisp (you even mentioned one
> of them in UPPERCASE-LETTERS :).

You can just as well put another REPL at the top. MAXIMA is an example of 
just one system that does precisely that.

> The fact that few people actually
> extend the syntax of CL beyond mere S-expressions also indicates that
> (the usual counter goes like "we are happy with S-expressions", which
> I believe is not the entire story :). [1]

Well, the point is that many people may initially think that the system 
should have a "proper" syntax (including McCarthy, by the way), but upon 
working with it for some time discover that actually it's much more 
convenient if it does not.

I must say, I did it, transliterating much of (it's not a lot of work 
to be done, yet not quite complete) C's syntax to lisp, with the 
intention to provide people with their own syntax which they even can 
extend, say, for new operators, should they feel like it. I know I 
probably will never use it. Neither will _any_ advanced lisp hacker, I 
suppose. But it should help some people if you build them a bridge.

> I can imagine, though, that there might eventually be a language (or
> environment), which gets rid of some of those restrictions, which is
> one of the reasons why I've a.. more open attitude to new programming
> languages and environments :) [2,3]

My point is: one should not agglomerate things prematurely that better 
first should be studied in isolation. In particular, it certainly is 
important to understand what syntactic conventions help human programmers 
to express their thoughts. It is also of undeniable importance to 
understand run-time system issues such as what data types and 
functionality a language should offer. For example, I by now consider 
perl's concept of "plurality" (@x behaving like "those thingies" and \@x 
behaving like "this array") as far not as useful than it was intended to 
be.

Just as one can learn more about the structure of the proton by probing it 
with electrons rather than with another proton, I would not mind a more 
systematic approach towards finding out what makes a good language and 
what not than throwing together a set of features from various corners, 
shaking it well, and seeing how pretty the thing one gets turns out to be.

Geologists do (mineral-forming) experiments of just that kind as well.
They call it "cook and look".

So, again, syntax is not by itself an essential feature of the language.


What then does make ocaml so attractive that one should consider it as a 
basis for a project?

* It's far easier to learn and handle than most other languages for casual 
users. (Like, say, people who are not programmers, but do a bit of 
programming nevertheless.)

* It's got a quite reasonable free compiler that can produce somewhat 
compact standalone binaries, and is available for a variety of platforms.

* There is support for lambda abstraction.

I don't think there are many systems that unify these properties. At 
least, it's not true for lisp, haskell, perl, python, c, c++, java, 
sml/nj, ...

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Michael Walter]

On Mon, 14 Feb 2005 00:59:21 +0100 (CET), Thomas Fischbacher
<Thomas.Fischbacher@physik.uni-muenchen.de> wrote:
> 
> On Sun, 13 Feb 2005, Michael Walter wrote:
> 
> > > > I feel I've mentioned that so many times it should be in some FAQ ;o)
> > >
> > > With a parser generator (take zebu, for example) and, say,
> > > SET-DISPATCH-MACRO-CHARACTER, I just as well can give you any syntax you
> > > want on top of lisp. But I think you understand if I don't post code
> > > that explicitly demonstrates how to do that now.
> >
> > This has obvious restrictrions in Common Lisp (you even mentioned one
> > of them in UPPERCASE-LETTERS :).
> 
> You can just as well put another REPL at the top. MAXIMA is an example of
> just one system that does precisely that.

Exactly! That's creating a new language.

> [...]
> In particular, it certainly is
> important to understand what syntactic conventions help human programmers
> to express their thoughts. 
> [...]
> So, again, syntax is not by itself an essential feature of the language.
I rate the "human factor" important enough to consider it as an
essential feature for programming languages meant to be used by
humans.

Of course, if you decide to use S-expressions primarily as a compiler
target that's an entirely different issue (to bad that this path
hasn't been explored that much, besides maybe Dylan).

Michael

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Sun, 13 Feb 2005, Michael Walter wrote:

> > You can just as well put another REPL at the top. MAXIMA is an example of
> > just one system that does precisely that.
> 
> Exactly! That's creating a new language.

Ok, then if you see it that way: the major difference then is that you do 
not have to go through the daunting process of implementing all of the 
runtime system so that it is (1) fast, (2) bugfree, (3) sufficiently 
complete to be useful. Furthermore, you gain the ability to use 
already existing libraries.

Anything else is in >95% of all cases an exercise in Greenspunning.

> > [...]
> > So, again, syntax is not by itself an essential feature of the language.
> I rate the "human factor" important enough to consider it as an
> essential feature for programming languages meant to be used by
> humans.

Well, yes, but this can be studied to great extent without the drawbacks 
of creating incompatibility boundaries, see above.

> Of course, if you decide to use S-expressions primarily as a compiler
> target that's an entirely different issue (to bad that this path
> hasn't been explored that much, besides maybe Dylan).

That's how it's supposed to be. Especially scheme tries to be nothing else 
but just the minimal "functional assembly language". So one can put other 
languages on top of it.

Judging from the .NET CLR specification, I'd say that conceptually, scheme 
does the far better job, as it does not treat such lots of non-fundamental 
ad-hoc concepts (in particular, everything related to OO) as fundamental.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Michael Walter]

On Mon, 14 Feb 2005 01:42:11 +0100 (CET), Thomas Fischbacher
<Thomas.Fischbacher@physik.uni-muenchen.de> wrote:
> On Sun, 13 Feb 2005, Michael Walter wrote:
> > > You can just as well put another REPL at the top. MAXIMA is an example of
> > > just one system that does precisely that.
> >
> > Exactly! That's creating a new language.
> 
> Ok, then if you see it that way: the major difference then is that you do
> not have to go through the daunting process of implementing all of the
> runtime system so that it is (1) fast, (2) bugfree, (3) sufficiently
> complete to be useful. Furthermore, you gain the ability to use
> already existing libraries.

This applies to C, as well.

> > > [...]
> > > So, again, syntax is not by itself an essential feature of the language.
> > I rate the "human factor" important enough to consider it as an
> > essential feature for programming languages meant to be used by
> > humans.
> 
> Well, yes, but this can be studied to great extent without the drawbacks
> of creating incompatibility boundaries, see above.

Yeah, for instance by compiling to C :) This is for instance the path
chosen by GHC (although they are switching over to a C-- backend).

> > Of course, if you decide to use S-expressions primarily as a compiler
> > target that's an entirely different issue (to bad that this path
> > hasn't been explored that much, besides maybe Dylan).
> 
> That's how it's supposed to be.
But that is not what it *is* like in > 95% of "the Lisp world". See my
last mail - the typical Lisper seldomly/never "escapes" S expressions,
and I strongly believe this is not because S expressions are the
"best" syntax.

Michael

Re: [Caml-list] The boon of static type checking

[Michael Walter]

On Mon, 14 Feb 2005 01:42:11 +0100 (CET), Thomas Fischbacher
<Thomas.Fischbacher@physik.uni-muenchen.de> wrote:
> Judging from the .NET CLR specification, I'd say that conceptually, scheme
> does the far better job, as it does not treat such lots of non-fundamental
> ad-hoc concepts (in particular, everything related to OO) as fundamental.

I forgot to reply to this point. This again is a tradeoff between
conceptual purity and real world pragmatics. In this case, for
instance interopability is simplified by narrowing the design space
for CLR languages. It obviously avoids quite a bit of "Greenspunning",
as well.

The world is not black is not white-ly yours,
Michael

Re: [Caml-list] The boon of static type checking

[Michael Vanier]

> Date: Sun, 13 Feb 2005 20:11:54 -0500
> From: Michael Walter <michael.walter@gmail.com>
> 
> > > Of course, if you decide to use S-expressions primarily as a compiler
> > > target that's an entirely different issue (to bad that this path
> > > hasn't been explored that much, besides maybe Dylan).
> > 
> > That's how it's supposed to be.
> But that is not what it *is* like in > 95% of "the Lisp world". See my
> last mail - the typical Lisper seldomly/never "escapes" S expressions,
> and I strongly believe this is not because S expressions are the
> "best" syntax.
> 
> Michael
> 

[Way off-topic -- sorry!]

But S-expressions are arguably the best syntax for writing macro
expansions.  Since an S-expression is trivially parseable and dispatches on
its first symbol it's very easy to write source code transformations in
lisp, and lispers seem to value this much more than aficionados of other
languages.  More recent efforts like metaocaml and template Haskell (not to
mention camlp4 and C++ templates) suggest that the notion that source code
transformations can be a useful part of programming is getting more
popular.

Mike

Re: [Caml-list] The boon of static type checking

[Michael Walter]

On Sun, 13 Feb 2005 17:46:24 -0800 (PST), Michael Vanier
<mvanier@cs.caltech.edu> wrote:
> [Way off-topic -- sorry!]
> 
> But S-expressions are arguably the best syntax for writing macro
> expansions.
Yeah, they are well-suited for that.

> More recent efforts like metaocaml and template Haskell (not to
> mention camlp4 and C++ templates) suggest that the notion that source code
> transformations can be a useful part of programming is getting more
> popular.
And this is great! What bothers me about S-expressions is that their
sole advantage seems to lie in technical reasons, like the ones
mentioned above. I strongly believe that there might be better ways to
allow for both intuitive code transformations and expressive,
"human-friendly" syntax. That's why I'm personally very interested in
efforts such as Metaocaml, ocamlp4, TH, Logix, IP, etc.

Michael

Re: [Caml-list] The boon of static type checking

[skaller]

On Mon, 2005-02-14 at 08:42, Thomas Fischbacher wrote:
> On Sun, 13 Feb 2005, Michael Walter wrote:
> 
> > Your argument regarding Lisp and O'caml ignores the fact that
> > programming languages are to a large part about syntax 
> > I feel I've mentioned that so many times it should be in some FAQ ;o)

> With a parser generator (take zebu, for example) and, say,
> SET-DISPATCH-MACRO-CHARACTER, I just as well can give you any syntax you 
> want on top of lisp.

> So, syntax just as well is "nothing more than a library".

However this indicates you're a Lisper. What you say isn't
the case for most other languages. Lisp has a trivial grammar,
as does, for example, Forth.

Ocaml does indeed have a programmable front end with
the camlp4 system, indeed pattern matches have been
extended to include regexps with 'micmatch' package
using it.

However the idea that 'pattern matching' can just be
done with a library for Ocaml is wrong AFAICS.

Pattern matching is *fundamental* because, with
the exception of a couple of library functions
(hd, tl, fst, snd etc), it is the *only* way of accessing
inductive data type destructors.

Yes of course you can write a translator converting
language A to language B, but the idea that this
is always 'just syntax' misses the point -- there
is a level of complexity in such a transformation
where your translator isn't merely 'just a syntactic
tranform' but earns the title 'compiler'.

Would you call GHC: Haskell -> C 'just syntax'?
Even Ocaml 'just produces assembler'..
Is not a term rewriting system, including the whole
lambda calculus 'just a syntactic transformer'?


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[skaller]

On Mon, 2005-02-14 at 10:59, Thomas Fischbacher wrote:

> I must say, I did it, transliterating much of (it's not a lot of work 
> to be done, yet not quite complete) C's syntax to lisp, with the 
> intention to provide people with their own syntax which they even can 
> extend, say, for new operators, should they feel like it. I know I 
> probably will never use it. Neither will _any_ advanced lisp hacker, I 
> suppose. But it should help some people if you build them a bridge.

What else is a compiler but a bridge to assembler?
In that light, one might say 'it would help some
novices program that can't do assembler' .. 

> My point is: one should not agglomerate things prematurely that better 
> first should be studied in isolation. 

You should know from Quantum Physics this idea must
be taken with few grain of salt and a couple of Schroedinger cats.

> Just as one can learn more about the structure of the proton by probing it 
> with electrons rather than with another proton, I would not mind a more 
> systematic approach towards finding out what makes a good language and 
> what not than throwing together a set of features from various corners, 
> shaking it well, and seeing how pretty the thing one gets turns out to be.

We're open to suggestions on how to do this, for surely
no one knows. All the maths in the world won't create a good
programming language, even though it may help weed out poor ones.

> So, again, syntax is not by itself an essential feature of the language.

Sure it is: it is what distinguishes the system from a
mere library. In particular, it provides a way of
enforcing constraints mere library calls cannot
-- and perhaps someone else can list other advantages of languages
over lower level raw API calls?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Paul Snively]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 13, 2005, at 6:22 PM, skaller wrote:

> What else is a compiler but a bridge to assembler?
> In that light, one might say 'it would help some
> novices program that can't do assembler' ..
>
...

> You should know from Quantum Physics this idea must
> be taken with few grain of salt and a couple of Schroedinger cats.
>
...

> We're open to suggestions on how to do this, for surely
> no one knows. All the maths in the world won't create a good
> programming language, even though it may help weed out poor ones.
>
> ...

> Sure it is: it is what distinguishes the system from a
> mere library. In particular, it provides a way of
> enforcing constraints mere library calls cannot
> -- and perhaps someone else can list other advantages of languages
> over lower level raw API calls?
>
I'm reminded of the Alan Perlis epigram "Beware of the Turing tar-pit 
in which everything is possible but nothing of interest is easy." The 
Ward's Wiki page on it at <http://c2.com/cgi/wiki?TuringTarpit> is 
pretty good. Given the thread, the final paragraph of the page is 
likely to throw gasoline on the fire.

> -- 
> John Skaller, mailto:skaller@users.sf.net
> voice: 061-2-9660-0850,
> snail: PO BOX 401 Glebe NSW 2037 Australia
> Checkout the Felix programming language http://felix.sf.net
>
>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
Best regards,
Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iEYEARECAAYFAkIQW5UACgkQO3fYpochAqIT5gCggSMJNdavab3/S1KSRZ6pEFnX
kNMAoOMMMT4eig8NbtpTr37YLQicSn3O
=yWZF
-----END PGP SIGNATURE-----

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Mon, 14 Feb 2005, skaller wrote:

> > So, again, syntax is not by itself an essential feature of the language.
> 
> Sure it is: it is what distinguishes the system from a
> mere library.

But that's precisely the issue!

There is many a system around out there, take FORM, take GAP, take LiE, 
take R, take whatever you want, that provides highly specialized 
functionality in form of a language, whereas it would be 20 times more 
useful to have it in form of a library.

I saw colleagues in string theory wrapping LiE up with expect, just to 
make it scriptable. As if a string theorist should have to waste his time 
with such nonsense.

My point is: a library in virtually any case is much more valuable than a 
new language.

Syntax is just make-up. Superficial, arbitrary, vain. What really makes up 
the character of a language happens beneath.

Say what you want, I consider it as grossly misguided to invent a new 
language just to have "something greater than a mere library".


-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Mon, 14 Feb 2005, skaller wrote:

> On Mon, 2005-02-14 at 10:59, Thomas Fischbacher wrote:
> 
> > I must say, I did it, transliterating much of (it's not a lot of work 
> > to be done, yet not quite complete) C's syntax to lisp, with the 
> > intention to provide people with their own syntax which they even can 
> > extend, say, for new operators, should they feel like it. I know I 
> > probably will never use it. Neither will _any_ advanced lisp hacker, I 
> > suppose. But it should help some people if you build them a bridge.
> 
> What else is a compiler but a bridge to assembler?

A language is more than just syntax plus a rule how to translate that to 
machine code. One may come to such a conclusion by looking e.g. at C, but 
frequently, much more happens between syntax and machine code.

Take the GC. Take fundamental data types.

> > Just as one can learn more about the structure of the proton by probing it 
> > with electrons rather than with another proton, I would not mind a more 
> > systematic approach towards finding out what makes a good language and 
> > what not than throwing together a set of features from various corners, 
> > shaking it well, and seeing how pretty the thing one gets turns out to be.
> 
> We're open to suggestions on how to do this, for surely
> no one knows. All the maths in the world won't create a good
> programming language, even though it may help weed out poor ones.

Exactly. One of the greatest medical achievements was not the discovery of 
Penicillin, but the introduction of statistical methods and the 
double-blind experiment. Only this allowed us to do systematic studies of 
what's useful and what's not.

No one has a clue how to systematically do a quantitative study of what 
makes a useful language. We even do not seem to be really interested in 
finding the appropriate questions to ask.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: The boon of static type checking

[Stefan Monnier]

> But S-expressions are arguably the best syntax for writing macro
> expansions.  Since an S-expression is trivially parseable and dispatches on

That's exactly where syntax is important: depending on your syntax some
things are easy/concise and others aren't, so people end up adapting a very
different programming style.  It doesn't mean that one syntax is
intrinsically better than another, but just that syntax does matter.


        Stefan

Re: [Caml-list] Re: The boon of static type checking

[Thomas Fischbacher]

On Mon, 14 Feb 2005, Stefan Monnier wrote:

> > But S-expressions are arguably the best syntax for writing macro
> > expansions.  Since an S-expression is trivially parseable and dispatches on
> 
> That's exactly where syntax is important: depending on your syntax some
> things are easy/concise and others aren't, so people end up adapting a very
> different programming style.  It doesn't mean that one syntax is
> intrinsically better than another, but just that syntax does matter.

Macroexpansion - if done properly - is done at the level of parsed trees. 
Hence, yes, it does matter if this is obscured by syntax or not, that is: 
whether your language does provide a special "mostly arbitrary" syntax or 
whether it does not.

Superficial differences in various ad-hoc notations, say "{}" vs. 
"BEGIN/END" and such, by far do not matter as much as questions whether 
there is a machine code compiler available, or whether memory management 
works in a proper way.

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)

Re: [Caml-list] The boon of static type checking

[Martin Berger]

> That's how it's supposed to be. Especially scheme tries to be nothing else 
> but just the minimal "functional assembly language". So one can put other 
> languages on top of it.

the words "functional" and "minimal" may be considered contradictory as the basic
primitive of functional programming, beta reduction, is a very heavy operation that
can successfully be decomposed into more lightweight operations like:

    - state change + conditional branching.
    - continuation passing
    - name-passing interaction.

(of those the third is the most elementary and general and encompasses the others).
putting any of those on top of beta-reduction generally leads to something ugly.
functional abstractions are extremely useful in many computational situations, but
they are high-level, not something one can use successfully as a foundation to start
from. several decades of failed attempts at founding (the semantics of) computation
on lambda calculus shows this. the difficulties of finding convincing hoare-logics for
ML-like languages, a problem that has really only been solved this year, and on the
basis of pi-calculus, is another indication in this direction.

as an aside, are there any good program logics for languages with macro-facilities like
lisp-dialects?

martin

Re: [Caml-list] The boon of static type checking

[skaller]

On Tue, 2005-02-15 at 04:29, Martin Berger wrote:

> as an aside, are there any good program logics for languages with macro-facilities like
> lisp-dialects?

Aren't macros a way to do lazy evaluation in an eager language?
EG in Ocaml a 'macro':

  cond (c,t,f) --> match c with | true ->  t | false -> f

maps the eager functional syntax onto a lazily evaluated syntax,
strangely doing so by hyper-active evaluation?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

Re: [Caml-list] The boon of static type checking

[Thomas Fischbacher]

On Mon, 14 Feb 2005, Martin Berger wrote:

> > That's how it's supposed to be. Especially scheme tries to be nothing else 
> > but just the minimal "functional assembly language". So one can put other 
> > languages on top of it.
> 
> the words "functional" and "minimal" may be considered contradictory as the basic
> primitive of functional programming, beta reduction, is a very heavy operation that
> can successfully be decomposed into more lightweight operations like:
> 
>     - state change + conditional branching.
>     - continuation passing
>     - name-passing interaction.
> 
> (of those the third is the most elementary and general and encompasses the others).
> putting any of those on top of beta-reduction generally leads to something ugly.
> functional abstractions are extremely useful in many computational situations, but
> they are high-level, not something one can use successfully as a foundation to start
> from. several decades of failed attempts at founding (the semantics of) computation
> on lambda calculus shows this. the difficulties of finding convincing hoare-logics for
> ML-like languages, a problem that has really only been solved this year, and on the
> basis of pi-calculus, is another indication in this direction.

Now that sounds interesting! Can you provide me with a few references?

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)