[Caml-list] ocaml killer

[Caml-list] ocaml killer

[Alexander Epifanov]

Hello,

I have read message about Skala language, and I think (it's only my IMHO),
that ocaml have no future without some features, like concurrent programming
(CP) and chance to use libraries from the other languages.

1) Erlang uses build in CP, but Skala has a library for it, IMHO it would be a
good way for ocaml feature. Thread module isn't enough for effective usage of
CP.

2) No one would use ocaml without libraries, and it's so hard to rewrite them
all in ocaml. external functions aren't enough to use libraries from Languages
like java or c++.

Are any plans about these two features exists ?

Thanks.

-- 
Gentoo Linux http://www.gentoo.org

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

Re: [Caml-list] ocaml killer

[Alex Baretta]

Alexander Epifanov wrote:
> Hello,
> 
> I have read message about Skala language, and I think (it's only my IMHO),
> that ocaml have no future without some features, like concurrent programming
> (CP) and chance to use libraries from the other languages.

Thanks for sharing you "humble opinion" with us. Let me share mine with 
you: my company has chosen Ocaml as it's primary general purpose 
language and is devoting most of it's R&D efforts towards new 
development based on/for Ocaml.

> 1) Erlang uses build in CP, but Skala has a library for it, IMHO it would be a
> good way for ocaml feature. Thread module isn't enough for effective usage of
> CP.

Ever heard about message passing? Did you ever try running a 
multithreaded application on a server cluster?

> 2) No one would use ocaml without libraries, and it's so hard to rewrite them
> all in ocaml. external functions aren't enough to use libraries from Languages
> like java or c++.

No one. Except maybe Xavier et al. in the Cristal group. Except maybe 
myself and all of my colleagues. Except all of those who subscribe to 
the mailing list. Except hundreds of researchers and students.

How about "No one you know would use Ocaml with Java bindings".  No one 
I know would use a language with Java bindings for any realistic project.

> Are any plans about these two features exists ?

I definitely hope Xavier will not waste his time coding JNI's to use 
ocaml within Java.

Alex

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

Re: [Caml-list] ocaml killer

[Alexander Epifanov]

On 09:56 Tue 27 Jan     , Alex Baretta wrote:
> Alexander Epifanov wrote:
> >Hello,
> >
> >I have read message about Skala language, and I think (it's only my IMHO),
> >that ocaml have no future without some features, like concurrent 
> >programming
> >(CP) and chance to use libraries from the other languages.
> 
> Thanks for sharing you "humble opinion" with us. Let me share mine with 
> you: my company has chosen Ocaml as it's primary general purpose 
> language and is devoting most of it's R&D efforts towards new 
> development based on/for Ocaml.
> 
> >1) Erlang uses build in CP, but Skala has a library for it, IMHO it would 
> >be a
> >good way for ocaml feature. Thread module isn't enough for effective usage 
> >of
> >CP.
> 
> Ever heard about message passing? Did you ever try running a 
> multithreaded application on a server cluster?
Everybody has server clusters?
> 
> >2) No one would use ocaml without libraries, and it's so hard to rewrite 
> >them
> >all in ocaml. external functions aren't enough to use libraries from 
> >Languages
> >like java or c++.
> 
> No one. Except maybe Xavier et al. in the Cristal group. Except maybe 
> myself and all of my colleagues. Except all of those who subscribe to 
> the mailing list. Except hundreds of researchers and students.
You want to use ocaml for yourself only? Do You need more popularity of
ocaml ? OCaml isn't used a lot for commercial projects.
> 
> How about "No one you know would use Ocaml with Java bindings".  No one +
> I know would use a language with Java bindings for any realistic project.
> 
> >Are any plans about these two features exists ?
> 
> I definitely hope Xavier will not waste his time coding JNI's to use 
> ocaml within Java.
I agree with you, JNI isn't the best solution. But what time do you need to
implement the part of CPAN's libraries for example ? Ocaml is the great
language for the BIG projects. but it hasn't simple libraries for small
projects. Of course, It doesn't need them for "academical" language. 
> 
> Alex

-- 
Gentoo Linux http://www.gentoo.org

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

Re: [Caml-list] ocaml killer

[Shawn Wagner]

On Tue, Jan 27, 2004 at 12:43:51PM +0300, Alexander Epifanov wrote:

> I agree with you, JNI isn't the best solution. But what time do you need to
> implement the part of CPAN's libraries for example ? Ocaml is the great
> language for the BIG projects. but it hasn't simple libraries for small
> projects. Of course, It doesn't need them for "academical" language. 

The obvious thing to do is for people to, if they write stuff (Be it big
modules or small little utility functions) that would be useful to the
general population of ocaml users, is release that code so we get those
small libraries. Then the hard part: Advertising them and getting people to
use them.

Something I'm thinking of doing after I finish getting some much-delayed
updates to a couple of the libraries I maintain out the door: A
general-purpose config file library; the sort of thing that'd be useful for
most non-trivial applications that, as far as I'm aware, doesn't exit for
ocaml yet.

-- 
Shawn Wagner
shawnw@speakeasy.org

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

Re: [Caml-list] ocaml killer

[skaller]

CPAN for Ocaml? No chance. We actually need:

CPAN-GPL
CPAN-LGPL
CPAN-BSD
CPAN-FFAU
CPAN-Q

-- 
John Max Skaller, mailto:skaller@tpg.com.au
snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net




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

Re: [Caml-list] ocaml killer

[james woodyatt]

everyone--

At the risk of flogging a dead horse...

I still think the simplest and most effective way to improve the 
utility of Ocaml in the construction of large software projects is not 
a CPAN-like distributed source library-- it's a federated naming 
authority for library modules, like you find in the Java Runtime 
Environment.

This is the *one* glaring hole in the language as far as I'm concerned, 
and if I ever find myself in a position to do something about it-- I 
just might have to hack the tool chain myself to get what I want.  (On 
the other hand, the one glaring hole in the implementation that INRIA 
provides, if you ask me, is the incomplete support for dynamic module 
load/link in native code programs.  This is not that big a problem for 
me, but it would be nice to have.)

In all other respects, I'm more than satisfied-- I'm tickled pink.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

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

Re: [Caml-list] ocaml killer

[Alex Baretta]

Ken Rose wrote:
> Alex Baretta wrote:
> 
> 
> 
> Where do you work?  Are they hiring?  (only half ;-) )
> 
>  - ken

We are actually hiring. We are in Milano, Italy.

Alex

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

Re: [Caml-list] ocaml killer

[David Fox]

Alex Baretta wrote:

> Ken Rose wrote:
>
>> Alex Baretta wrote:
>>
>>
>>
>> Where do you work?  Are they hiring?  (only half ;-) )
>>
>>  - ken
>
>
> We are actually hiring. We are in Milano, Italy.
>
> Alex
>
We're looking for an ocaml + operating system person, if you want to 
come to San Diego.


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

Re: [Caml-list] ocaml killer

[Eray Ozkural]

On Wednesday 28 January 2004 15:29, David Fox wrote:
> Alex Baretta wrote:
> > Ken Rose wrote:
> >> Alex Baretta wrote:
> >>
> >>
> >>
> >> Where do you work?  Are they hiring?  (only half ;-) )
> >>
> >>  - ken
> >
> > We are actually hiring. We are in Milano, Italy.
> >
> > Alex
>
> We're looking for an ocaml + operating system person, if you want to
> come to San Diego.

w00t! ocaml positions!

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

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

Re: [Caml-list] ocaml killer

[Alexander Danilov]

Alexander Epifanov wrote:

>Hello,
>
>I have read message about Skala language, and I think (it's only my IMHO),
>that ocaml have no future without some features, like concurrent programming
>(CP) and chance to use libraries from the other languages.
>
>1) Erlang uses build in CP, but Skala has a library for it, IMHO it would be a
>good way for ocaml feature. Thread module isn't enough for effective usage of
>CP.
>
>  
>
CP is not the main feature. For example, Perl has no good and stable CP 
support, but it is very popular.
There are no so many task, that need CP.

>2) No one would use ocaml without libraries, and it's so hard to rewrite them
>all in ocaml. external functions aren't enough to use libraries from Languages
>like java or c++.
>
>Are any plans about these two features exists ?
>
>Thanks.
>
>  
>
http://wiki.tcl.tk/critcl - here is interesting idea how to make 
bindings wuickly. I think it can be implemented in Ocaml,

The language will be preffered in many projects only when it have good 
repository of packages, policy of packaging libraries, modules, etc., 
simple mechanism to install this packages over the net and so on. So I 
think that for more popularity Ocaml need for something like CPAN 
http://www.cpan.org/ . Thats why I don't use Tcl, Ruby, Ocaml in real 
applications. If Ocaml community create packaging policy and network 
archive, than number of Ocaml developers will increase much faster.

Not CP, not multithreading can make programmer happy :), but CPAN can.

P.S.: I know, my English is terrible, I will try to make it better :)

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

Re: [Caml-list] ocaml killer

[Alexander Epifanov]

On 12:41 Tue 27 Jan     , Alexander Danilov wrote:
> Alexander Epifanov wrote:
> 
> >Hello,
> >
> >I have read message about Skala language, and I think (it's only my IMHO),
> >that ocaml have no future without some features, like concurrent 
> >programming
> >(CP) and chance to use libraries from the other languages.
> >
> >1) Erlang uses build in CP, but Skala has a library for it, IMHO it would 
> >be a
> >good way for ocaml feature. Thread module isn't enough for effective usage 
> >of
> >CP.
> >
> > 
> >
> CP is not the main feature. For example, Perl has no good and stable CP 
> support, but it is very popular.
> There are no so many task, that need CP.
Maybe. but Thread isn't the best solution.
> 
> >2) No one would use ocaml without libraries, and it's so hard to rewrite 
> >them
> >all in ocaml. external functions aren't enough to use libraries from 
> >Languages
> >like java or c++.
> >
> >Are any plans about these two features exists ?
> >
> >Thanks.
> >
> > 
> >
> http://wiki.tcl.tk/critcl - here is interesting idea how to make 
> bindings wuickly. I think it can be implemented in Ocaml,
> 
> The language will be preffered in many projects only when it have good 
> repository of packages, policy of packaging libraries, modules, etc., 
> simple mechanism to install this packages over the net and so on. So I 
> think that for more popularity Ocaml need for something like CPAN 
> http://www.cpan.org/ . Thats why I don't use Tcl, Ruby, Ocaml in real 
> applications. If Ocaml community create packaging policy and network 
> archive, than number of Ocaml developers will increase much faster.
> 
Yes, I can't use _only_ Ocaml for the projects.

> Not CP, not multithreading can make programmer happy :), but CPAN can.
nice phrase. I agree with you.
> 
> P.S.: I know, my English is terrible, I will try to make it better :)
My English more terrible, I'm just learning it :)

-- 
Gentoo Linux http://www.gentoo.org

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

Re: [Caml-list] ocaml killer

[Eric Stokes]

	Despite a little FUD (and bad English :P) I think this thread has a 
lot of good ideas in it. After reading it all it seems to me that Ocaml 
is in a transition period, more and more production oriented 
programmers are starting to pay serious attention to it. For my case, 
my organization has decided to migrate to Ocaml as our primary general 
purpose language. We have invested significant R&D into code written in 
Ocaml, and have recently launched our first production service written 
in it.
	That said, the concerns about libraries, and about a CPAN like 
repository are very good ones. There is a CPAN like repository for 
Ocaml (there are several), and while they are in a somewhat embryonic 
state, they are quite useable. The best example is the Ocaml link 
database http://www.npc.de/ocaml/linkdb/ almost all Ocaml libraries 
eventually get posted there. It is missing some features often 
associated with CPAN, however the most important feature of such a tool 
is that it serves as a directory of available libraries. The link 
database accomplishes this quite well, and serves the community well. 
GODI is looking to be a more complete CPAN clone for Ocaml, I have not 
played with it extensively yet, so I can't say too much more. Note 
also, that C and C++ have no central library repository, and yet they 
remain the industry standard general purpose languages. On the library 
side of things, there is a C interface, and a Perl interface, which 
opens up quite a lot of libraries to use from Ocaml. 	However, one of 
the main benefits of Ocaml is type safety, and using foreign language 
libraries throws away some of that type safety (the library is free to 
have grievous errors in it). The primary reason that my organization 
has switched to Ocaml is that we are under increasing pressure to write 
highly reliable software. From our point of view all of our libraries 
must eventually be rewritten in Ocaml, and the sooner the better. I 
don't think that the pressure we feel is without parallel elsewhere in 
the industry, so I think that Ocaml has quite a bright future as a 
production quality general purpose language.

On Jan 27, 2004, at 1:57 AM, Alexander Epifanov wrote:

> On 12:41 Tue 27 Jan     , Alexander Danilov wrote:
>> Alexander Epifanov wrote:
>>
>>> Hello,
>>>
>>> I have read message about Skala language, and I think (it's only my 
>>> IMHO),
>>> that ocaml have no future without some features, like concurrent
>>> programming
>>> (CP) and chance to use libraries from the other languages.
>>>
>>> 1) Erlang uses build in CP, but Skala has a library for it, IMHO it 
>>> would
>>> be a
>>> good way for ocaml feature. Thread module isn't enough for effective 
>>> usage
>>> of
>>> CP.
>>>
>>>
>>>
>> CP is not the main feature. For example, Perl has no good and stable 
>> CP
>> support, but it is very popular.
>> There are no so many task, that need CP.
> Maybe. but Thread isn't the best solution.
>>
>>> 2) No one would use ocaml without libraries, and it's so hard to 
>>> rewrite
>>> them
>>> all in ocaml. external functions aren't enough to use libraries from
>>> Languages
>>> like java or c++.
>>>
>>> Are any plans about these two features exists ?
>>>
>>> Thanks.
>>>
>>>
>>>
>> http://wiki.tcl.tk/critcl - here is interesting idea how to make
>> bindings wuickly. I think it can be implemented in Ocaml,
>>
>> The language will be preffered in many projects only when it have good
>> repository of packages, policy of packaging libraries, modules, etc.,
>> simple mechanism to install this packages over the net and so on. So I
>> think that for more popularity Ocaml need for something like CPAN
>> http://www.cpan.org/ . Thats why I don't use Tcl, Ruby, Ocaml in real
>> applications. If Ocaml community create packaging policy and network
>> archive, than number of Ocaml developers will increase much faster.
>>
> Yes, I can't use _only_ Ocaml for the projects.
>
>> Not CP, not multithreading can make programmer happy :), but CPAN can.
> nice phrase. I agree with you.
>>
>> P.S.: I know, my English is terrible, I will try to make it better :)
> My English more terrible, I'm just learning it :)
>
> -- 
> Gentoo Linux http://www.gentoo.org
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: 
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>

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

Re: [Caml-list] ocaml killer

[David Fox]

I would forward this post to some management folks around here if it 
didn't have the subject "ocaml killer"!  :-)

Eric Stokes wrote:

>     Despite a little FUD (and bad English :P) I think this thread has 
> a lot of good ideas in it. After reading it all it seems to me that 
> Ocaml is in a transition period, more and more production oriented 
> programmers are starting to pay serious attention to it. For my case, 
> my organization has decided to migrate to Ocaml as our primary general 
> purpose language. We have invested significant R&D into code written 
> in Ocaml, and have recently launched our first production service 
> written in it.
>     That said, the concerns about libraries, and about a CPAN like 
> repository are very good ones. There is a CPAN like repository for 
> Ocaml (there are several), and while they are in a somewhat embryonic 
> state, they are quite useable. The best example is the Ocaml link 
> database http://www.npc.de/ocaml/linkdb/ almost all Ocaml libraries 
> eventually get posted there. It is missing some features often 
> associated with CPAN, however the most important feature of such a 
> tool is that it serves as a directory of available libraries. The link 
> database accomplishes this quite well, and serves the community well. 
> GODI is looking to be a more complete CPAN clone for Ocaml, I have not 
> played with it extensively yet, so I can't say too much more. Note 
> also, that C and C++ have no central library repository, and yet they 
> remain the industry standard general purpose languages. On the library 
> side of things, there is a C interface, and a Perl interface, which 
> opens up quite a lot of libraries to use from Ocaml.     However, one 
> of the main benefits of Ocaml is type safety, and using foreign 
> language libraries throws away some of that type safety (the library 
> is free to have grievous errors in it). The primary reason that my 
> organization has switched to Ocaml is that we are under increasing 
> pressure to write highly reliable software. From our point of view all 
> of our libraries must eventually be rewritten in Ocaml, and the sooner 
> the better. I don't think that the pressure we feel is without 
> parallel elsewhere in the industry, so I think that Ocaml has quite a 
> bright future as a production quality general purpose language.
>
> On Jan 27, 2004, at 1:57 AM, Alexander Epifanov wrote:
>
>> On 12:41 Tue 27 Jan     , Alexander Danilov wrote:
>>
>>> Alexander Epifanov wrote:
>>>
>>>> Hello,
>>>>
>>>> I have read message about Skala language, and I think (it's only my 
>>>> IMHO),
>>>> that ocaml have no future without some features, like concurrent
>>>> programming
>>>> (CP) and chance to use libraries from the other languages.
>>>>
>>>> 1) Erlang uses build in CP, but Skala has a library for it, IMHO it 
>>>> would
>>>> be a
>>>> good way for ocaml feature. Thread module isn't enough for 
>>>> effective usage
>>>> of
>>>> CP.
>>>>
>>>>
>>>>
>>> CP is not the main feature. For example, Perl has no good and stable CP
>>> support, but it is very popular.
>>> There are no so many task, that need CP.
>>
>> Maybe. but Thread isn't the best solution.
>>
>>>
>>>> 2) No one would use ocaml without libraries, and it's so hard to 
>>>> rewrite
>>>> them
>>>> all in ocaml. external functions aren't enough to use libraries from
>>>> Languages
>>>> like java or c++.
>>>>
>>>> Are any plans about these two features exists ?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>> http://wiki.tcl.tk/critcl - here is interesting idea how to make
>>> bindings wuickly. I think it can be implemented in Ocaml,
>>>
>>> The language will be preffered in many projects only when it have good
>>> repository of packages, policy of packaging libraries, modules, etc.,
>>> simple mechanism to install this packages over the net and so on. So I
>>> think that for more popularity Ocaml need for something like CPAN
>>> http://www.cpan.org/ . Thats why I don't use Tcl, Ruby, Ocaml in real
>>> applications. If Ocaml community create packaging policy and network
>>> archive, than number of Ocaml developers will increase much faster.
>>>
>> Yes, I can't use _only_ Ocaml for the projects.
>>
>>> Not CP, not multithreading can make programmer happy :), but CPAN can.
>>
>> nice phrase. I agree with you.
>>
>>>
>>> P.S.: I know, my English is terrible, I will try to make it better :)
>>
>> My English more terrible, I'm just learning it :)
>>
>> -- 
>> Gentoo Linux http://www.gentoo.org
>>
>> -------------------
>> To unsubscribe, mail caml-list-request@inria.fr Archives: 
>> http://caml.inria.fr
>> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: 
>> http://caml.inria.fr/FAQ/
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: 
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


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

Re: [Caml-list] ocaml killer

[Richard Jones]

On Tue, Jan 27, 2004 at 08:43:51AM -0800, Eric Stokes wrote:
> programmers are starting to pay serious attention to it. For my case, 
> my organization has decided to migrate to Ocaml as our primary general 
> purpose language. We have invested significant R&D into code written in 

Which enlightened company is this?

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
PTHRLIB is a library for writing small, efficient and fast servers in C.
HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/

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

Re: [Caml-list] ocaml killer

[Eric Stokes]

On Jan 27, 2004, at 10:47 AM, Richard Jones wrote:

> On Tue, Jan 27, 2004 at 08:43:51AM -0800, Eric Stokes wrote:
>> programmers are starting to pay serious attention to it. For my case,
>> my organization has decided to migrate to Ocaml as our primary general
>> purpose language. We have invested significant R&D into code written 
>> in
>
> Which enlightened company is this?
>

The central IT of California State University Northridge. We're 
currently working on an open source
middleware suite written (largely) in Ocaml.
	Part of our R&D effort has involved taking over maintenance of 
ocamldap, and adding
significant features to it. We've also been working with GPS to add 
fast-cgi support to ocamlnet
(working code is in cvs awaiting release). In the future we'd like to 
do a native Ocaml ldap protocal
implementation for ocamldap. That means that we will probably end up 
implementing an ASN.1
compiler, and BER, DER, etc.. There is an ASN.1 compiler laying around 
that we might try to
resurrect, but we'll still need to implement BER, etc.. A working ASN.1 
environment would be great
for Ocaml, as it would allow lots of really cool protocals (such as 
SNMP) to be implemented easily.
We don't currently have a time frame for getting this done, and our 
metadirectory will probably take
priority.

Our directory managment daemon (written in ocaml) can be found at
www-qa.csun.edu/opensource/rmwd
(this site is in development, I'm literally scrambling to get it up :P. 
the final url may change.
I'll be posting  to the link database when its ready.)

Info on our meta-directory will be going up soon, it is not currently 
written in Ocaml, but we're planning
to do a rewrite in Ocaml fairly soon.

So that's the 5 minute summery of CSUN :P

> Rich.
>
> -- 
> Richard Jones. http://www.annexia.org/ http://www.j-london.com/
> Merjis Ltd. http://www.merjis.com/ - improving website return on 
> investment
> PTHRLIB is a library for writing small, efficient and fast servers in 
> C.
> HTTP, CGI, DBI, lightweight threads: 
> http://www.annexia.org/freeware/pthrlib/
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: 
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>

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

Re: [Caml-list] ocaml killer

[Eray Ozkural]

I think you're trolling.

Have a nice day,

On Tuesday 27 January 2004 08:32, Alexander Epifanov wrote:
> Hello,
>
> I have read message about Skala language, and I think (it's only my IMHO),
> that ocaml have no future without some features, like concurrent
> programming (CP) and chance to use libraries from the other languages.
>
> 1) Erlang uses build in CP, but Skala has a library for it, IMHO it would
> be a good way for ocaml feature. Thread module isn't enough for effective
> usage of CP.
>
> 2) No one would use ocaml without libraries, and it's so hard to rewrite
> them all in ocaml. external functions aren't enough to use libraries from
> Languages like java or c++.
>
> Are any plans about these two features exists ?
>
> Thanks.

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara  KDE Project: http://www.kde.org
http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://malfunct.iuma.com
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C

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

Re: [Caml-list] ocaml killer

[Chet Murthy]

Alexander,

I don't know what to say, except that clearly, you should spend some
time in the trenches, working with the COBOL of the 21st Century --
Java.

That's what I do for a living.  I've written extremely complex Java
systems.  I've debugged more Java code than anybody else at my current
employer, and I'm not kidding.

And, y'know what?

Java/the JVM still sux.

I left CAML in 1994, when it still didn't have a native-code
compiler.  I started hacking on Java in the spring of 1996.  I've got
code in (probably) every JVM.  I've debugged dozens of very large, and
hundreds of only somewhat large Java deployments, some of them in
situations involving large amounts of business at risk.

And y'know what?

Java/the JVM still sux.

"concurrency"!  You ever tried to use Java threads to do anything
meaningful?  Check out the J2EE spec.  It basically is BUILT around
NOT sharing anything between threads.

Oh, and y'know, we have a joke: "every Java bug is a connection-pool
(or resource-pool) bug".

Here's another: "When you arrive onsite,  grep for synchronized, and
if you see it, put your laptop back in your bag, tell 'em you're going
to get coffee, and don't come back".

Java/the JVM is not a systems-programming language.  Period.  Oh, and
I'll defend that against all comers.  Difference is, though, if you
wanna attack, I'll expect real examples, not the academic crap that
most programming language theorists throw around.

--chet--

P.S.  I came back to CAML for personal programming in 1999, and after
that four-year hiatus, during which I became a commercial JVM
internals guy, as well as a commercial transaction-processing
firefighter (think "Mr. Wolf" from _Pulp Fiction_).  So I think I have
the experience to compare, and the verdict seems manifestly
incontrovertible: Java/the JVM sux.

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

Re: [Caml-list] ocaml killer

[Martin Berger]

> Java/the JVM is not a systems-programming language.  Period.  Oh, and
> I'll defend that against all comers.  Difference is, though, if you
> wanna attack, I'll expect real examples, not the academic crap that
> most programming language theorists throw around.

i'll have to defend my profession here: which working programming
language theorist proposes java as a "systems-programming language"?
most of them are busy researching concurrency or pointer arithmetic
these days.

but i guess it depends what you mean by that "systems-programming
language". rather than attempting a definition (it's late here), i'll
point to C/C++ or Cyclone as examples.

martin

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

Re: [Caml-list] ocaml killer

[Chet Murthy]

>>>>> "MB" == Martin Berger <martinb@dcs.qmul.ac.uk> writes:

    MB> but i guess it depends what you mean by that
    MB> "systems-programming language". rather than attempting a
    MB> definition (it's late here), i'll point to C/C++ or Cyclone as
    MB> examples.

A "system" includes an application-server, a GUI, a database, a window
manager, a widget system, a GRID scheduler, a directory server, a
group communications toolkit and lots of other things.

Application programming, is really programming -inside- a system,
wherein programmers face strong limits on what they can do, with the
aim of keeping their code well-managed, controlled, and providing a
"managed environment" for the code's execution.

All of these things, in my opinion, benefit from being written in
high-level languages -- significantly higher than CCured and Cyclone.

The high-level abstraction capabilities of CAML shine here, and do
some of capabilities of Java in these applications.

BTW, people (fools) propose using Java to write all of those things I
describe above.

--chet--

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

Re: [Caml-list] ocaml killer

[Chet Murthy]

>>>>> "CM" == Chet Murthy <chet@watson.ibm.com> writes:

    CM> All of these things, in my opinion, benefit from being written
    CM> in high-level languages -- significantly higher than CCured
    CM> and Cyclone.

    CM> The high-level abstraction capabilities of CAML shine here,
    CM> and do some of capabilities of Java in these applications.

I wasn't clear here.  The high-level capabilities of both Java and
CAML are useful in writing such systems.  Too bad Java/the JVM's
behavioural attributes make it totally unsuited.  Ah, well.

For those who don't understand what I mean, take a look at
InstallShield MultiPlatform.  Also look at "javac" itself.  And "jar".
Ask yourself how such simple problems have admitted such awful
solutions in Java.  Marvel at the foolishness of the creators of these
artifacts.

--chet--

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

Re: [Caml-list] ocaml killer

[Martin Berger]

> A "system" includes an application-server, a GUI, a database, a window
> manager, a widget system, a GRID scheduler, a directory server, a
> group communications toolkit and lots of other things.
> 
> Application programming, is really programming -inside- a system,
> wherein programmers face strong limits on what they can do, with the
> aim of keeping their code well-managed, controlled, and providing a
> "managed environment" for the code's execution.

I agree.

> The high-level abstraction capabilities of CAML shine here, and do
> some of capabilities of Java in these applications.

 > I wasn't clear here.  The high-level capabilities of both Java and
 > CAML are useful in writing such systems.  Too bad Java/the JVM's
 > behavioural attributes make it totally unsuited.  Ah, well.

please allow me to compare Ocaml and Java from the lofty perspective
of a programming language theorist. both are mixed imperative/functional
languages (like all others). what are the *essential* differences?

Ocaml has/Java doesn't have

   * sum types
   * pattern matching as destructors for sum types
   * full function types (not restricted to first-order like java)
   * second-order types (will be added to java)

Java has/Ocaml doesn't have

   * reflection (maybe in ocaml, not sure at the moment)

there are probably other big differences, for example in the module system,
but let's ignore those.

if i'm right about this, then what java lacks is a more expressive
type system.

martin

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

Re: [Caml-list] ocaml killer

[Chet Murthy]

Martin,

[Maybe this is going off-topic.  Since I'm comparing Java to Caml,
I'll leave this cc'ed to the Caml list, but if there are further
responses, it might be good to take 'em offline.]

>>>>> "MB" == Martin Berger <martinb@dcs.qmul.ac.uk> writes:

    MB> please allow me to compare Ocaml and Java from the lofty
    MB> perspective of a programming language theorist. both are mixed
    MB> imperative/functional languages (like all others). what are
    MB> the *essential* differences?

    MB> if i'm right about this, then what java lacks is a more
    MB> expressive type system.

Your comparison of Java and Caml leaves out two of the most important
parts of CAML (from a systems-programmer perspective):

  (1) high-quality FFI (MUCH better than JNI)

  (2) high-quality C-like execution model, WITHOUT threads, WITHOUT
  intrinsic dynamic code-loading

Compared to these, the type system is almost irrelevant.  There's a
reason, for instance, that Perl (the first popular implementation of
Scheme*) won: a killer FFI, great UNIX syscall support, and bang-up
support for the string datatype.  Java/the JVM ain't got none of this!

[*: and I am NOT kidding about Perl being a popular implementation of
Scheme, albeit with a pretty interesting syntax.]

These are the things that matter in a language.  The fact that CAML
has fancy types, well, -I- like it, but it isn't why I wrote some of
my most complex systems in it, and it will never be enough to push
CAML into the mainstream.

Xavier's (and others') careful attention to building a -system-, and
to making CAML suitable for systems-programming, is infinitely more
compelling, than the type system.

After all, I switched from SML to CAML, not for the type system, but
for the quality of the implementation.  And I wrote Coq V5.10 in CAML,
again, 'cos it was such a high-quality systems language.

--chet--

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

Re: [Caml-list] ocaml killer'

[Matt Gushee]

On Wed, Jan 28, 2004 at 07:34:56PM -0500, Chet Murthy wrote:
> 
> [Maybe this is going off-topic.  Since I'm comparing Java to Caml,
> I'll leave this cc'ed to the Caml list, but if there are further
> responses, it might be good to take 'em offline.]

I can't speak for other list members, but I'm glad to have this on this
list. As someone with much more practical than theoretical knowledge,
I've long known that I liked OCaml and didn't like Java, but haven't
been very sure of the reasons. So for me a rational discussion of
language differences is very educational.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

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

Re: [Caml-list] ocaml killer

[Thomas Fischbacher]

On Wed, 28 Jan 2004, Chet Murthy wrote:

> These are the things that matter in a language.  The fact that CAML
> has fancy types, well, -I- like it, but it isn't why I wrote some of
> my most complex systems in it, and it will never be enough to push
> CAML into the mainstream.

At least, it is nice to be able to use the FFI to define a function 
believe_me: 'a -> 'b which is just the identity, so that one can pass as 
an argument a function to itself. There _are_ some situations where things 
are best handled by using the fixed-point principle at a deep level.

Yes, you may call me a heretic. No, I do not repair fridges with chainsaws.

-- 
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)

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

fancy types (was Re: [Caml-list] ocaml killer)

[William Lovas]

On Thu, Jan 29, 2004 at 09:52:31AM +0100, Thomas Fischbacher wrote:
> On Wed, 28 Jan 2004, Chet Murthy wrote:
> 
> > These are the things that matter in a language.  The fact that CAML
> > has fancy types, well, -I- like it, but it isn't why I wrote some of
> > my most complex systems in it, and it will never be enough to push
> > CAML into the mainstream.
> 
> At least, it is nice to be able to use the FFI to define a function 
> believe_me: 'a -> 'b which is just the identity, so that one can pass as 
> an argument a function to itself. There _are_ some situations where things 
> are best handled by using the fixed-point principle at a deep level.

I've passed functions to themselves before without ever having to make use
of such a function (which already exists in the standard library, it being
mysteriously named Obj.magic and its use being highly discouraged).  In all
of my scenarios, regular old parametric polymorphism was able to handle the
typing.  In what sort of situation have you needed this identity function?

William

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

Re: fancy types (was Re: [Caml-list] ocaml killer)

[james woodyatt]

On 29 Jan 2004, at 08:20, William Lovas wrote:
> [...] (which already exists in the standard library, it being
> mysteriously named Obj.magic and its use being highly discouraged).  
> In all
> of my scenarios, regular old parametric polymorphism was able to 
> handle the
> typing.  In what sort of situation have you needed this identity 
> function?

I needed to use it in two places in the Cf library I recently released.

	1) In Cf_deque, for bootstrapping the data structure.
	2) In Cf_gadget, for unifying continuations in the scheduler.

Its use is highly discouraged for good reason.  You don't want to know 
what it was like trying to get the bugs out of code that used this 
function improperly.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

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

Re: fancy types (was Re: [Caml-list] ocaml killer)

[Benedikt Grundmann]

I'm using it sometimes in connection with lablgtk and camls object system.
In particular the restriction that object fields cannot be initialized with an
expression that uses the value of another field requires me to use Obj.magic.

Cheers,

Bene


On Thursday 29 January 2004 18:13, james woodyatt wrote:
> On 29 Jan 2004, at 08:20, William Lovas wrote:
> > [...] (which already exists in the standard library, it being
> > mysteriously named Obj.magic and its use being highly discouraged).
> > In all
> > of my scenarios, regular old parametric polymorphism was able to
> > handle the
> > typing.  In what sort of situation have you needed this identity
> > function?
>
> I needed to use it in two places in the Cf library I recently released.
>
> 	1) In Cf_deque, for bootstrapping the data structure.
> 	2) In Cf_gadget, for unifying continuations in the scheduler.
>
> Its use is highly discouraged for good reason.  You don't want to know
> what it was like trying to get the bugs out of code that used this
> function improperly.

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

Re: fancy types (was Re: [Caml-list] ocaml killer)

[Thomas Fischbacher]

On Thu, 29 Jan 2004, William Lovas wrote:

> I've passed functions to themselves before without ever having to make use
> of such a function

Look here:

# let fac n = let do_rec specialist n = if n = 0 then 1 else n * specialist specialist (n-1) in do_rec do_rec n;;

Characters 74-84:
  let fac n = let do_rec specialist n = if n = 0 then 1 else n * 
specialist specialist (n-1) in do_rec do_rec n;;
                                                                            
^^^^^^^^^^
This expression has type 'a -> 'b -> 'c but is here used with type 'a

# let fac n = let do_rec specialist n = if n = 0 then 1 else n * (Obj.magic specialist) specialist (n-1) in do_rec do_rec n;;
val fac : int -> int = <fun>

# fac 8;;
- : int = 40320

This is just one stupid example where the type system gets in the way 
while it should not. Yes, here it does not make too much sense, as I 
would use let rec if I wanted to just create a factorial, but it shows 
the general principle: whenever I have a function that handles a "base 
case" and takes a specialist to pass the recursive case on to, which may 
in turn again require a specialist, I cannot give the specialist itself as 
further specialist, "because unification would give infinite type", as 
other functional languages with similar type system (Haskell or SML, say),
like to put it. and there are quite some cases where one would like to 
employ such techniques. (In Common LISP, I use it regularly when working 
with the "screamer" nondeterministic evaluation module: screamer's biggest 
advantage is that it is readily available, but it is conceptually broken 
at many levels. As it in particular cannot code walk a LABELS, I have to 
resort to such techniques for manual resolution of fixed points to make 
recursive nondeterministic functions...)

As one particular consequence, I also cannot easily map some combinators 
to ocaml:

# let l_combinator x y = x (y y);;

Characters 28-29:
  let l_combinator x y = x (y y);;
                              ^
This expression has type 'a -> 'b but is here used with type 'a

But there are more issues... Look here:

# type ('a,'b) mypair = Nil | Cons of 'a * 'b;;
type ('a, 'b) mypair = Nil | Cons of 'a * 'b


Try defining something like this on it:


# let rec my_len x = match x with | Nil -> 0 | (Cons (p,q)) -> 1+my_len q;;

Characters 70-71:
  let rec my_len x = match x with | Nil -> 0 | (Cons (p,q)) -> 1+my_len q;;
                                                                        ^
This expression has type 'a but is here used with type ('b, 'a) mypair


OF COURSE opinions may differ whether this is really a problem or not. 
Certainly, you can implement every algorithm you want in ocaml, but I 
personally feel that a Hindley-Milner like type system restricts my 
freedom too much and occasionally gets in the way when I want to implement
solutions to problems that are most naturally viewed from a lambda 
calculus point of view. On the other hand, I experience the benefits of 
such a type system as limited; it is able to catch a lot of mistakes I 
would not have made anyway. Nah, I'm rather a LISP hacker.

> (which already exists in the standard library, it being
> mysteriously named Obj.magic and its use being highly discouraged).

For good. I bet this feature exists precisely to keep the LISP wizards 
happy who know about and are not afraid of these dark corners, and have 
(maybe out of stubbornness :-) ) a strong desire writing LISP code in 
ocaml. If there were only honest and upright ocaml programmers, such a 
feature certainly wouuld not exist, and hence it is perhaps a good idea to 
strongly discourage its use.

[I still do not have a good overview over the ocaml library and thus did 
not know this function. Thanks for that piece of information.]


BTW: I also strongly assume that internally, ocaml uses type tagging 
anyway, at least for the garbage collector; hence it may be possible to 
use just the engine of ocaml and build a dynamically typed lisp on top of 
it...? Would be terrific...


-- 
regards,               tf@cip.physik.uni-muenchen.de                 (o_
Dr. 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)

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

Re: fancy types (was Re: [Caml-list] ocaml killer)

[Andreas Rossberg]

Thomas Fischbacher wrote:
> 
> Look here:
> 
> # let fac n = let do_rec specialist n = if n = 0 then 1 else n * specialist specialist (n-1) in do_rec do_rec n;;
> 
> Characters 74-84:
>   let fac n = let do_rec specialist n = if n = 0 then 1 else n * 
> specialist specialist (n-1) in do_rec do_rec n;;
>                                                                             
> ^^^^^^^^^^
> This expression has type 'a -> 'b -> 'c but is here used with type 'a
> 
> # let fac n = let do_rec specialist n = if n = 0 then 1 else n * (Obj.magic specialist) specialist (n-1) in do_rec do_rec n;;
> val fac : int -> int = <fun>
> 
> # fac 8;;
> - : int = 40320
> 
> This is just one stupid example where the type system gets in the way 
> while it should not.

This is almost an FAQ. Try "ocaml -rectypes".

Note that there are very good reasons for this being an option, since it 
is almost never practically useful, but can lead to "false negatives" 
(code getting accepted although it is plain nonsense) quite easily.

Also note that you can encode most of these examples without -rectypes, 
using variant types.

>>(which already exists in the standard library, it being
>>mysteriously named Obj.magic and its use being highly discouraged).
> 
> For good. I bet this feature exists precisely to keep the LISP wizards 
> happy who know about and are not afraid of these dark corners, and have 
> (maybe out of stubbornness :-) ) a strong desire writing LISP code in 
> ocaml.

No, it is rather there for hacking C bindings and stuff.

> BTW: I also strongly assume that internally, ocaml uses type tagging 
> anyway, at least for the garbage collector; hence it may be possible to 
> use just the engine of ocaml and build a dynamically typed lisp on top of 
> it...?

No, it uses only 1-bit tags.

	- Andreas

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

"Computer games don't affect kids; I mean if Pac Man affected us
  as kids, we would all be running around in darkened rooms, munching
  magic pills, and listening to repetitive electronic music."
  - Kristian Wilson, Nintendo Inc.

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

Re: fancy types (was Re: [Caml-list] ocaml killer)

[William Lovas]

On Thu, Jan 29, 2004 at 06:41:47PM +0100, Andreas Rossberg wrote:
> Also note that you can encode most of these examples without -rectypes, 
> using variant types.

In case it's nonobvious, have a gander at this:

    # type ('a, 'b) specialist = S of (('a, 'b) specialist -> 'a -> 'b);;
    type ('a, 'b) specialist = S of (('a, 'b) specialist -> 'a -> 'b)
    # let fac n =
        let do_rec (S specialist) n =
          if n = 0 then
            1
          else
            n * specialist (S specialist) n
        in
        do_rec (S do_rec) n;;
    val fac : int -> int = <fun>

It's also instructive to look at the new, improved type of do_rec:

    val do_rec : (int, int) specialist -> int -> int = <fun>

In my experience, type errors have never indicated a lack of flexibility in
the typechecker, but rather a lack of understanding on my own part of the
code i'm trying to write or the problem i'm trying to solve.  And it nearly
always pays off in the end to pause for a moment and attempt to assign
appropriate types to my functions -- then, when i'm finished, i actually
*understand* why the code should work.

This is probably why it so often seems to be the case that in typeful
programming, "once it typechecks, it works!"

cheers,
William

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

Re: fancy types (was Re: [Caml-list] ocaml killer)

[Thomas Fischbacher]

On Thu, 29 Jan 2004, William Lovas wrote:

>     # type ('a, 'b) specialist = S of (('a, 'b) specialist -> 'a -> 'b);;
>     type ('a, 'b) specialist = S of (('a, 'b) specialist -> 'a -> 'b)
>     # let fac n =
>         let do_rec (S specialist) n =
>           if n = 0 then
>             1
>           else
>             n * specialist (S specialist) n
>         in
>         do_rec (S do_rec) n;;
>     val fac : int -> int = <fun>

Hm, correct me if I am wrong, but to me this looks as if you had to 
unnecessarily cons at every recursive call...

-- 
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)

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

Re: fancy types (was Re: [Caml-list] ocaml killer)

[William Lovas]

On Fri, Jan 30, 2004 at 11:36:13AM +0100, Thomas Fischbacher wrote:
> 
> On Thu, 29 Jan 2004, William Lovas wrote:
> 
> >     # type ('a, 'b) specialist = S of (('a, 'b) specialist -> 'a -> 'b);;
> >     type ('a, 'b) specialist = S of (('a, 'b) specialist -> 'a -> 'b)
> >     # let fac n =
> >         let do_rec (S specialist) n =
> >           if n = 0 then
> >             1
> >           else
> >             n * specialist (S specialist) n
> >         in
> >         do_rec (S do_rec) n;;
> >     val fac : int -> int = <fun>
> 
> Hm, correct me if I am wrong, but to me this looks as if you had to 
> unnecessarily cons at every recursive call...

Well, it depends on what you mean by "unnecessarily" and what you mean by
"cons".  First, if by "cons" you mean "call a constructor", then yes, i did
have to cons at every recursive call.  However, if by "cons" you mean
"allocate memory", i can't say for sure by looking at this code -- it says
nothing about the optimizations applied to variant types during compilation
or potential opportunities for structure sharing.  I strongly suspect that
memory need not be allocated, though, in which case the answer is no, i did
not have to allocate memory at every recursive cell.

As far as "unnecessarily" goes, to me the calls are perfectly necessary --
otherwise the code wouldn't make sense -- I think in types first and code
second. :)

So if efficiency is your concern, you've nothing to worry about.  If its
verbosity, then you have a fair argument -- you just have to weigh the
development time benefits against the small amount of extra code you have
to write beyond what LISP would require you to write.  Personally, i think
it's worth it, but that's just an opinion.

cheers,
William

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

Re: fancy types (was Re: [Caml-list] ocaml killer)

[Vasile Rotaru]

William Lovas <wlovas@stwing.upenn.edu> wrote:

> On Fri, Jan 30, 2004 at 11:36:13AM +0100, Thomas Fischbacher wrote:
> > 
> > On Thu, 29 Jan 2004, William Lovas wrote:
> > 
> > >     # type ('a, 'b) specialist = S of (('a, 'b) specialist -> 'a -> 'b);;
[...]
> > 
> > Hm, correct me if I am wrong, but to me this looks as if you had to 
> > unnecessarily cons at every recursive call...
> 
> Well, it depends on what you mean by "unnecessarily" and what you mean by
> "cons".  First, if by "cons" you mean "call a constructor", then yes, i did
> have to cons at every recursive call.  However, if by "cons" you mean
> "allocate memory", i can't say for sure by looking at this code -- it says
> nothing about the optimizations applied to variant types during compilation
> or potential opportunities for structure sharing.  I strongly suspect that
> memory need not be allocated, though, in which case the answer is no, i did
> not have to allocate memory at every recursive cell.
> 

  Just look at this:

rv@helios:~$ cat specialist_typed.ml
type ('a, 'b) specialist = S of (('a, 'b) specialist -> 'a -> 'b)

let fac n =
  let do_rec (S specialist) n =
    if n = 0 then
      1
    else
      n * specialist (S specialist) (n - 1)
  in
  do_rec (S do_rec) n

rv@helios:~$ ocamlc -dlambda specialist_typed.ml
(setglobal Specialist_typed!
  (let
    (fac/61
       (function n/62
         (let
           (do_rec/63
              (function param/68 n/65
                (if (== n/65 0) 1
                  (let (specialist/64 (field 0 param/68))
                    (* n/65
                      (apply specialist/64 (makeblock 0 specialist/64)
                        (- n/65 1)))))))
           (apply do_rec/63 (makeblock 0 do_rec/63) n/62))))
    (makeblock 0 fac/61)))

rv@helios:~$ ocamlc -dlambda specialist_untyped.ml
(setglobal Specialist_untyped!
  (let
    (fac/56
       (function n/57
         (let
           (do_rec/58
              (function specialist/59 n/60
                (if (== n/60 0) 1
                  (* n/60
                    (apply specialist/59 (id specialist/59) (- n/60 1))))))
           (apply do_rec/58 do_rec/58 n/57))))
    (makeblock 0 fac/56)))


The difference between the two versions are in those two calls

    (id specialist/..)               ; obviously a nop
and
    (makeblock 0 specialist/..)      ; ???

Comments about whether (makeblock 0 ..) is a special case which can be
optimized away are welcome.

> 
> cheers,
> William
> 

Regards,
Vasha

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

Re: fancy types (was Re: [Caml-list] ocaml killer)

[Florian Hars]

Vasile Rotaru wrote:
> The difference between the two versions are in those two calls
> 
>     (id specialist/..)               ; obviously a nop
> and
>     (makeblock 0 specialist/..)      ; ???
> 
> Comments about whether (makeblock 0 ..) is a special case which can be
> optimized away are welcome.

Try

let do_rec (S specialist as spec) n =
   if n = 0 then
     1
   else
     n * specialist spec n

instead, and the code becomes a simple spec/..

Isn't it a standard idiom to pass the same cons cell on recursive calls instead 
of rebuilding an otherwise identical copy?

Yours, Florian Hars.

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

Re: fancy types (was Re: [Caml-list] ocaml killer)

[Alex Baretta]

Thomas Fischbacher wrote:
> On Thu, 29 Jan 2004, William Lovas wrote:

> # let fac n = let do_rec specialist n = if n = 0 then 1 else n * specialist specialist (n-1) in do_rec do_rec n;;
> 
> Characters 74-84:
>   let fac n = let do_rec specialist n = if n = 0 then 1 else n * 
> specialist specialist (n-1) in do_rec do_rec n;;
>                                                                             
> ^^^^^^^^^^
> This expression has type 'a -> 'b -> 'c but is here used with type 'a
> 
> # let fac n = let do_rec specialist n = if n = 0 then 1 else n * (Obj.magic specialist) specialist (n-1) in do_rec do_rec n;;
> val fac : int -> int = <fun>
> 
> # fac 8;;
> - : int = 40320

As far as I can see you are asking for no more than recursive types.

[alex@alex graph]$ ocaml -rectypes
         Objective Caml version 3.07+2

# let fac n = let do_rec specialist n = if n = 0 then 1 else n * 
specialist specialist (n-1) in do_rec do_rec n;;
val fac : int -> int = <fun>
# fac 3;;
- : int = 6

This is kind of thread where an RTFL comment might be appropriate.

Alex

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

Re: [Caml-list] ocaml killer

[skaller]

On Thu, 2004-01-29 at 11:11, Martin Berger wrote:
> > A "system" includes an application-server, a GUI, a database, a window

> please allow me to compare Ocaml and Java from the lofty perspective
> of a programming language theorist. both are mixed imperative/functional
> languages (like all others). what are the *essential* differences?
> 
> Ocaml has/Java doesn't have
> 
>    * sum types
>    * pattern matching as destructors for sum types
>    * full function types (not restricted to first-order like java)
>    * second-order types (will be added to java)
> 
> Java has/Ocaml doesn't have
> 
>    * reflection (maybe in ocaml, not sure at the moment)
> 
> there are probably other big differences, for example in the module system,
> but let's ignore those.

Java has 'inheritance is subtyping' which is bogus,
whereas Ocaml uses algebraic subtyping which is
well-principled.

Ocaml also has polymorphic functions, Java does not.
(virtual functins don't really count here ..:-)
I would say this is quite distinct from the typing
of the function's interface (to see this consider
a language like C++ or Felix where values are not boxed).

-- 
John Max Skaller, mailto:skaller@tpg.com.au
snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net




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

Re: [Caml-list] ocaml killer

[Brian Hurt]

On Wed, 28 Jan 2004, Martin Berger wrote:

> > Java/the JVM is not a systems-programming language.  Period.  Oh, and
> > I'll defend that against all comers.  Difference is, though, if you
> > wanna attack, I'll expect real examples, not the academic crap that
> > most programming language theorists throw around.
> 
> i'll have to defend my profession here: which working programming
> language theorist proposes java as a "systems-programming language"?
> most of them are busy researching concurrency or pointer arithmetic
> these days.

Supposedly Sun has an OS written in Java.  I wouldn't touch it with a ten 
foot cattle prod, myself.  I'd rather use Pascal to write an OS (I'd shoot 
myself first in either case, it'd be less painfull).

> 
> but i guess it depends what you mean by that "systems-programming
> language". rather than attempting a definition (it's late here), i'll
> point to C/C++ or Cyclone as examples.

As a day-job systems programmers, throw C++ out of that group.  Systems 
programming (device drivers, OSs, BIOSs, etc- things that beat directly on 
hardware) tends to be either C or assembly.

See previous rant.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

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

Re: [Caml-list] ocaml killer

[Alexander Epifanov]

On 18:26 Wed 28 Jan     , Chet Murthy wrote:

I agree with you on all items.
I've written a lot of java applications. "Java - slow sux" - it's right.
I don't think the JVM is a good solution. I told about scala, which used JVM,
but I don't want to tell "We need to use JVM".

The basic problem in projects in which I took part, was that I could not use
ocaml _only_ to make project complete. I wrote a lot of C/C++ functions to use
ocaml with CORBA or SNMP for example.
> 
> Alexander,
> 
> I don't know what to say, except that clearly, you should spend some
> time in the trenches, working with the COBOL of the 21st Century --
> Java.
> 
> That's what I do for a living.  I've written extremely complex Java
> systems.  I've debugged more Java code than anybody else at my current
> employer, and I'm not kidding.
> 
> And, y'know what?
> 
> Java/the JVM still sux.
> 
> I left CAML in 1994, when it still didn't have a native-code
> compiler.  I started hacking on Java in the spring of 1996.  I've got
> code in (probably) every JVM.  I've debugged dozens of very large, and
> hundreds of only somewhat large Java deployments, some of them in
> situations involving large amounts of business at risk.
> 
> And y'know what?
> 
> Java/the JVM still sux.
> 
> "concurrency"!  You ever tried to use Java threads to do anything
> meaningful?  Check out the J2EE spec.  It basically is BUILT around
> NOT sharing anything between threads.
> 
> Oh, and y'know, we have a joke: "every Java bug is a connection-pool
> (or resource-pool) bug".
> 
> Here's another: "When you arrive onsite,  grep for synchronized, and
> if you see it, put your laptop back in your bag, tell 'em you're going
> to get coffee, and don't come back".
> 
> Java/the JVM is not a systems-programming language.  Period.  Oh, and
> I'll defend that against all comers.  Difference is, though, if you
> wanna attack, I'll expect real examples, not the academic crap that
> most programming language theorists throw around.
> 
> --chet--
> 
> P.S.  I came back to CAML for personal programming in 1999, and after
> that four-year hiatus, during which I became a commercial JVM
> internals guy, as well as a commercial transaction-processing
> firefighter (think "Mr. Wolf" from _Pulp Fiction_).  So I think I have
> the experience to compare, and the verdict seems manifestly
> incontrovertible: Java/the JVM sux.
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

-- 
Gentoo Linux http://www.gentoo.org

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

[Caml-list] ocaml and concurrency

[james woodyatt]

On 28 Jan 2004, at 15:26, Chet Murthy wrote:
>
> [...]
> "concurrency"!  You ever tried to use Java threads to do anything
> meaningful?  Check out the J2EE spec.  It basically is BUILT around
> NOT sharing anything between threads.
>
> Oh, and y'know, we have a joke: "every Java bug is a connection-pool
> (or resource-pool) bug".
>
> Here's another: "When you arrive onsite,  grep for synchronized, and
> if you see it, put your laptop back in your bag, tell 'em you're going
> to get coffee, and don't come back".
> [...]

In my current day job, I get paid to code on an application for the 
VxWorks RTOS, a very multi-threaded environment.  I've been around 
multi-threaded programming environments for a long time now.  Since the 
late 1980's anyway.  That's no joke about 'every bug being a 
resource-pool bug'-- except in C/C++ (as well as Java probably), there 
are also the other two kinds of bug: the 'unprotected critical section 
bug' and the 'mutual exclusion deadlock bug'.

I've almost finished convincing myself that the main problem with the 
Java Runtime Environment (which I don't have much experience with, 
because I saw it as a train wreck waiting to happen back when the world 
was all jazzed to be getting Java 1.0 someday soon, and I avoided it at 
all costs) is that the multi-threaded programming environment itself 
should be considered harmful and wrong and Just Say No, Kids.

But to write concurrent services without threads, you have to use a lot 
of higher-order functions and non-blocking I/O functions.  Hey, guess 
what?  Ocaml is a pretty good language for mixing functional 
programming with imperative programming.  What if the *right* way to 
get concurrency really *is* the ancient Unix dogma of 1) use 
heavyweight process switching and message passing between processes, 
and 2) use monolithic event loops inside lightweight programs?

I'm still working on a demonstration of the concept.  Please mind the 
gap.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] ocaml and concurrency

[Vitaly Lugovsky]

On Thu, 29 Jan 2004, james woodyatt wrote:

>


 You may want to try my mpassing library, which now lacks the
sequental orthodox unixish message queue, but it would be easy to
implement (going to do it soon). I'm using it heavily in a
distributed calculations as well as in a massive agent models and
as a simple way to program "components", and I'm quite happy I
don't ever met in OCaml any of the most common concurrncy bugs
I enjoyed with Java and C++.


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

Re: [Caml-list] ocaml and concurrency

[Martin Berger]

>  You may want to try my mpassing library, which now lacks the
> sequental orthodox unixish message queue, but it would be easy to
> implement (going to do it soon). I'm using it heavily in a
> distributed calculations as well as in a massive agent models and
> as a simple way to program "components", and I'm quite happy I
> don't ever met in OCaml any of the most common concurrncy bugs
> I enjoyed with Java and C++.

i wonder why. ocaml essentially offers the same approaches to
concurrency as do the relevant java or C/C++ libraries.
as far as i can see, there's nothing in Ocaml's approach to shared
memory concurrency that would prevent deadlocks or lack of mutual
exclusion, and there's nothing that prevents the usual problems
with message passing, like lack of liveness. you do have more expressive
types in Ocaml, but that is orthogonal to concurrency.

martin

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

RE: [Caml-list] ocaml and concurrency

[Michael Hicks]

I don't believe the underlying language and the concurrency style are
completely orthogonal.  OCaml encourages a functional style of
programming, in which you use immutable data quite a lot.  Immutable
data does not run the risk of races.  Java, I would claim, encourages
imperative programming.  Most Java programmers I know make changes
through side effects, rather than copying the object and making
adjustments in the new version.  Doing the copy+adjustment in Java, to
make objects immutable, requires a bit more work than just assigning to
a field, since you have to make a copy constructor and call it.  In
OCaml, making something a reference and dereferencing it/assigning to it
is a bit more work than just defining a new variable with let ...

Mike

-----Original Message-----
From: owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of Martin Berger
Sent: Thursday, January 29, 2004 5:38 AM
To: Vitaly Lugovsky
Cc: The Trade
Subject: Re: [Caml-list] ocaml and concurrency

>  You may want to try my mpassing library, which now lacks the
> sequental orthodox unixish message queue, but it would be easy to
> implement (going to do it soon). I'm using it heavily in a
> distributed calculations as well as in a massive agent models and
> as a simple way to program "components", and I'm quite happy I
> don't ever met in OCaml any of the most common concurrncy bugs
> I enjoyed with Java and C++.

i wonder why. ocaml essentially offers the same approaches to
concurrency as do the relevant java or C/C++ libraries.
as far as i can see, there's nothing in Ocaml's approach to shared
memory concurrency that would prevent deadlocks or lack of mutual
exclusion, and there's nothing that prevents the usual problems
with message passing, like lack of liveness. you do have more expressive
types in Ocaml, but that is orthogonal to concurrency.

martin

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

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

Re: [Caml-list] ocaml and concurrency

[Alex Baretta]

Martin Berger wrote:

> i wonder why. ocaml essentially offers the same approaches to
> concurrency as do the relevant java or C/C++ libraries.
> as far as i can see, there's nothing in Ocaml's approach to shared
> memory concurrency that would prevent deadlocks or lack of mutual
> exclusion, and there's nothing that prevents the usual problems
> with message passing, like lack of liveness. you do have more expressive
> types in Ocaml, but that is orthogonal to concurrency.
> 
> martin

You are right. No tool can save you from deadlocks or races in a 
concurrent environment. The properties of being free from deadlocks and 
free from races depend on the characteristics of the distributed 
algorithm implemented by the program, not by the 
multithreading/multiprocessing abstraction facilities in the language. 
Yet, it is immensely better to to write concurrent software in a purely 
functional style with a garbage collected language, while taking 
advantage of a functional message passing library. Ifk you really have 
to dig your own grave, get yourself a Caterpillar.

Alex

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

Re: [Caml-list] ocaml and concurrency

[Martin Berger]

> You are right. No tool can save you from deadlocks or races in a 
> concurrent environment. The properties of being free from deadlocks and 
> free from races depend on the characteristics of the distributed 
> algorithm implemented by the program, not by the 
> multithreading/multiprocessing abstraction facilities in the language. 

i agree and disagree.  what you say is true for conventional languages
like java, C, ocaml ... but it is possible to design typing systems
that will make guarantees about absence of races (see for example
cormac flannagan's work http://www.cse.ucsc.edu/~cormac/) or about
liveness or guaranteed termination (http://www.doc.ic.ac.uk/~yoshida/paper-ic.html#TYPES).
this is of course still quite experimental work, not yet tested
enough for inclusion into mainstream languages, but the time will
come ...

> Yet, it is immensely better to to write concurrent software in a purely 
> functional style with a garbage collected language, while taking 
> advantage of a functional message passing library. 

in many situations, yes. in all, no. and there's nothing in Ocaml
that enforces functional programming. it's down to SW-engineering
practices. that may or may not be enough for your needs.

martin

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

Re: [Caml-list] ocaml and concurrency

[Vitaly Lugovsky]

On Thu, 29 Jan 2004, Martin Berger wrote:

> >  You may want to try my mpassing library, which now lacks the
> > sequental orthodox unixish message queue, but it would be easy to
> > implement (going to do it soon). I'm using it heavily in a
> > distributed calculations as well as in a massive agent models and
> > as a simple way to program "components", and I'm quite happy I
> > don't ever met in OCaml any of the most common concurrncy bugs
> > I enjoyed with Java and C++.
>
> i wonder why. ocaml essentially offers the same approaches to
> concurrency as do the relevant java or C/C++ libraries. as far
> as i can see, there's nothing in Ocaml's approach to shared
> memory concurrency that would prevent deadlocks or lack of
> mutual exclusion,

 Nothing? Did you forget about the possibility to code without
side effects?

> and there's nothing that prevents the usual
> problems with message passing, like lack of liveness. you do
> have more expressive types in Ocaml, but that is orthogonal to
> concurrency.

 Right. But it's much easier to implement a quite stable
environment for message passing, which will remain stable until
you're following some quite simple rules.


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

Re: [Caml-list] ocaml and concurrency

[Martin Berger]

>  Nothing? Did you forget about the possibility to code without
> side effects?

you have this possibility in java too, albeit less conveniently
due to lacking type expressivity. more importantly, however, ocaml
does not enforce side-effect freeness. but in a big project with
multiple and changing developers, what guarantees that no other
developer cuts a corner and introduces some inappropriate side
effects (this can be done in many and subtle ways)?

only SW-engineering discipline. But that is applicable to other
languages, too.

even more importantly, side-effect freeness only prevents (certain)
race conditions. but race conditions are never really a problem
for any experienced programmer (and others should not try and
write concurrent or distributed programs). there is a very simple
rule: every access to a shared variable must be guarded by a lock.
it is trivial. if you do not know what your shared variables
are at any time in your development, you are in the wrong job.

the real problems with concurrent programming are deadlocks, livelock
and things like that. lack of side effects does not help you here at
all.

>  Right. But it's much easier to implement a quite stable
> environment for message passing, which will remain stable until
> you're following some quite simple rules.

i don't see why message passing is easier to implement and use in
ocaml than in, say, C++. and livelock or starvation in your message
queues can happen in either language, too, unless you take precautions.

having said all that, i much prefer writing concurrent or distributed
code in ocaml. i think that's because it is more high level, prevents
lots of stupid mistakes by typing, is more expressive and requires me
to do much less bureaucratic book-keeping. that frees up mind and
screen space for the difficult issues.

martin



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

Re: [Caml-list] ocaml and concurrency

[Andreas Rossberg]

Martin Berger wrote:
> 
>>  Nothing? Did you forget about the possibility to code without
>> side effects?
> 
> you have this possibility in java too, albeit less conveniently
> due to lacking type expressivity.

And even more so due to the lack of real closures, and tail calls. You 
are practically bound to stateful loops and iterators in Java and 
similar languages.

	- Andreas

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

"Computer games don't affect kids; I mean if Pac Man affected us
  as kids, we would all be running around in darkened rooms, munching
  magic pills, and listening to repetitive electronic music."
  - Kristian Wilson, Nintendo Inc.

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

Re: [Caml-list] ocaml and concurrency

[james woodyatt]

On 29 Jan 2004, at 08:56, Andreas Rossberg wrote:
> Martin Berger wrote:
>>>  Nothing? Did you forget about the possibility to code without
>>> side effects?
>> you have this possibility in java too, albeit less conveniently
>> due to lacking type expressivity.
>
> And even more so due to the lack of real closures, and tail calls. You 
> are practically bound to stateful loops and iterators in Java and 
> similar languages.

Not to mention the happy fact that the library of reuseable code in 
Java, widely touted as "extensive and rich," is heavy with side 
effects.  Unless you want to rewrite the world to get rid of side 
effects, you're stuck trying to wrap imperative code in functional 
wrappers-- a trick not easily done without using the continuation 
monad.

I can't even *imagine* what the continuation monad looks like in Java.  
Does anyone have an example?


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

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

Re: [Caml-list] ocaml and concurrency

[Martin Berger]

> And even more so due to the lack of real closures, 

wouldn't you say that the lack of real closures is a consequence
of java's lack of a proper function space arrow, rather than a
separate issue? i don't see how you could have ocaml's full --->
without real closures, but maybe i'm missing something.

martin

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

Re: [Caml-list] ocaml and concurrency

[Andreas Rossberg]

Martin Berger wrote:
> 
> wouldn't you say that the lack of real closures is a consequence
> of java's lack of a proper function space arrow, rather than a
> separate issue? i don't see how you could have ocaml's full --->
> without real closures, but maybe i'm missing something.

In Java, inner classes could give you (a clumsy form of) closures as 
well, but they don't (since they may not capture non-static variables).

	- Andreas

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

"Computer games don't affect kids; I mean if Pac Man affected us
  as kids, we would all be running around in darkened rooms, munching
  magic pills, and listening to repetitive electronic music."
  - Kristian Wilson, Nintendo Inc.

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

Re: [Caml-list] ocaml and concurrency

[Martin Berger]

> In Java, inner classes could give you (a clumsy form of) closures as 
> well, but they don't (since they may not capture non-static variables).

on the subject of inner classes i always wonder if they can be used
to implement existential quantification, because i can pass instantiations
to the environment, but the receiver cannot do anything with them except
(1) using them according to their external spec, (2) discard them or (3)
return them. but when are returned, i can use them according to their full
type. like existentials ...

martin


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

Re: [Caml-list] ocaml and concurrency

[Lauri Alanko]

On Thu, Jan 29, 2004 at 06:54:58PM +0100, Andreas Rossberg wrote:
> Martin Berger wrote:
> >
> >wouldn't you say that the lack of real closures is a consequence
> >of java's lack of a proper function space arrow, rather than a
> >separate issue? i don't see how you could have ocaml's full --->
> >without real closures, but maybe i'm missing something.
> 
> In Java, inner classes could give you (a clumsy form of) closures as 
> well, but they don't (since they may not capture non-static variables).

Yes they can, though only if the variables are declared final (for
obvious reasons). See JLS 8.1.2:

	Any local variable, formal method parameter or exception
	handler parameter used but not declared in an inner class must
	be declared final, [...]


Lauri Alanko
la@iki.fi

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

Re: [Caml-list] ocaml and concurrency

[skaller]

On Fri, 2004-01-30 at 04:43, Martin Berger wrote:
> > And even more so due to the lack of real closures, 
> 
> wouldn't you say that the lack of real closures is a consequence
> of java's lack of a proper function space arrow, rather than a
> separate issue? i don't see how you could have ocaml's full --->
> without real closures, but maybe i'm missing something.

Perhaps because you're a type theorist? <g>
C not only *does* have function types, it has
first class function values just like ML does.

The two differences are: functions can't be 
lexically scoped (so all the closures are trivial)
and there's no garbage collector (so pointers to
automatic variables are unsafe).

-- 
John Max Skaller, mailto:skaller@tpg.com.au
snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net




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

Re: [Caml-list] ocaml and concurrency

[Martin Berger]

> Perhaps because you're a type theorist? <g>

being a type theorist has many disadvantages ...

> C not only *does* have function types, it has
> first class function values just like ML does.

well, i'm not so sure about this for two reasons.

firstly, NULL-pointers (i'm assuming that in C/C++ function
pointers can be NULL, though it's been too long for me to remember
precisely). that means, you have values of function pointer type
that act ... well ... in interesting ways. from that point of
view, function pointers T (*)(A) correspond more to a sum type

    (A --> T) + Error

secondly, there's the "location restriction". maybe it's an
issue of taste, but one might argue that for function really
being first class -- as in lambda calculi, whenever we have
a piece of code C with free variable x_1 of type T_1, ...,
x_n of type T_n, then we can abstract and form
(lambda x_1 ... x_n . C), as we can in ML, but not
in C/Java/C++.

martin


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

Re: [Caml-list] ocaml and concurrency

[Brian Hurt]

On Fri, 30 Jan 2004, Martin Berger wrote:

> > Perhaps because you're a type theorist? <g>
> 
> being a type theorist has many disadvantages ...
> 
> > C not only *does* have function types, it has
> > first class function values just like ML does.
> 
> well, i'm not so sure about this for two reasons.

Technically, he's correct.  What C doesn't have is partial function 
application, which makes having functional types much less worthwhile- 
it's impossible for a function type to also contain state.  Which is why 
when I do callbacks in C, I always include a void * context which is 
passed (uninspected) to the callback routine.

I mean, writting this function in C would be interesting to say the least:

let summer ival =
    let cval = ref ival in
    let f x = cval := !cval + x; !cval in
    f
;;

C's type syntax also discourages you from using pointers to functions.  
I've been programming C way too long, I can just dash out prototypes like:

extern int (*)(int (*)(int), int) foo(int (*)(int (*)(int), int), int);

I can parse them too, although normally I *would* use typedefs.  The ocaml 
equivelent type:
((int -> int) -> int -> int) -> int -> ((int -> int) -> int -> int)
is easier to read and easier to type and parse.

> 
> firstly, NULL-pointers (i'm assuming that in C/C++ function
> pointers can be NULL, though it's been too long for me to remember
> precisely). 

They can.  You can even cast integer values to be function pointers- and I 
have, legitimately (hint: BIOS functions).  I've also debugged bugs where 
wild pointers where clobbering function pointers, and boy wasn't that fun.  

I'm not sure I'd compare NULL to variant types.  It's more like a 
standardized abuse of C's concept of a pointer.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

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

Re: [Caml-list] ocaml and concurrency

[Issac Trotts]

On Fri, Jan 30, 2004 at 12:52:42AM -0600, Brian Hurt wrote:
[snip]
> 
> Technically, he's correct.  What C doesn't have is partial function 
> application, which makes having functional types much less worthwhile- 
> it's impossible for a function type to also contain state.  Which is why 
> when I do callbacks in C, I always include a void * context which is 
> passed (uninspected) to the callback routine.
> 
> I mean, writting this function in C would be interesting to say the least:
> 
> let summer ival =
>     let cval = ref ival in
>     let f x = cval := !cval + x; !cval in
>     f
> ;;

OK, maybe C doesn't support it, but it's easy to do this one in C++:

#include <assert.h>

class summer
{
  int cval;
public:
  summer(int ival): cval(ival) {} 
  int operator()(int x) { cval += x; return cval; }
};

int main()
{
  summer s(3);
  assert(s(2)==5);
  assert(s(7)==12);
  return 0;
}

Issac

[snip]

-- 
Issac Trotts
http://redwood.ucdavis.edu/~issac

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

Re: [Caml-list] ocaml and concurrency

[skaller]

On Fri, 2004-01-30 at 17:52, Brian Hurt wrote:
> On Fri, 30 Jan 2004, Martin Berger wrote:
> 
> > > Perhaps because you're a type theorist? <g>
> > 
> > being a type theorist has many disadvantages ...
> > 
> > > C not only *does* have function types, it has
> > > first class function values just like ML does.
> > 
> > well, i'm not so sure about this for two reasons.
> 
> Technically, he's correct.  What C doesn't have is partial function 
> application, 

If by that you mean currying .. well, of course C has that.
If a function returns a function which returns a function
you can curry exactly like in ML :-)

> which makes having functional types much less worthwhile- 
> it's impossible for a function type to also contain state.  

Almost, but not quite true:

	int f(int x) {
		static int y = x;
		y = y + x;
		return x;
	}

clearly does contain state.. the function isn't
re-entrant though (which means merely not
thread safe here since it manifestly isn't recursive).

However it is true in Haskell and any purely
functional Ocaml code .. they really cannot contain
any state :-)

Indeed, one can go further and say that ML functions
are a lie: if you consider:

	let f x = 
		let g y = y + x in g
	in 
		let g1 = f 1
		and g2 = f 2

then the two g's are distinction functions, they're
NOT the 'g' defined in f, which in fact is NOT
a function at all, merely an abstraction (of course
g1 and g2 are functions .. :)


-- 
John Max Skaller, mailto:skaller@tpg.com.au
snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net




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

Re: [Caml-list] ocaml and concurrency

[Brian Hurt]

On 31 Jan 2004, skaller wrote:

> On Fri, 2004-01-30 at 17:52, Brian Hurt wrote:
> > On Fri, 30 Jan 2004, Martin Berger wrote:
> > 
> > > > Perhaps because you're a type theorist? <g>
> > > 
> > > being a type theorist has many disadvantages ...
> > > 
> > > > C not only *does* have function types, it has
> > > > first class function values just like ML does.
> > > 
> > > well, i'm not so sure about this for two reasons.
> > 
> > Technically, he's correct.  What C doesn't have is partial function 
> > application, 
> 
> If by that you mean currying .. well, of course C has that.
> If a function returns a function which returns a function
> you can curry exactly like in ML :-)

Yuck.  Yes, I suppose you could do that- but I say again, yuck.  A simple 
function, which in Ocaml would have the type int -> int -> int ->int, 
would have the C prototype:
((int (*)(int)) (*)(int)) foo(int);

Something reasonably, but not unheard of, complicated, like say:
('a -> 'b -> 'c) -> 'a array -> 'b array -> 'c array
would be (ignoring the type safety issue):

(((void **) (*)(void **))(*)(void **))foo(void * (*)(void *) (*)(void *));

That's like something out of a submission to the IOCCC.  Not that the 
uncurried version is that much better:

void ** foo(void * (*)(void *, void *), void **, void **);


> 
> > which makes having functional types much less worthwhile- 
> > it's impossible for a function type to also contain state.  
> 
> Almost, but not quite true:
> 
> 	int f(int x) {
> 		static int y = x;
> 		y = y + x;
> 		return x;
> 	}
> 
> clearly does contain state.. the function isn't
> re-entrant though (which means merely not
> thread safe here since it manifestly isn't recursive).

It's not only not re-entrant, it doesn't do what my example does.  Here, I
can have only one sum ever.  My example allows to me have multiple
different sums simultaneously- and adding to one doesn't add to the
others.  The C++ example kicking around that uses objects is more correct.  
Which is one way to do it in C- fake objects, and then used the faked
objects to fake partial application.

> 
> However it is true in Haskell and any purely
> functional Ocaml code .. they really cannot contain
> any state :-)

No, even then they can contain state, they just can't change it.  But it 
can be different from one partial application to another.

A purely functional example:

let logb base x = (log x)/.(log base);;

let log10 = logb 10.;;

let log2 = logb 2.;;

let logn = logb (exp 1.);;

Here I have three different functions- but all of them contain functional 
state- the base of logarithms I'm working in.

> 
> Indeed, one can go further and say that ML functions
> are a lie: if you consider:
> 
> 	let f x = 
> 		let g y = y + x in g
> 	in 
> 		let g1 = f 1
> 		and g2 = f 2
> 
> then the two g's are distinction functions, they're
> NOT the 'g' defined in f, which in fact is NOT
> a function at all, merely an abstraction (of course
> g1 and g2 are functions .. :)

f has a type int -> int -> int here, so f 1 has the type int -> int.  
Looks like a function to me.  The question is: what is a function?

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

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

Re: [Caml-list] ocaml and concurrency

[skaller]

On Fri, 2004-01-30 at 11:05, Martin Berger wrote:
> > Perhaps because you're a type theorist? <g>
> 
> being a type theorist has many disadvantages ...
> 
> > C not only *does* have function types, it has
> > first class function values just like ML does.
> 
> well, i'm not so sure about this for two reasons.
> 
> firstly, NULL-pointers 
> 
>     (A --> T) + Error

Agree. I glossed over that :-)

> secondly, there's the "location restriction". maybe it's an
> issue of taste, but one might argue that for function really
> being first class -- as in lambda calculi, whenever we have
> a piece of code C with free variable x_1 of type T_1, ...,
> x_n of type T_n, then we can abstract and form
> (lambda x_1 ... x_n . C), as we can in ML, but not
> in C/Java/C++.

Neither ML nor C is lambda calculus: they use distinct syntax.
ML is closer of course, but in C you can always abstract a piece
of code even if it means passing all the variables in the 
environment one at a time.

-- 
John Max Skaller, mailto:skaller@tpg.com.au
snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net




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

Re: [Caml-list] ocaml and concurrency

[skaller]

On Thu, 2004-01-29 at 21:37, Martin Berger wrote:

> and I'm quite happy I
> > don't ever met in OCaml any of the most common concurrncy bugs
> > I enjoyed with Java and C++.
> 
> i wonder why. ocaml essentially offers the same approaches to
> concurrency as do the relevant java or C/C++ libraries.

Ocaml relieves you of distractions and allows you
to concentrate on the design ..

Don't underestimate how bad C is. EG: g++ compiler
uses a linked list for lookup ... I mean you can't write:

let h = Hashtbl.create 97 in
Hashtbl.add h symbol valu

in C can you ...

-- 
John Max Skaller, mailto:skaller@tpg.com.au
snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net




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

Re: [Caml-list] ocaml and concurrency

[Alex Baretta]

james woodyatt wrote:
> On 28 Jan 2004, at 15:26, Chet Murthy wrote:
 >
> I've almost finished convincing myself that <snip/>
 > the multi-threaded programming environment itself
> should be considered harmful and wrong and Just Say No, Kids.
> 
> But to write concurrent services without threads, you have to use a lot 
> of higher-order functions and non-blocking I/O functions.  Hey, guess 
> what?  Ocaml is a pretty good language for mixing functional programming 
> with imperative programming.  What if the *right* way to get concurrency 
> really *is* the ancient Unix dogma of 1) use heavyweight process 
> switching and message passing between processes, and 2) use monolithic 
> event loops inside lightweight programs?
> 
> I'm still working on a demonstration of the concept.  Please mind the gap.

Of course you are free to use the lower level abstractions if you like 
them better, but it gives you no more safety than threads. It's like 
flying your own jet plane because you are suspicious of pilots. Well, 
are you not a pilot if you fly your own plane? And are not 
reimplementing a (limited) multithreading model when you use Unix.select 
to choose a descriptor ready for IO?

Concurrency is neither good nor bad: it's just a part of modern 
interactive information systems. You've got to cope with it. It takes 
competence and adequate tools. I beleive that the message passing model 
implemented in the threads library's Event module is great abstraction 
with which to cope with the intricacies of concurrency. If this library 
had support for marshalling events through channels with an underlying 
file descriptor, Event would give me all the facilities I need for 
concurrency and distributed parallel processing.

Yet the neither the solution nor the problem are ever in the tool, but 
in the tool's user. You can implement distributed concurrent 
applications with Unix.select. Or, if you cannot trust the real-tiime 
capabilities of your Unix kernel, you can always code your own 
kernel--this is what a number of companies actually do (i.e. Cisco, with 
its proprietary OS) but whether their systems are more or less 
trustworthy than a Linux or BSD box is doubtful.

Alex

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

Re: [Caml-list] ocaml and concurrency

[skaller]

On Thu, 2004-01-29 at 19:53, james woodyatt wrote:
> On 28 Jan 2004, at 15:26, Chet Murthy wrote:

> But to write concurrent services without threads, you have to use a lot 
> of higher-order functions and non-blocking I/O functions.  Hey, guess 
> what?  Ocaml is a pretty good language for mixing functional 
> programming with imperative programming.  What if the *right* way to 
> get concurrency really *is* the ancient Unix dogma of 1) use 
> heavyweight process switching and message passing between processes, 
> and 2) use monolithic event loops inside lightweight programs?

See Felix. 

A large amount of 'need' for concurrency is
actually a need for control inversion. Event driven
programs are efficient  but almost impossible to structure
correctly: this is because a lot of state in block structured
code is maintained on the stack and identified by the current
value of the program counter: when you're programming directly
with an event loop, you have to maintain all that state manually.

In Felix, the programmer writes 'threads' and calls the 'read'
primitive to get the next message. This is no different
to calling C's 'read' function to read from a file, except
the context switching is done in user space. 

The architecture would usually be several threads or
processes to load the message queue, and a a small number
of independent worker threads (typically one per CPU)
to deliver the messages to the client threads synchronously.
[The worker threads are event loops ..]

I personally believe this architecture is useful in a 
wide class of applications, for example almost all
kinds of servers. However, asynchronous (pre-emptive)
context switching with shared data is certainly 
needed in many situations where neither cooperative
multi-tasking nor processes are suitable..

.. for example even in the above architecture, threads are
useful for loading the central message queue,
even if all they're doing is synchronising with
the processes actually procuring the messages.

-- 
John Max Skaller, mailto:skaller@tpg.com.au
snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net




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