[Caml-list] (no subject)

[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

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

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)

[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

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