trying to explain some words

[Francois-Rene Rideau]

>>>: Paul Dufresne
>>: Sami Mäkelä
>: Paul Dufresne

>> and for example SML doesn't have looping constructs AFAIK
You are very ignorant to utter such non-sense!
There _are_ looping constructs in SML and in CAML as well;
they are seldom used because they are so desperately clumsier
and less expressive than tail-recursion and general recursion!

> Hum, well, frankly I did not used ML much. I wanted to tell that
> ML is easier to learn from someone coming from C world than Haskell
> or Clean can be.
Of course! ML is an impure language (understand: imperative),
whereas Haskell and Clean (and Mercury) are pure languages
(that can nonetheless express single-threaded imperative computations
very easily through linear variables and monadic combinators).

> Actually, I guess I would suggest a newcomer to functionnal
> language to learn Scheme in the first place
	http://www.tunes.org/Review/Languages.html#Scheme
points to many sites with good tutorials or references to good books.

>>> ML is not object-oriented.
OCAML is, as the name says.

>>> Lambda Calculus appeared in mathematics in
>>> about 1920, but it is only 'recently' that some programming language
>>> begin to allow all what the lambda calculus let you do.
LISP exists since 1958, and Scheme (that has _real_ lambdas) since 1974 or so.
Haskell and Clean, based on pure typed lambda-calculus,
or already mature languages, too.

>>> What Fare was telling me, is that there is a new mathematical-model
>>> called join-calculus that could be seen as a new kind of pi-calculus.
No. It could be seen as a dialect of pi-calculus, but actually,
I prefer to see it as a formalized version of Carl Hewitt's long known
actor model, where every join definition term is an actor.

>>> At first glance the main difference with pi-calculus is
>>> that it integrate better with functions in the language (that is
>>> with lambda-calculus,
That is true, but the reason for that is deep
(a CPS transform makes the join calculus with functions
into the core join-calculus).
The Pi-calculus also allows for arbitrary world-wide synchronization,
which is a Bad Thing(TM); known implementations (mostly Pict)
all restrict the Pi-calculus so as to be implementable
in a distributed way.
All these reasons, and more, are why
the join calculus is definitely the Right Thing(TM) over the Pi-calculus.

> this characteristic [non-determinism] should
> be shared by join-calculus and pi-calculus,
Of course. As soon as you have general parallel and asynchronous computation,
you have non-determinism.

> The other private e-mail was asking me why not just program these
> communication stuff through the Internet in plain C.
Programming a asynchronous distributed application in C
is even worse than implementing a high-level language in assembly.

> I invite people to read the Tunes's pages on programming languages.
> Search in the Review project on http://www.tunes.org. I have tried to
> reorganize this page on the wiki server too, some months ago.
Yup.

Best regards,

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project!   http://www.tunes.org/  ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics  | Project for  a Free Reflective  Computing System ]
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.