English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] [ANN] The Missing Library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-05-03 (15:08)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] [ANN] The Missing Library
On Mon, 2004-05-03 at 22:40, Marcin 'Qrczak' Kowalczyk wrote:

> > In Felix this can't be a problem for functions, only for
> > variables. Unlike Ocaml, 
> > 
> > 	fun f ...
> > 
> > declares a class, whilst
> > 
> > 	let f x = ..
> > 
> > in Ocaml constructs a value.
> I don't understand.

In Felix,

	fun f(x:int) = { return x; }

declares a class:

	struct f {
		int apply(int x) { return x; }

So *direct* calls are like:


where the closure is created on the fly.
The Ocaml:

	let f x = x

defines f as a variable already containing
the closure .. so you can't call f until
that variable is actually initialised.

> The problem in my language is that here:
>    let f x {y + 1};
>    let z = f 10;
>    let y = z + 1;
> there is no single place which should be detected as an error.

Same in Felix:

include "std";
fun f (x:int):int= { return y + 1; }
val z = f 10;
val y = z + 1;

print z; endl; 
print y; endl;

[skaller@pelican] ~>flx xxx

Well, no run time error: y just happens to
be zero initially :)

> 2. Ordinary code uses dynamic dispatch a lot, e.g. for all arithmetic,
>    and currently the only way to avoid that is to use inline C code
>    (similar to inline asm in C). Even some type inference would not
>    help much because of bignums (did I say that I hate arbitrary
>    limitations? I can't just not have bignums!).

Felix uses gmp. However it has all the C int types as well.
Oh .. none of them are built in, not even bool.
You *have* to 'inline C' the lot.

Did I say I hate arbitrary limitations like needing
to have builtin types? <g>

>  Even if I implement
>    inlining, not much could be inlined from a dispatched function.
>    Performing the dispatch statically when possible would be very
>    hard...

You'd be surprised. When I wrote Vyper, I did a lot
of analysis to try to make things static.
For Python, that proved almost impossible.

With a little care you can probably 
do very much better with just a little type inference.

John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language 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