Re: tiny toplevel

[Markus Mottl <mottl@miss.wu-wien.ac.at>]

On Wed, 09 Aug 2000, Georges Mariano wrote:
> > I don't know how Java scales up with more interesting programs, but I don't
> > expect any surprises here... - so if somebody wants to go "embedded", don't
> > do it with Java... ;)
> Statitics are good but your conclusion is wrong because
> who said that "embedded" interpreters are "standard" interpreters ??

Right - on the the other hand, I could imagine that one could tweak the
interpreters of (O)Caml for "embedded systems", too: as we could see,
"caml-light" has a significantly smaller memory footprint, and we may not
have reached the ground yet...

> Obviously this is not the case, and taking Java as an example is
> also wrong because "embedded JAVA" is not JAVA but somthing close
> to JavaCard (in the SmartCards **specific** context), 
> so different constraints, specifications, and language

I cannot compare Apples to Oranges. It wouldn't be fair to take a "slim"
version of a Java interpreter and compare it with a "fat" OCaml
interpreter. Given the same purpose of the interpreters (running it on
"normal" machines), OCaml seems to be the better choice in terms of memory
consumption. Extrapolating the results to embedded systems may not be
justified, but taking the opposite view point without additional
information is probably even less so...

> Suppose that you are able to define a JAVA language subset
> wich is small enough to be embedded in, say, smartcards,
> but in the same time, you're not able to define the same subset for Ocaml
> (recall, it's a supposition!! :-)
> => you can't have OScard (Ocaml for Smart Cards :-)
> despite the comparison we made on "initial" interpreters...

Right, but it could be the other way round, too. Correct me if I am wrong,
but I suppose that runtime systems for object oriented languages are more
likely to consume more memory than ones for "just" a functional core.

E.g., given that the type system of Java is not 100% secure (statically),
it may require more code to do runtime checks.

> If I understand P. Weis, one thing is to remove Object Programming from
> OCaml, then you have something close to CamlLight toplevel, ok.
> In the context of an embedded system you may remove I/O filesystem
> functions ?? (I don't know exactly what is an embedded system...)

Maybe the developers can say more about this, but I guess it is not easy to
"peel out" just the core functionality.  OCaml seems to be mainly addressed
at "normal" computing, which addresses my needs, anyway. But who knows,
maybe OCaml has a bright future in embedded system?  (I always wanted to
run my micro-wave in a referentially transparent way... ;)

Best regards,
Markus Mottl

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