Looking for a nail

Looking for a nail

[Miles Egan]

I've been working with OCaml on my own for the past two weeks or so and
think I'm finally ready to take on a real project.  I feel like I've just come
upon a beautiful new hammer and I want to find some nails to hit with it.

I'd like to work on something that might help raise OCaml's visibility among
the Linux hacker community.  A few projects have occurred to me already:

1.  Extend OCaml's Unix library.  What's already there is very useful, but
there are quite a few functions missing.  I'd be happy to help fill this out,
although I'm new enough to OCaml and functional programming that I'm still not
sure if some Unix functions were omitted because of their stateful semantics.

2.  Build a GTK+ wrapper.  I know there was some discussion of this earlier. 
Is anyone still working on this?  I think a robust, comprehensive GTK+
interface would make OCaml a stronger candidate for a lot of burgeoning
open-source projects.  Again, I'm new enough to this that I'm still not sure if
languages like OCaml are a good fit for GUI work, but it seems to me that
OCaml's mix of imperative and functional features should provide enough
flexibility for something like this.

3.  Rewrite some of the GNU build tools, autoconf, automake etc. in OCaml.  It
seems to me that OCaml would be a marvelous language for building these kinds
of tools; their current m4 / perl implementation seems inelegant to me.  On the
other hand, the FSF seems to favor scheme, so they may not be receptive to
OCaml implementations ( I haven't asked ).

I'd appreciate any criticisms of these projects or any suggestions for others. 
My goal is to do my small part to promote OCaml ( while having fun hacking
with it ) and to try to show the open-source community what a boon a tool like
OCaml can be.  With a bit of luck, maybe one day I can earn a living writing
OCaml instead of C++. :)

--
miles

Re: Looking for a nail

[Lyn A Headley]

>>>>> "Miles" == Miles Egan <cullenx@earthlink.net> writes:


    Miles> I've been working with OCaml on my own for the past two
    Miles> weeks or so and think I'm finally ready to take on a real
    Miles> project.  I feel like I've just come upon a beautiful new
    Miles> hammer and I want to find some nails to hit with it.

Ocaml could really use some nice database interfaces.  Any of
Postgresql, Mysql, or the free sybase or oracle bindings would go a
long way toward making ocaml attractive for free software hackers.  I
would also consider a web server and/or some HTML generation
utilities.

-Lyn

Re: Looking for a nail

[Jean-Christophe Filliatre]

> Ocaml could really use some nice database interfaces.  Any of
> Postgresql, Mysql, or the free sybase or oracle bindings would go a
> long way toward making ocaml attractive for free software hackers.  I
> would also consider a web server and/or some HTML generation
> utilities.

Regarding web tools, Daniel de Rauglaudre and I freely distribute a
(very) small library to write CGI in ocaml. It is available here :

      http://www.lri.fr/~filliatr/ftp/ocaml/cgi/

-- 
Jean-Christophe FILLIATRE
  mailto:Jean-Christophe.Filliatre@lri.fr
  http://www.lri.fr/~filliatr

Re: Looking for a nail

[Markus Mottl]

> > Ocaml could really use some nice database interfaces.  Any of
> > Postgresql, Mysql, or the free sybase or oracle bindings would go a
> > long way toward making ocaml attractive for free software hackers.  I
> > would also consider a web server and/or some HTML generation
> > utilities.
> 
> Regarding web tools, Daniel de Rauglaudre and I freely distribute a
> (very) small library to write CGI in ocaml. It is available here :
> 
>       http://www.lri.fr/~filliatr/ftp/ocaml/cgi/

Ah, apropos web server: Daniel de Rauglaudre has already written a small
but beautiful version of a basic web server. Get it from:

  ftp://ftp.inria.fr/INRIA/Projects/cristal/Daniel.de_Rauglaudre/Tools/

Regards,
Markus

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: Looking for a nail

[mattwb]

>
>Lyn A Headley <laheadle@cs.uchicago.edu> writes:
>
>>>>>> "Miles" == Miles Egan <cullenx@earthlink.net> writes:
>
>
>    Miles> I've been working with OCaml on my own for the past two
>    Miles> weeks or so and think I'm finally ready to take on a real
>    Miles> project.  I feel like I've just come upon a beautiful new
>    Miles> hammer and I want to find some nails to hit with it.
>
>Ocaml could really use some nice database interfaces.  Any of
>Postgresql, Mysql, or the free sybase or oracle bindings would go a
>long way toward making ocaml attractive for free software hackers.  I
>would also consider a web server and/or some HTML generation
>utilities.
>
>-Lyn
>

I have written postgresql bindings as well as ODBC bindings that
work with MySQL's iODBC (and any other ODBC database) if anyone's 
interested.  They need some work, but it's a start.

Re: Looking for a nail

[Trevor Jim]

And I've written LDAP bindings if anyone's interested.

-Trevor


>>Ocaml could really use some nice database interfaces.  Any of
>>Postgresql, Mysql, or the free sybase or oracle bindings would go a
>>long way toward making ocaml attractive for free software hackers.  I
>>
>
>I have written postgresql bindings as well as ODBC bindings that
>work with MySQL's iODBC (and any other ODBC database) if anyone's 
>interested.  They need some work, but it's a start.

Re: Looking for a nail

[Gerd Stolpmann]

On Mon, 25 Jan 1999, Lyn A Headley wrote:

>Ocaml could really use some nice database interfaces.  Any of
>Postgresql, Mysql, or the free sybase or oracle bindings would go a
>long way toward making ocaml attractive for free software hackers.  I
>would also consider a web server and/or some HTML generation
>utilities.

I am currently working on a db interface that connects to Adabas D,
and plan to write another driver for Informix. If somebody else is
interested in that we could share code; most commercial DBMS follow
the ANSI standard for embedded SQL and because of that it should be very 
simple to derive drivers for other DBMS. As far as I know, the free
DBMS have their own specific interfaces; drivers would have to be totally
rewritten.

What would be really nice if Miles is interested in that are tools for
server-side "scripting", as alternative for Perl and Python. This could
mean a good CGI parser, a configurable XML-to-HTML converter, HTTP and
FTP tools, and a killer app showing everybody what's going on.

Another interesting project would be a Corba interface, as Gnome and KDE
want to use Corba. Then Ocaml would be one of the most elegant ways to
write desktop applications.


Gerd
--
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   Gerd.Stolpmann@darmstadt.netsurf.de (privat)
Germany                     
----------------------------------------------------------------------------

Re: Looking for a nail

[Michel Schinz]

Miles Egan <cullenx@earthlink.net> writes:

[...]
> 1. Extend OCaml's Unix library. What's already there is very useful,
> but there are quite a few functions missing. I'd be happy to help
> fill this out, although I'm new enough to OCaml and functional
> programming that I'm still not sure if some Unix functions were
> omitted because of their stateful semantics.

I think it would be nice if you took a look at scsh for that part.
Scsh is a Scheme interpreter with a complete Posix interface. The
design of scsh is really great IMHO and you could take many ideas from
it (mostly because Scheme is also a functional language, and the
design of scsh is also quite functional). However, porting the
complete scsh design to CAML is not trivial, since CAML (at least
Objective CAML) doesn't have a macro system, and Scheme's macros are
heavily used in scsh.

Anyway, the scsh page is at http://www-swiss.ai.mit.edu/scsh/

[...]
> I'd appreciate any criticisms of these projects or any suggestions
> for others.

Here is a "big" suggestion: what I'd really like to see for OCaml is a
good and consistent data structure library. The one shipped with OCaml
is quite good, but there are some things I do not like about it:

- some parts are "imperative" (Array, Hashtbl, ...), while others are
  "functional" (Set, Map, ...),

- the interface of some of the modules are not as complete as one
  might wish (in almost all of my projects, I end up writing some
  basic functions, like list partitioning, ...),

- the interface of the different modules is not always consistent
  (e.g. in the Map module, the map is always given as the last
  parameter, while in the Hashtbl module, the table is given as the
  first argument, and that is confusing sometimes [and sometimes it
  also prevents the use of partial application]),

- none of the modules use the OO features of OCaml.

So, what I would really like to do (if only I had time) is:

1. take a good look at many good standard libraries of many languages,
   functional or not, object-oriented or not (e.g. Haskell, MIT
   Scheme, Common Lisp, C++'s STL, Eiffel, Okasaki's book, ...) and
   identify the most important data structures and the important
   operations that can be performed on them,

2. design two different versions of the library: one purely
   applicative, and the other one with in-place modification (note
   that these two versions could be different, because some data
   structures might not be efficient or interesting enough in the two
   versions; however, it would be great if the two designs were as
   similar as possible),

3. implement these two versions of the library,

4. document them thoroughly (e.g., give the complexity of every
   function, ...).

I'm still unclear about the OO features of OCaml, so I do not know
whether they should be used or not for these libraries.

Designing a good library is usually really hard, but I think that it's
a crucial point. C++ for example has almost become usable now that the
STL exists. And one of the main reasons why Common Lisp is usually
preferred to Scheme for big applications is that the former has a good
standard library (which is in fact part of the language itself) while
the latter has none (yet).

Michel.

Re: Looking for a nail

[Markus Mottl]

> Here is a "big" suggestion: what I'd really like to see for OCaml is a
> good and consistent data structure library. The one shipped with OCaml
> is quite good, but there are some things I do not like about it:
> 
> - some parts are "imperative" (Array, Hashtbl, ...), while others are
>   "functional" (Set, Map, ...),

It would be nice if someone would extend Okasaki's implementation of
purely functional data structures. There are some really very efficient
implementations to be found there. Unfortunately, they are by far not
complete: the ADTs offer but the most basic functionality. So please
take a look at

  http://miss.wu-wien.ac.at/~mottl/ocaml_sources

and extend some of the modules of the port from SML to OCAML. If you
have something to contribute, just send it to me and I will put it on
my page. A very fine implementation of random access lists by Pierpaolo
Bernardi is already available...
In the meanwhile I will continue porting the last four chapters.

> - the interface of some of the modules are not as complete as one
>   might wish (in almost all of my projects, I end up writing some
>   basic functions, like list partitioning, ...),

I could also imagine some more functions that would be useful, e.g. with
sets (and maybe a small change in the implementation). I'll write a
separate mail on this...

> - none of the modules use the OO features of OCaml.

There is even a much more radical approach concerning OO:
Make all basic types classes! This would e.g. allow to put all kinds of
values into a list and iterate it with a print function - just one of
many other then possible things I miss...

I think this change could be done without breaking existing code. All
(most) standard functions on basic types would have to be changed. E.g.:

"print_string" could be something like:

  let print_string x = x # print_string

But preferably we would use functions like:

  let print x = x # print

and "x" could be any object having a "print" function. This would even
allow user-defined classes to be mixed with basic types in "general"
manipulation functions - as long as they have the appropriate interface...

I think that this proposition could greatly reduce the amount of low-level
tinkering with basic types.

Maybe we could try to test this with CAMLP4 - I think it wouldn't
be this difficult to transform sources with it in such a way that
expressions like:

  let x = 3

become

  let x = new int 3

where "int" is actually the class "int" (different name spaces!)

> 2. design two different versions of the library: one purely
>    applicative, and the other one with in-place modification (note
>    that these two versions could be different, because some data
>    structures might not be efficient or interesting enough in the two
>    versions; however, it would be great if the two designs were as
>    similar as possible),

As Okasaki shows, most kinds of data structures can be implemented
in a very efficient and still purely applicative way. I am not sure
whether there are many data structures that deserve their existence in
both forms...

> 4. document them thoroughly (e.g., give the complexity of every
>    function, ...).

Probably the biggest problem ;-)
Many people (including me) don't like writing documentation...

Best regards,
Markus

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: Looking for a nail

[Michel Schinz]

Markus Mottl <mottl@miss.wu-wien.ac.at> writes:

[...]
> There is even a much more radical approach concerning OO: Make all
> basic types classes! This would e.g. allow to put all kinds of
> values into a list and iterate it with a print function - just one
> of many other then possible things I miss...

I'm not sure this is such a good idea for CAML. The non-OO part of
CAML is quite mature, while the OO part is more like research. Forcing
everybody to use CAML as an OO language is IMHO not a very nice thing.
I do not use the OO part of CAML at all right now, and I'm pretty sure
I'm not the only one. I think we need more experience with the OO part
of CAML (or, more fundamentally with OO programming in a functional
language) before choosing to use it for basic types.

Don't get me wrong, I have nothing against purely-OO languages. I
*love* Self, Smalltalk, ... I just think that it's not appropriate for
CAML at this time. Later, when we have more experience, maybe, but not
now.

[...]
> As Okasaki shows, most kinds of data structures can be implemented
> in a very efficient and still purely applicative way. I am not sure
> whether there are many data structures that deserve their existence
> in both forms...

I think that having arrays with in-place modification is almost a
must, for example. For some applications, having only functional
arrays is pretty awful.

I agree with you that for some data-structures, having a
non-functional version when the functional one is efficient is maybe
not such a good idea.

Michel.

Re: Looking for a nail

[Markus Mottl]

> Markus Mottl <mottl@miss.wu-wien.ac.at> writes:
> 
> [...]
> > There is even a much more radical approach concerning OO: Make all
> > basic types classes! This would e.g. allow to put all kinds of
> > values into a list and iterate it with a print function - just one
> > of many other then possible things I miss...
> 
> I'm not sure this is such a good idea for CAML. The non-OO part of
> CAML is quite mature, while the OO part is more like research. Forcing
> everybody to use CAML as an OO language is IMHO not a very nice thing.
> I do not use the OO part of CAML at all right now, and I'm pretty sure
> I'm not the only one. I think we need more experience with the OO part
> of CAML (or, more fundamentally with OO programming in a functional
> language) before choosing to use it for basic types.
> 
> Don't get me wrong, I have nothing against purely-OO languages. I
> *love* Self, Smalltalk, ... I just think that it's not appropriate for
> CAML at this time. Later, when we have more experience, maybe, but not
> now.

I didn't say that one should be forced to use objects (I sometimes prefer
modules - or even have to take them).

But I think it would be possible to let people use all basic types
as if they were classes without breaking code of other people.  Thus,
if someone doesn't like objects - he needs not necessarily use them.

I wonder whether this is a big task for camlp4 - translating every
appearance of a basic type in the source to an appropriate construction
of an object and all standard functions to appropriate method calls.
I am not so experienced in camlp4, but I believe it could work.

So there is no need to change the compiler - especially, since the
OO-system is still under development. Changing just the preprocessor
(the rules) is certainly not so much work.

> [...]
> > As Okasaki shows, most kinds of data structures can be implemented
> > in a very efficient and still purely applicative way. I am not sure
> > whether there are many data structures that deserve their existence
> > in both forms...
> 
> I think that having arrays with in-place modification is almost a
> must, for example. For some applications, having only functional
> arrays is pretty awful.

Although there are more or less efficient implementations of functional
arrays, I would not want to trade them against "real" arrays (not yet).

As I wrote above (probably just a misunderstanding):

  I am not sure whether there are many data structures that deserve
  their existence in *both forms*...

I don't want to have everything functional nor everything imperative
(of course), but I definitely don't want to have both versions if they
otherwise behave exactly the same (time/memory complexity, comparable
performance). I think this would lead to a lot of confusion (which one
to choose now?).

> I agree with you that for some data-structures, having a
> non-functional version when the functional one is efficient is maybe
> not such a good idea.

Exactly my opinion.

Best regards,
Markus

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: Looking for a nail

[Hendrik Tews]

Hi,

   Miles> hammer and I want to find some nails to hit with it.
   
1. Bringing ocamletags to live again. I keep a copy, which
compiles under 2.01 and reads 2.01 files, but does not create
much tags for classes. I am willing to through this into the
pool (if Francois Rouaix agrees).

2. The yacc and lex interface of ocaml could be a tuned up. Some
ideas:

- use a oo interface for lexers and parsers, this would provide a
much butter way of adding state information to lexers and parsers
[cf Christian Lindig's mail "Proposal for new Lexing Module
(long)" from Mon, 18 Jan 1999] 
by simply inheriting from the library classes.

- adding start conditions a la flex to ocamllex

- adding a tool for generating perfect hash functions for keyword
recognition a la gperf; It would be great, if the hash function
generator could read the set of keywords from annotations in the
.mly file. I have a rather primitive version, which could be used
as a starting point.

Bye,

Hendrik

Re: Looking for a nail

[Ian T Zimmerman]

> Date: Mon, 25 Jan 1999 21:53:53 +0100
> From: Hendrik Tews <tews@irritatie.cs.kun.nl>
> X-Gnus-Article-Number: 99   Tue Jan 26 11:02:09 1999
> 
> 1. Bringing ocamletags to live again. I keep a copy, which compiles
> under 2.01 and reads 2.01 files, but does not create much tags for
> classes. I am willing to through this into the pool (if Francois
> Rouaix agrees).

An etags generator (written in Elisp) is part of current snapshot of
the Emacs subdirectory.  It is exactly as precise/correct as the imenu
generator :-) If you want to see it and can't wait for next release,
write me.

>  2. The yacc and lex interface of ocaml could be a tuned up. Some
> ideas:

>  - use a oo interface for lexers and parsers, this would provide a
> much butter way of adding state information to lexers and parsers
> [cf Christian Lindig's mail "Proposal for new Lexing Module (long)"
> from Mon, 18 Jan 1999] by simply inheriting from the library
> classes.

No.  Sorry, but I don't want to be forced to use classes.  I want to
be able to use Ocaml as a "better ML" only.  This also applies to
Markus' proposal about the standard library.


>  - adding start conditions a la flex to ocamllex

I haven't thought of this really hard, but I bet there is already a
way to do that.  If there isn't, I would think hard again to find a
cleaner, more functional (less stateful) way to do it.  If the current
condition is kept in a global as in flex, that just drops again the
reentrancy that Christian has been working so hard to achieve.

>  - adding a tool for generating perfect hash functions for keyword
> recognition a la gperf; It would be great, if the hash function
> generator could read the set of keywords from annotations in the
> .mly file. I have a rather primitive version, which could be used as
> a starting point.

Yes, I like this one.

-- 
Ian T Zimmerman                        <itz@transbay.net>
I came to the conclusion that what was wrong about the guillotine
was that the condemned man had no chance at all, absolutely none.
Albert Camus, _The Outsider_

Re: Looking for a nail

[John Prevost]

Accidentally sent this as a personal reply.  Here it is to the list.

Ian T Zimmerman <itz@transbay.net> writes:

> >  - adding start conditions a la flex to ocamllex
> 
> I haven't thought of this really hard, but I bet there is already a
> way to do that.  If there isn't, I would think hard again to find a
> cleaner, more functional (less stateful) way to do it.  If the current
> condition is kept in a global as in flex, that just drops again the
> reentrancy that Christian has been working so hard to achieve.

The current condition already exists in ocamllex--this is what the
rule name is equivalent to.  The one thing it doesn't do is support
the idea that some regexp -> action specs should be in more than one
rule--which is no real great loss.

I think making the languages of ocamllex and ocamlyacc slightly nicer
wouldn't be entirely out of order, as would writing them in Caml
rather than C.

John.

Re: Looking for a nail

[Hendrik Tews]

Hi,

   From: Ian T Zimmerman <itz@transbay.net>
   Date: Tue, 26 Jan 1999 11:20:47 -0800
   Subject: Re: Looking for a nail
   
    [concerning an oo interface to ocamllex]
   
   No.  Sorry, but I don't want to be forced to use classes.  I want to

Hold on! This was only a suggestion to somebody looking for a
nail! I agree that the possibility of choosing between (or even
mixing) the functional and the oo paradigm is one of the great
advantages of ocaml. Therefore there should always be a
functional version of the standard libray. But, by the same
argument it would be nice, to have an oo version.

   >  - adding start conditions a la flex to ocamllex
   
   I haven't thought of this really hard, but I bet there is already a
   way to do that.  If there isn't, I would think hard again to find a
   cleaner, more functional (less stateful) way to do it.  If the current
   condition is kept in a global as in flex, that just drops again the
   reentrancy that Christian has been working so hard to achieve.

Yes, indeed, you can do the following:

	{
	   type lexer_state_type = A | B
	   let lexer_state = ref A
	}

	rule token = parse
	   ""                           { match !lexer_state with
					    A -> atoken lexbuf
					  | B -> btoken lexbuf
					}

	and atoken = parse ...

But it would be nice to have an intuitive syntax for that.

Bye,

Hendrik

Re: Looking for a nail

[Jacques GARRIGUE]

From: Hendrik Tews <tews@irritatie.cs.kun.nl>

>    Miles> hammer and I want to find some nails to hit with it.
>    
> 1. Bringing ocamletags to live again. I keep a copy, which
> compiles under 2.01 and reads 2.01 files, but does not create
> much tags for classes. I am willing to through this into the
> pool (if Francois Rouaix agrees).

I have put a snapshot of the caml-mode at

ftp://ftp.kurims.kyoto-u.ac.jp/pub/lang/olabl/ocaml-mode-990127.tar.gz

Along with some improvements to the emacs mode itself, it includes
an ocamltags script, thanks to ITZ.  This one does some clever parsing
to give a reasonable amount of tags, including methods.

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

Re: Looking for a nail

[Jean-Christophe Filliatre]

> 1. Bringing ocamletags to live again. I keep a copy, which
> compiles under 2.01 and reads 2.01 files, but does not create
> much tags for classes. I am willing to through this into the
> pool (if Francois Rouaix agrees).

To get Emacs tags for ocaml, a quick solution is the following :

======================================================================
find . -name "*.ml*" | sort -r | xargs \
	etags "--regex=/let[ \t]+\([^ \t]+\)/\1/" \
	      "--regex=/let[ \t]+rec[ \t]+\([^ \t]+\)/\1/" \
	      "--regex=/and[ \t]+\([^ \t]+\)/\1/" \
	      "--regex=/type[ \t]+\([^ \t]+\)/\1/" \
              "--regex=/exception[ \t]+\([^ \t]+\)/\1/" \
	      "--regex=/val[ \t]+\([^ \t]+\)/\1/" \
	      "--regex=/module[ \t]+\([^ \t]+\)/\1/"
======================================================================

It is very useful in practice. (It does not create tags for classes too.)

-- 
Jean-Christophe FILLIATRE
  mailto:Jean-Christophe.Filliatre@lri.fr
  http://www.lri.fr/~filliatr

Re: Looking for a nail

[Cuihtlauac ALVARADO]

> 1. Bringing ocamletags to live again. I keep a copy, which
> compiles under 2.01 and reads 2.01 files, but does not create
> much tags for classes. I am willing to through this into the
> pool (if Francois Rouaix agrees).

We (J.-F. Monin <JeanFrancois.Monin@cnet.francetelecom.fr> and I) made a new
small ocamltags. It creates
not too bad tags for classes, types, etc.

Send me an email to get a copy.

Best regards.

-- 
Cuihtlauac ALVARADO - France Telecom - FT.BD/CNET/DTL/MSV
2, avenue Pierre Marzin - 22307 Lannion Cedex - France
Tel {+33|0} 2 96 05 32 73 - Fax {+33|0} 2 96 05 39 45

RE: Looking for a nail

[Don Syme]

> I'm not sure this is such a good idea for CAML. The non-OO part of
> CAML is quite mature, while the OO part is more like research. Forcing
> everybody to use CAML as an OO language is IMHO not a very nice thing.
> I do not use the OO part of CAML at all right now, and I'm pretty sure
> I'm not the only one. I think we need more experience with the OO part
> of CAML (or, more fundamentally with OO programming in a functional
> language) before choosing to use it for basic types.

Yes, I'd be interested to see a really convincing use of the utility of the
OO features, e.g. a program or library which is manifestly shorter, cleaner
and/or simpler when expressed with OO rather than the core features.  I
guess people can take this as a challenge if they like :-)  I'm open to be
convinced - but I'm not convinced yet.

That said, Xavier mentions the match between COM & Ocaml, which is a good
sign!

Cheers,
Don

------------------------------------------------------------------------
At the lab:                                     At home:
Microsoft Research Cambridge                    11 John St
St George House                                 CB1 1DT
Cambridge, CB2 3NH, UK
Ph: +44 (0) 1223 744797                         Ph: +44 (0) 1223 722244
http://research.microsoft.com/users/dsyme
email: dsyme@microsoft.com
   "You've been chosen as an extra in the movie
        adaptation of the sequel to your life"  -- Pavement, Shady Lane
------------------------------------------------------------------------

Re: Looking for a nail

[Markus Mottl]

> Yes, I'd be interested to see a really convincing use of the utility of the
> OO features, e.g. a program or library which is manifestly shorter, cleaner
> and/or simpler when expressed with OO rather than the core features.  I
> guess people can take this as a challenge if they like :-)  I'm open to be
> convinced - but I'm not convinced yet.

Imagine that all basic types were classes and all of them would support
a method e.g. "print". Than you could do the following:

  let print x = x # print
  List.iter print [3; "hello"; 3.14; ["yeah, another list!"]]

or you want to map various objects to strings:

  let to_string x = x # to_string
  List.map to_string [some_object; another_object; 7; 2.7172]

Some (general) complex stuff you can do with OO (send some messages to
all objects in a container - they do not necessarily have to be members
of the same class, they only share parts of interfaces):

  ASet.iter (fun x -> x#simplify; x#factorize; x#calculate_question 42) s

If you want, I show you a zillion similar constructs, which IMHO make
life *significantly* more comfortable...

I already use this where I can, but if basic types were classes, the first
two examples would also work. There is probably hardly any program, where
you wouldn't need such constructs. Although modules are a great means of
abstraction, show me how you can do such (very readable) things with them.

When I began using the OO features, I rewrote some program to use classes
instead of (algebraic) types. The code not only became much more readable,
but it is much easier to maintain - adding new features takes (in my
experience) far less time.

Best regards,
Markus

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

RE: Looking for a nail

[John Whitley]

Don Syme writes:
 > Yes, I'd be interested to see a really convincing use of the
 > utility of the OO features, e.g. a program or library which is
 > manifestly shorter, cleaner and/or simpler when expressed with OO
 > rather than the core features.

Here's an example of something that I would like to be able to do:

If arrays were implemented as a class, then I could subclass them with
something that I was tentatively calling an arrayView class.  The
arrayView is constructed from an existing array, a stride, an offset,
and a length.  The new class only need override the array get and set
element methods, inheriting all remaining operations.  The goal is
that an arrayView can be used by any function/method that requires an
array.

The application that motivated the above idea is a lifting-scheme
based wavelet transform I have written for my research.  This
algorithm requires splitting the input into evens and odds, altering
each even/odd sub-array, then recursing on each sub-array.

The implementation in OCaml (actually, I'm using OLabl) presently
requires that I use a while loop.  (not quite back to Fortran IV,
but...;-) A for-statement with step would clean things up somewhat.
Finally, I think that the ability to create an arrayView class like I
describe would be a useful step for exploring the practice of the OO
and "core Caml" features.

IMHO, languages that support classes but lack a standard class library
aren't really "object-oriented" in an important sense.  In OCaml's
case, I suspect that the lack of a standard library has inhibited
exploration of OO-style in OCaml.

-- John

Re: Looking for a nail

[Frank A. Christoph]

>Another interesting project would be a Corba interface, as Gnome and KDE
>want to use Corba. Then Ocaml would be one of the most elegant ways to
>write desktop applications.

It's almost not worth mentioning because it's completely untested, but since everyone else is getting in on the act, I'll say that I have a mostly-complete CORBA IDL lexer and parser (but no compiler) lying around (written in Ocaml, of course). If anyone wants to use it as a starting point, send me some mail.

--FC