Browse thread
[Caml-list] [ANN] The Missing Library
-
John Goerzen
-
Kenneth Knowles
- Alexander V. Voinov
-
John Goerzen
-
Maxence Guesdon
-
John Goerzen
- Maxence Guesdon
-
John Goerzen
-
Alain.Frisch@e...
-
John Goerzen
-
Alain.Frisch@e...
-
Nicolas Cannasse
-
Yamagata Yoriyuki
- Gerd Stolpmann
-
Nicolas Cannasse
-
Yamagata Yoriyuki
- Jacques GARRIGUE
- Nicolas Cannasse
-
Yamagata Yoriyuki
-
Yamagata Yoriyuki
-
Nicolas Cannasse
- oliver@f...
-
Alain.Frisch@e...
-
John Goerzen
- Henri DF
- Shawn Wagner
- james woodyatt
-
Alain.Frisch@e...
- Basile STARYNKEVITCH
-
John Goerzen
- Kenneth Knowles
- Florian Hars
-
Maxence Guesdon
- Eric C. Cooper
-
Kenneth Knowles
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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:
f().apply(1)
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
1
2
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