Didier Remy | 2 Jan 11:38 2001
Picon
Picon

Re: A proposal for overloading ...

Christophe,

I am afraid that the picture might be far more complicated that what your
description suggests. Of course, two identifiers might have ambiguous
types when considered alone, but become unambiguous when combined together
in a program (this is at the basis of overloading, when the context should
be used to desambiguate). For instance,

        foo: int -> int or string -> string
        bar: string or bool

Then, (for, bar) is ambiguous but (foo bar) is not.  

However, to solve the latter case seems to imply something more complicated
than your simple schema. 

The above example is just a basic example of overloading.  There are many
variations involving ambiguous (maybe polymorphic) local bindings that are
used non-ambiguously for which it is not clearly whether their should be
ambiguity should be resolved or propagated.

In summary you cannot save the effort of a careful formal specification of
what is an overloaded symbol, how overloading is propagated, and how it is
resolved.

> Then, if there is still some identifiers with ambiguous value, we choose
> one (the first by position in the source code ?), and assign it the
> first possible value in the list (this choice insure compatibility with
> existing code). 

(Continue reading)

Pierre Weis | 2 Jan 18:02 2001
Picon
Picon

Happy New Year

Hi everybody,

As you may have noticed, we are just in the middle of the greetings
season.

That's why, I'm glad to wish all of you a happy new year, with a lot
of happy, easy, funny, and profitable hacking with Caml.

I'm also glad to wish a happy new year to the Caml implementors team
and the Cristal projet members. I'm sure the good job will continue
this year, we will issue even better Caml compiler releases, and get a
lot of amazingly successful stories with our favorite language.

Bonne année à tous.

Pierre Weis as the moderator of the Caml mailing list.

INRIA, Projet Cristal, Pierre.Weis <at> inria.fr, http://pauillac.inria.fr/~weis/

Christophe Raffalli | 2 Jan 20:08 2001
Picon

Re: A proposal for overloading ...

Didier Remy a écrit :
> 
> Christophe,
> 
> I am afraid that the picture might be far more complicated that what your
> description suggests. Of course, two identifiers might have ambiguous
> types when considered alone, but become unambiguous when combined together
> in a program (this is at the basis of overloading, when the context should
> be used to desambiguate). For instance,
> 
>         foo: int -> int or string -> string
>         bar: string or bool
> 
> Then, (for, bar) is ambiguous but (foo bar) is not.
>
> However, to solve the latter case seems to imply something more complicated
> than your simple schema.

My proposal would not solve this problem automatically but at least it
will give overloading of arithmetical operator (if you still keep
separate constants) and a few others. It is clear that if you want
something more general,
you need an algotihm that implements some kind of bactracking or that
infer all the possible types and altough it is possible, it seems much
more complex ...

> 
> The above example is just a basic example of overloading.  There are many
> variations involving ambiguous (maybe polymorphic) local bindings that are
> used non-ambiguously for which it is not clearly whether their should be
(Continue reading)

Markus Mottl | 2 Jan 17:07 2001
Picon

JIT-compilation for OCaml?

Hello,

one thing I just wondered about is whether there are any intentions
concerning a JIT-compiler for OCaml byte code similar to what Java
offers. This would allow much faster execution while still retaining
full portability of the byte code. Is this a goody we might expect in the
(near? far?) future?

- Markus Mottl

--

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

William Chesters | 2 Jan 18:39 2001

Re: status of some big "important" features?

Daniel de Rauglaudre writes:
 > Camlp4 allows to make syntax extensions. We could imagine something to
 > make typing extensions and code generating extensions. But I don't
 > know how to do that, and even if it is possible in a simple way.
 > 
 > Do other caml-list readers have an opinion about that?

The actual source code for the compiler as it is now is pretty decent, 
remarkably so given its maturity, and it's hard to imagine any useful
"semantic extension" mechanism being much simpler than just hacking the
relevant bits of camlc.

My 2p,
W

Mattias Waldau | 2 Jan 19:16 2001
Picon

RE: JIT-compilation for OCaml?

Why do you want JIT? Do you use Java for regular development? It is a pain,
the reason is

1. Slow, slow
2. Big, big

and the reason that Java gets away with it, is the JIT-compiler. That mean
that after enormous start-time, the program might achieve resonable
performance after a couple of minutes. However, at that time, it still needs
10-20 extra megs, since the compiler is still loaded into memory.

The beatty of Ocaml are the fast compilers, the optimizing compiler is
faster than javac, which only produces bytecode. It is sad that so few
other programming language developers realizes that the speed of the
development environment matters.

The only thing Ocaml can learn from Java is its libraries. If I would invent
a programming language with a library today, I would just copy Java's
interface. Libraries are much harder to learn than programming languages,
thus standards are needed.

/mattias

-----Original Message-----
From: Pierre.Weis <at> inria.fr [mailto:Pierre.Weis <at> inria.fr]On Behalf Of
Markus Mottl
Sent: Tuesday, January 02, 2001 5:08 PM
To: OCAML
Subject: JIT-compilation for OCaml?

(Continue reading)

Markus Mottl | 2 Jan 20:30 2001
Picon

Re: JIT-compilation for OCaml?

On Tue, 02 Jan 2001, Mattias Waldau wrote:
> Why do you want JIT?

I don't need it currently, but I can imagine applications that greatly
benefit from it.

> Do you use Java for regular development? It is a pain,

No, I don't use it at all, but I believe you that it must be very
painful ;)

> the reason is
> 
> 1. Slow, slow
> 2. Big, big

Maybe that's because the Java JIT-compilers were not written by Xavier? ;)

> and the reason that Java gets away with it, is the JIT-compiler. That mean
> that after enormous start-time, the program might achieve resonable
> performance after a couple of minutes. However, at that time, it still needs
> 10-20 extra megs, since the compiler is still loaded into memory.

It shouldn't be too difficult to come up with a protocol that informs
the interpreter whether it should actually use JIT-compilation or not
and if yes, how it should compile the code for optimum performance, etc.

This meta information could be generated by passing options to the byte
code compiler or maybe even by some kind of pragmas in the source. Or
maybe by a magnificent program analysis tool that finds the "hot spots"
(Continue reading)

Charles Martin | 3 Jan 00:33 2001

New Year's resolution suggestions...

... for the OCaml implementors :)

(1) overloading, or something with equivalent functionality

(2) explicit declarations for operator associativity and precedence

Happy New Year!

Mattias Waldau | 3 Jan 14:23 2001
Picon

RE: JIT-compilation for OCaml?

If you just want portability, then why not generate Java-byte code instead
of Ocaml-bytecode. Then you can distribute you Ocaml-applications in Jars.
And you can benefit from the JIT of SUN etc, for example SUN's latest JIT
called HotSpot.

This has been done for many languages, for example JPython.

See http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html for more examples.

/mattias

> Certainly! I definitely don't want to replace the normal byte code
> interpreter with a purely JIT-one. My motivation was rather portability +
> speed rather than speed alone. For the latter "ocamlopt" is more than
> good enough, and for portability we have the byte code compiler. But
> if you want to have portability with reasonable speed for demanding
> applications...

Alain Frisch | 3 Jan 13:15 2001
Picon
Picon

Re: JIT-compilation for OCaml?

Hello,

my 0.02 euros ideas about a JIT for OCaml:

There are basically two ways to JIT-compile a bytecode program: at
startup or during runtime.

Compiling the bytecode at startup makes sense for instance for web
distributed code (applets). Otherwise, if the code is to be used more than
once by a given user, it's better to convert statically the bytecode to
native code. Hacking ocamlrun to produce native code simply by expanding
each opcode from the abstract machine seems fairly easy. Some
optimizations are lost. Another idea would be to make the compiler
outputs the "lambda" intermediate code (shared between ocamlc and
ocamlopt) and distribute it, maybe with some modification to
prevent reverse engineering. The backend of ocamlopt (code generation)
is run by the user to produce an executable program.

Compiling the code really during runtime opens the door to further
optimizations (I guess this is how Java JIT compilers work, but I have no
idea). For instance, it is possible to watch conditionnal jumps and
reorganize the code so that the most taken branches don't need any jump.
The GC and the memory allocator have the opportunity to adapt themselves
to the application. Of course, this only makes sense for long running
applications. The user should be able to record the optimization
information collected. Actually, there are two operations involved: a
profiler (a bytecode interpreter that also collects optimization
information) and a bytecode-to-nativecode converter as in the previous
paragraph. I don't see the advantage of mixing them in a complex JIT
compiler (which will be slow for a long time after startup if the
(Continue reading)


Gmane