(no subject)

[Kathleen Fisher]

As part of our work on Moby, John Reppy and I are collecting
experiences people have had using the object-oriented features of
Ocaml, as it has been available long enough for people to use it "for
real."

We are interested in understanding what people use the object- 
oriented features for.  What works really well?  What doesn't work so  
smoothly?  How do you decide when to use the object-oriented  
features?  Do you have other observations you'd like to share?

I'm happy to summarize responses sent directly to me for the list.

Thanks in advance!
Kathleen Fisher

Re: [Caml-list] (no subject)

[skaller]

On Mon, 2006-01-23 at 11:37 -0800, Kathleen Fisher wrote:
> As part of our work on Moby, John Reppy and I are collecting
> experiences people have had using the object-oriented features of
> Ocaml, as it has been available long enough for people to use it "for
> real."
> 
> We are interested in understanding what people use the object- 
> oriented features for.  What works really well?  What doesn't work so  
> smoothly?  How do you decide when to use the object-oriented  
> features?  Do you have other observations you'd like to share?

OO features provide dynamic binding, which is more powerful
than polymorphism provided by any other feature other than
higher order polymorphism (which doesn't work properly in Ocaml).

However, the utility is heavily constrained by the variance
requirements.

The effect is that OO is often the best solution for
sources and sinks, and cannot be used for most relationships
(since they're usually covariant).

Thus, I am using Ocaml OO as sources and
for relationships where one type is invariant. In particular,
I am using it in the lexer phase of my compiler, with classes
to handle and factorise the state of the preprocessor/lexer,
parameterising Ocamllex action code.

Secondly, it is used to manage the inputs supplied to the
Ocamlyacc parser mainly to feed a stream of tokens to it.

In both cases the type of a token is invariant, and so
amenable to an OO solution. In both cases the technology
being leveraged -- Ocamllex and Ocamlyacc -- forces me
to control invert my logic and program reactively instead
of actively -- user actions of both tools are callbacks
driven by tool generated logic which provide no or very
limited ability to interact actively.

These uses are not intended to provide any abstraction,
they're just a convenient way to package up the functionality
and pass it around as a single value.

My back end would also benefit from use of classes.
The output data type involved -- strings -- is invariant.
Classes would provide abstraction which may assist in
making the code generator pluggable: at present it can
only generate ISO C++, it would be useful to generate C,
C--, Ocaml, or some other languages too.

This is not done at the moment, because using classes
requires knowing in advance what your abstractions are:
classes break badly with design changes. Algebraic data
structures are more flexible, adapt more easily, but it
is harder to reason about correctness when operating
directly on low level representations.

In fact, in the lexer classes, the enforced abstraction
(variables can't be accessed, you have to write get/set
methods) is actually a pain. As the system developed
I've had to add more variables and get/set methods ..
and declare separately the types in *.mli files ..
because much of the time I'm *really* working directly
with the representation. Refactoring would be a nightmare ;(

In another project I used classes much more heavily.
That project (Vyper) was an Ocaml program which implemented
the Python programming language. This was not only convenient
to model the Python objects as classes, it was also useful for
constructing lookup scopes, with methods representing the various
lookup rules.

There I used abstraction heavily, as a way of separating my
Ocaml implementation from the semantics, and this was tenable
because the semantics were well specified (by the Python language),
which itself is object based.

One final comment: classes would be MUCH more useful if, as
in C++, one had dynamically loadable code. In that case
algorithms can work with class types instantiated at run time,
the dynamic binding is fundamental, and the enforced abstraction
vital. I exploit this heavily in Felix, which generates shared
libraries which are dynamically loaded by a driver program,
which runs the code using C++ abstract base methods.

In Ocaml you have to link all the instances in anyhow..
so the dynamic binding isn't nearly as useful. For Vyper this
was one of the major factors killing the project: there
was a need to model all the C extension to Python -- and there
are a LOT of them -- the same way Python does: by dynamic loading.
The Ocaml emulation had to statically link every extension,
which apart from being a pain, introduces the possibility that
the intended bindings are not fully abstracted.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

(no subject)

[DESMONS Bertrand]

> With "cmd /c dir", you should see a file "liblapack.a.lnk" (in /lib).
> Can you see it? Is there a file "liblapack.a" as well?


acer@PC ~
$ cd /usr

acer@PC /usr
$ cd lib

acer@PC /usr/lib
$ ls
X11                libasprintf.la     libe2p.a         libpthread.a
automode.o         libautomode.a      libexpat.a       libss.a
awk                libbfd.a           libexpat.dll.a   libtermcap.a
binmode.o          libbfd.la          libexpat.la      libtextmode.a
charset.alias      libbinmode.a       libext2fs.a      libtextreadmode.a
crt0.o             libblas.a          libg.a           libutil.a
dri                libblas.dll.a      libgmon.a        libz.a
e2fsprogs          libblkid.a         libiberty.a      libz.dll.a
engines            libc.a             libintl.a        mingw
gcc                libcom_err.a       libintl.dll.a    perl5
gcrt0.o            libcrypt.a         libintl.la       terminfo
groff              libcrypt.dll.a     liblapack.a      textmode.o
lapack             libcygicons.dll.a  liblapack.dll.a  textreadmode.o
ldscripts          libcygicons.la     libm.a           w32api
libasprintf.a      libcygwin.a        libopcodes.a
libasprintf.dll.a  libdl.a            libopcodes.la

acer@PC /usr/lib
$ ls -l liblapack.a
lrwxrwxrwx 1 acer Aucun 15 Apr  3 10:28 liblapack.a -> liblapack.dll.a

acer@PC /usr/lib
$ ls -l liblapack.dll.a
-rw-r--r-- 1 acer Aucun 739504 Mar 24  2006 liblapack.dll.a

acer@PORTABLE /usr/lib
$ cmd /c dir
 Le volume dans le lecteur C s'appelle ACER
 Le numéro de série du volume est 1054-16AB

 Répertoire de C:\cygwin\lib

29/10/2008  11:05    <REP>          .
29/10/2008  11:05    <REP>          ..
19/10/2003  10:12            18 452 libcrypt.a
19/10/2003  10:12             2 538 libcrypt.dll.a
24/08/2007  08:40               842 libcygicons.dll.a
24/08/2007  08:40               766 libcygicons.la
12/06/2008  18:36               554 automode.o
12/06/2008  18:36               375 binmode.o
12/06/2008  18:36               536 crt0.o
12/06/2008  18:36               656 gcrt0.o
12/06/2008  18:36               708 libautomode.a
12/06/2008  18:36               530 libbinmode.a
12/06/2008  18:36           803 428 libc.a
12/06/2008  18:36           976 188 libcygwin.a
12/06/2008  18:36             3 072 libdl.a
12/06/2008  18:36             5 384 libgmon.a
12/06/2008  18:36            94 936 libm.a
12/06/2008  18:36            58 478 libpthread.a
12/06/2008  18:36               530 libtextmode.a
12/06/2008  18:36               682 libtextreadmode.a
12/06/2008  18:36            10 486 libutil.a
12/06/2008  18:36               375 textmode.o
12/06/2008  18:36               528 textreadmode.o
29/10/2008  11:06    <REP>          awk
29/10/2008  11:06    <REP>          groff
09/05/2008  05:03           162 740 libexpat.a
09/05/2008  05:03            53 002 libexpat.dll.a
09/05/2008  05:03               773 libexpat.la
21/04/2005  21:37            25 150 libtermcap.a
29/10/2008  11:07               398 terminfo.lnk
29/10/2008  11:23    <REP>          ldscripts
08/07/2008  23:14           674 930 libbfd.a
08/07/2008  23:14               884 libbfd.la
08/07/2008  23:14           214 806 libiberty.a
08/07/2008  23:14           593 214 libopcodes.a
08/07/2008  23:14               896 libopcodes.la
29/10/2008  11:23    <REP>          gcc
30/03/2009  22:45    <REP>          e2fsprogs
14/09/2004  21:39            28 212 libblkid.a
14/09/2004  21:39             5 524 libcom_err.a
14/09/2004  21:39            23 652 libe2p.a
14/09/2004  21:39           122 960 libext2fs.a
14/09/2004  21:39            21 470 libss.a
31/12/2008  10:03            48 396 libintl.a
31/12/2008  10:03            30 674 libintl.dll.a
31/12/2008  10:03               926 libintl.la
31/12/2008  10:03               215 charset.alias
31/12/2008  10:02             3 324 libasprintf.a
31/12/2008  10:02             6 294 libasprintf.dll.a
31/12/2008  10:02               914 libasprintf.la
30/03/2009  22:45    <REP>          dri
30/03/2009  22:45    <REP>          X11
30/03/2009  22:45    <REP>          mingw
30/03/2009  22:45    <REP>          engines
30/03/2009  22:45    <REP>          perl5
30/03/2009  22:46    <REP>          w32api
02/03/2009  03:19            73 190 libz.a
02/03/2009  03:19            43 018 libz.dll.a
03/04/2009  10:28    <REP>          lapack
24/03/2006  07:31           181 936 libblas.dll.a
24/03/2006  07:31           739 504 liblapack.dll.a
              47 fichier(s)        5 037 046 octets
              14 Rép(s)   2 397 175 808 octets libres


It is really strange for me... 'ls' recognizes liblapack.a, but I don't
see it using 'dir' ... ? There is also no liblapack.a.lnk, but isn't that
due to the fact that liblapack.a is a symbolic link?

Re: [Caml-list] (no subject)

[Alain Frisch]

DESMONS Bertrand wrote:
> It is really strange for me... 'ls' recognizes liblapack.a, but I don't
> see it using 'dir' ... ? There is also no liblapack.a.lnk, but isn't that
> due to the fact that liblapack.a is a symbolic link?

As far as I understand Cygwin, if liblapack.a is a Cygwin symlink, there 
should really be a file liblapack.a.lnk in the directory. I don't 
understand what is going on.

-- Alain

RE: [Caml-list] (no subject)

[David Allsopp]

Alain Frisch wrote:
> DESMONS Bertrand wrote:
> > It is really strange for me... 'ls' recognizes liblapack.a, but I
> don't
> > see it using 'dir' ... ? There is also no liblapack.a.lnk, but isn't
> that
> > due to the fact that liblapack.a is a symbolic link?

Try dir /a - perhaps the attributes on the .lnk file are weird... which
might also be the cause of the problem if it's got hidden or system
attributes set for some reason.
 
> As far as I understand Cygwin, if liblapack.a is a Cygwin symlink,
> there
> should really be a file liblapack.a.lnk in the directory. I don't
> understand what is going on.
> 
> -- Alain

Could be a longshot - but might this be related to an issue I reported
building MinGW PCRE a month or so ago. In order to get PCRE to link, I had
to rename the actual libpcre.a to libpcre.a.old (i.e. get rid of it) and
then rename libpcre.dll.a to libpcre.a. I can't remember what the error
message was.

I think that the problem is something to do with GNU libtool - which gcc's
linker presumably understands but flexlink doesn't... but I didn't get a
related answer to
http://groups.google.com/group/fa.caml/browse_thread/thread/e9ff1f8ef73181d0
?pli=1



David

(no subject)

[Stéphane Payrard]

Hi,

I am an ocaml beginner and I try to compile the last snapshot of
camelon. I am using mandrake with the following rpms:
   ocaml-lablgtk-1.2.7-1mdk
   ocaml-3.08.2-1mdk

I get the following message when trying to compile:

Files /usr/lib/ocaml/lablgtk/gtkThread.cmx
and /usr/lib/ocaml/threads/threads.cmxa
make inconsistent assumptions over implementation Thread

Should I use different versiosn of either lablgtk or ocaml?
The INSTALL file suggest OCaml 3.07  and LablGtk 1.2.6 .
Or is there an easy way to tweak cameleon to get it to compile
with the ocaml and lablgtk versions I have.



--
 stef

Re: [Caml-list] (no subject)

[Jon Harrop]

On Tuesday 18 January 2005 07:33, Stéphane Payrard wrote:
> Hi,
>
> I am an ocaml beginner and I try to compile the last snapshot of
> camelon. I am using mandrake with the following rpms:
>    ocaml-lablgtk-1.2.7-1mdk
>    ocaml-3.08.2-1mdk
>
> I get the following message when trying to compile:
>
> Files /usr/lib/ocaml/lablgtk/gtkThread.cmx
> and /usr/lib/ocaml/threads/threads.cmxa
> make inconsistent assumptions over implementation Thread
>
> Should I use different versiosn of either lablgtk or ocaml?
> The INSTALL file suggest OCaml 3.07  and LablGtk 1.2.6 .
> Or is there an easy way to tweak cameleon to get it to compile
> with the ocaml and lablgtk versions I have.

I think this problem is due to different ocaml versions being used to generate 
lablgtk and threads.

Interfaces between OCaml compilation units are *very* brittle. This is being 
discussed on the list at the moment, as even a minor version change of the 
compiler (e.g. 3.08.2 -> 3.08.3) breaks compatibility.

The good news is that this binary incompatibility is because the compiler is 
very pedantic about interfaces and guarantees that everything will work.

Your best bet is either to compile all of the packages yourself or to use 
someone else's packages. I find Debian to be excellent in this respect.

Cheers,
Jon.

PS: 3.08 has some useful additions which you may well find that people use in 
their code now (e.g. immediate objects).

[Caml-list] (no subject)

[Nicolas Tacheny]

auth 4125c0d1 subscribe caml-list nicolas.tacheny@umh.ac.be

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