Hello Torsten,
My answers are inline as well.
Le 13/10/11 19:21, Torsten Anders a écrit :
Dear Yves,
I greatly appreciate your detailed response. I also do my comments inline below.
On 12 Oct 2011, at 11:32, Yves Jaradin wrote:
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.
Thanks for making that clear. We know all that the most promising way for the future of
Mozart/Oz is to engage some community which contributes bug reports and ideally patches
etc., and those will of course often be "just" users :)
Should we perhaps move/copy this discussion into the Oz-user email list to
widen participation?
In my view, oz-users is meant to be a non frightening mailing-list where
no question is too simple. A place where people can come if they have a
missing end or a strange error because they put comas in-between list
elements. A list for everyone who has to use the platform without
necessarily having any interest in it. The hackers mailing-list, is for
people caring in some way about Mozart. Of course discussions can
sometimes get very technical and only a few persons will follow them but
it is also the place for more general discussions like this one.
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 must confess that I am unable to follow all your technical details, but what
I understand is that a new native VM for Oz could become some library that
could be integrated in principle in any language with a C++ interface. So, I
understand that once such an interface has been developed, we could program in
the Oz language but using, say, the GUI library of this other language. Did I
understand that correctly?
Yes, that's a very good summary of it. Much better than what I was
trying to write as an answer to Stewart.
If so, then that is most wonderful news and fully substitutes the previously
mentioned need to target the JVM, or some other existing VM like that.
Would it perhaps also be possible if the Oz VM can be integrated as a library
into other languages to use Oz constructs within those other languages? That
could be very helpful for the Oz community to sell their ideas...
That would be very nice but isn't something I intend to do at first.
However we had a master thesis last year that re-targeted the Scala
compiler to Oz, adding some of the Oz concepts to Scala, so this is
definitely something possible in some form.
For the Gump, the outlook isn't as clear.
For my own project (Strasheela) Gump has been very useful, so I would like to
have some parser generator (or similar). However, I would not mind to
completely rewrite all the Gump code I wrote if the new replacement for Gump
would be more stable etc. In other words, for my projects I don't need
compatibility.
That's good to hear because, as far as I know, you are the most eminent
Gump user.
However, there is a parser written in Gump that compiles the Oz programming
language itself, and which is used in the ozh project (code documentation
tool). Generating documentation for software is important and therefore
something like ozh is very useful to keep. So, this could be a compatibility
issue, but should not hinder the redesign too much. Any idea how we could
address the need for something like ozh if we break compatibility?
The ideal solution would be to have a single parser for the compiler and
the documenter that keeps comment in the AST, attached to the
construction they relate to. The compiler can just drop them and the
documenter use them. I seem to remember that ozh is quite difficult to
use and requires an old version of Mozart to run, so we can consider
that, sadly, it is already broken.
Does anyone here know where Gump has been used elsewhere?
I never like it much so I used a PEG approach anytime I needed parsing,
so nowhere for me.
Again, thanks a lot for your response.
You are welcome,
Best wishes,
Torsten
Yves
--
Dr Torsten Anders
Course Leader, Music Technology
University of Bedfordshire
Park Square, Room A315
[email protected]
http://strasheela.sourceforge.net
http://www.torsten-anders.de
_________________________________________________________________________________
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
