On Sat, 2005-11-12 at 12:35 +0900, Nicolas Cannasse wrote: > Introspection is useful in order to do "funny" things such as TopLevel > console. It also have a lot of cases where you want to "bind" some data > to a database, or generate polymorphicaly XML from any value.... In > general, everytime you want to interact with the outside dynamicly typed > world.
The problem is, the introspection data is never enough for any particular application ;( As you point out below, the NekoML compiler forgets the NekoML data type -- and the ML user isn't really interested in introspection on the Neko data type. What I think will be interesting to look at is how to build *user defined* introspection data. This can be done now, for any system, by writing all by hand: make your own keyed data tables, and glue the key to them into the data. The question becomes, how can the compiler support this, and reduce the difficulty of the task? And, at the same time, make it less expensive in performance, whilst also providing some assurance you haven't missed any cases. > But it's really enough to program large systems :) > The speed is nowhere near the one of OCaml native executables since > we're currently running it on top of a dynamicly typed VM but it's > actually already pretty good right now and will improve with the time > (JIT, a better GC, ...) Hehe .. that's the wrong way. Forget JIT. The idea is to optimise the Neko code by compiling to native code, eliminating the VM. In the first instance (without optimisation), this is quite easy -- just replace the bytecodes with the C function calls that the interpreter invokes when it see them. The advantage of this approach is that you can separate optimising the bytecode -> native code separately from the Neko -> bytecode (and also, bytecode -> bytecode .. :) The MOST important rule though, is to be sure that in the language specification, the throwing of exceptions for various error conditions is NOT part of the language specification: you make that part of the specification of your particular implementation, but for the language specification you must say the behaviour is undefined. Without this, it is impossible to deduce types, because that deduction requires the assumption type errors will not be thrown. In general, system exceptions must never be part of the language specification. Behaviour of user raised exceptions is, of course. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net --- Neko : One VM to run them all
