Hi, Just a few comments inline...
On Wed, Oct 12, 2011 at 12:32 PM, Yves Jaradin <yves.jara...@uclouvain.be>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. > I agree with the above analysis. The Oz compiler should transform an Oz program into the kernel language, and then the kernel language to a VM language. Keeping transformation kernel -> vm simple is a major advantage for code maintenance and performance. 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. > I see a potential issue with blocking I/O. The language threads in the current Oz VM works well because all I/O are non-blocking. In order to make the Oz threads "look" responsive, I/O operations should not block the VM. 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. > I think that some effort should be done on the binding of native libraries in Oz. The effort of binding a library to the VM should only consist in implementing a few simple C++ classes. I believe that all Oz data structures should implement the same C++ API by inheriting some general base class. Such an effort was necessary to distribute Oz on top of the DSS: every data operation had to be abstracted as either a read, a write, a send (asynchronous write), or a bind (for variables). One also needed one or two extra methods for the gc. A simple and well-chosen API was part of the success of Python: porting a C library is really easy. 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. > What about Pratt parsers (http://en.wikipedia.org/wiki/Pratt_parser) ? It is really nice for parsing a mixture of prefix/infix/postfix operators with different binding priorities without having to write hundreds of grammar rules. You don't have to rewrite your whole grammar to fit LALR constraints. It is also more compositional. And performance is very good, because you can write some pragmatic hooks where necessary to make the parsing completely deterministic. Those were my two cents :-) Cheers, Raphael
_________________________________________________________________________________ mozart-hackers mailing list mozart-hackers@mozart-oz.org http://www.mozart-oz.org/mailman/listinfo/mozart-hackers
