Version française
Home     About     Download     Resources     Contact us    
Browse thread
Estimating the size of the ocaml community
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Thomas Fischbacher <Thomas.Fischbacher@P...>
Subject: Re: [Caml-list] The boon of static type checking

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)