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