Le 13/10/11 16:14, stewart mackenzie a écrit :
Yves ive read your email with great interest.
Thanks :-)
Though i need clarification in certain areas
Comments inline.
On 12 Oct 2011 18:32, "Yves Jaradin" <yves.jara...@uclouvain.be
<mailto:yves.jara...@uclouvain.be>> wrote:
>
> Hello everybody,
>
> (...)
>
> The idea is therefore (but still open to discussion) to have a native
VM but one that does only the parts for which other VMs are unsuitable.
This includes Oz threads management, store representation, space
trailing, GC, etc. but no environmental support (files, sockets, GUI,
etc.) This VM would be presented as a C++ library. A program using the
library would provide the VM with environmental builtins and a (pickled)
init functor, this last one being responsible to provide the whole
runtime system. This is similar to the current design, but pushed a bit
further.
>
This means any vm say python, jvm, etc would be able to run oz code? So
interested parties would implement sockets, files etc the oz difficult
bits get shoved onto the library? Could you speak a bit about how to
efficiently handle recursion on the jvm without changing oz semantics?
What is the current stance on ARM processors? This approach should also
make it possible to get mozart running on android? Am i wrong?
Yes, any (reasonable) VM should be able to embed the Oz emulator.
Execution of an Oz program would be done entirely by the Mozart VM with
only the external operations handled by the Oz VM.
Because the Oz VM would be pure C++ without much environmental
dependency, it could be ported to any platform for which there is C++
support (that includes Android on ARM).
In particular, it is a design goal to not use C++ exceptions or RTTI as
these features are not supported on many embedded platforms (they
require runtime support).
> (...)
> For the Gump, the outlook isn't as clear. The way it currently works
is a hack. It's extremely brittle, inelegant and unorthogonal to the
rest of the language. The code it is based on is extremely old,
unmaintained, buggy and has licensing problems. I suggest that the Gump
users discuss how they want it to evolve. Some of the options I see are:
> * Keep the design (generating C code from the parser description,
compile it and load it as a native module) but push it to an optional
add-on.
> * Do a source-to-source translation in the early compiling stages to
have an entirely Oz parser (as is done with the for loop). LALR theory
isn't too difficult and writing a parser generator is a very good way to
learn it :-)
> * Find some good open source library that can generate the tables for
us and write just the driver in Oz (or C++ if performance matters that
much) in a similar way to the current solution for Gump lexers (but cleaner)
> * Make a drastic change to have a more Oz-compatible syntax and a
more modern parsing strategy such as packrat. This of course utterly
breaks compatibility.
>
I also prefer the last solution. Possibly following the arch linux or
golang way by having stdlibs distributed with the main src and further
libs are downloaded abd compiled from src.
I'm sorry but I really don't understand what you are talking about here.
The last solution is about using another parsing technology than LALR.
Do you suggest removing parsing support from the language syntax and
make it all library?
I feel there is a lot of power in gump it should be done properly.
Agreed.
> (...)
Yves
_________________________________________________________________________________
mozart-hackers mailing list mozart-hackers@mozart-oz.org
http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
