Yves ive read your email with great interest. Though i need clarification in certain areas Comments inline.
On 12 Oct 2011 18:32, "Yves Jaradin" <[email protected]> wrote: > > Hello everybody, > > First, I want to thank everyone who commented so far. You, users of the platforms, are the Mozart community and it is exactly because we don't want developers-only input that we asked for comments. > > Regarding the technical aspects, I read most the comments as focusing on a decision we implicitly made which is to do a VM rather than a compiler. All the posts advocating that we target the JVM (or another existing VM for that matter) are essentially pushing the hard-work to the compiler. > > We didn't much consider this option for the following reasons: > > * The current split between compiler and Mozart VM has proved workable and efficient. The problems we are currently facing have more to do with the quality of implementation than with the design. > > * A simple compiler would lead to very bad performance. The semantic of Oz is rather unfriendly to the expectations of most VMs. As an example, the simple Oz statement X=A+B has 3 synchronization points. The addition can have to wait on A, then on B and finally the unification can have to wait (if X is a read-only). Using three tasks for such a statement is much too fine-grained to hope for a good performance. > > * A complex optimizing compiler is even more difficult to write than a VM. It is also less performant as it as to make safe assumptions about unknown parts of a program (e.g. because of separate compilation) which essentially brings back to the previous bullet.Even worse, it becomes very difficult for the Oz programmer to understand the performance implications of using certain constructs as it will depend heavily on the degree of completeness that the (complex) optimizations of the compiler will achieve. Finally, the multiplication of the possible runtime executions for a given source construct make debugging of the platform more difficult and increases the size of the bug examples. > > > > 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? > In particular, the "program" using the Oz VM library could be a Java native library that would provide the VM with the JNI interface as builtins. This would make an implementation of the whole platform that would be portable anywhere Java+JNI is supported. Of course an implementation providing the builtins of the current implementation in a more direct way is also possible. > > This brings to the way we want to deal with the rest of the Mozart ecosystem, such as the GUI (Tk and QTk), parser generator (Gump), etc. > > For the GUIs, the perspective are rather good. Most of the code is in Oz. The only parts which are not are in platform/emulator/tk.cc and should be rewritable in Oz easily. This would offer an easy transition path. If the performance of the rewriting is too bad, it would still be time to decide to redo the necessary builtins in C++ for the new VM. > The really good thing is that this can be done *now* (before the new VM) and should be an easy yet very visible task for someone wanting to give a hand. > > 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 feel there is a lot of power in gump it should be done properly. > While I like the last solution, I'd clearly understand that need one of the others as a portability route. > > Cheers, > Yves > _________________________________________________________________________________ > mozart-hackers mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
_________________________________________________________________________________ mozart-hackers mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
