Craig Ugoretz wrote:
Hello,
As I think of this matter further, I wonder if I am getting
into issues addressed by Chapter 11, Distributed Programming, in the
CTM book. If that is the case, then I possibly have a lot more
research to do in terms of understanding first Mozart-Oz programming
up to Ch. 11, and then the complexities of distributed programming
with a foreign language.
Craig
I don't think you'll need the content of this chapter the way you are
thinking of. You will probably end up with a Java program and an Oz
program needing to communicate with each other, and for this you might
find it useful to learn about the different concepts used for
distributed programming. But you won't be able to use the nice
transparency that Oz enables as this works only between Oz programs by
the virtue of a large body of code in the emulator. You could probably
implement the same distribution protocols in Java but at least on this
side, it won't be transparent and I advise you to avoid doing this as
this part is being rewritten right now (Mozart/DSS).
On 3/9/07, *Craig Ugoretz* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hello,
As I go forward thinking about integrating Mozart-Oz into
Eclipse, I realize that there may be three general options:
(1) Extending the CDT (have been posting to this mailing
list about this).
I don't think this will work because Oz is not closer to C than to Java.
Extending the CDT is easy for traditional languages which use the same
model and target as C. Oz use it's own virtual machine. The work to make
an Oz plugin in Eclipse is probably more comparable to the work done in
CDT itself.
(2) Using the way the Mozart-Oz tools as they currently work
as specifications for an Eclipse implementation (with
modifications to incorporate the tools into Eclipse views,
editors, etc.).
This is probably possible but is not easy. Most of the tools are written
in Oz and as such can not run on the Java VM. The only practical way to
interface them with a Java program is over TCP/IP sockets. This would
require cutting the user interface of these programs and replacing it
with socket communication and implementing in Java a user-interface
connected to the sockets. The main difficulty is that these programs
were not intended to be modified in this way and may make assumption
about the interface being Tcl/Tk (such as writing Tcl scripts to be
executed by the interface).
(3) A full integration of Mozart-Oz into Eclipse from
scratch with the tools looking entirely different to take full
advantage of Eclipse functionality.
This is very difficult. It would probably amount to write an Oz virtual
machine in Java. This would be extremely nice since the current virtual
machine is showing its age but this is a major undertaking. It is
probably not much easier than the dual (that you probably did not even
consider): writing a Java Virtual Machine in Oz which could run Eclipse.
In regard to (2), I have been thinking about what it would
take to translate graphical tools written using the Tk graphics
engine into the Java SWT widgets that are used by Eclipse. I am
not fully familiar with Gump, but perhaps, if I understand what it
does correctly, linguistic abstractions could be added to Oz such
that Java classes (on a client) could be wrapped (under the hood)
by Oz classes (on a server), with communication in between as a
possible design alternative.
Gump is nothing more than a way to write lex and yacc parsers. It allows
an Oz program to parse a string and make a syntax tree out of it. This
will only be useful if you have such a complex protocol between Oz and
Java that you need such tools to parse it. Since this protocol would be
totally internal (not user-visible) the language should be trivial to
parse (we don't care about it being verbose).
If the above scenario would turn out to be valid (in a
sequential program), how would the issue of the Java objects being
stateful and possibly launching threads of their own be handed by
Oz, which uses threads itself? As I understand it, handling state
and threads is a difficult or advanced topic. Does the Tk
graphics engine as it stands take into account threads in its
operation and is Tcl/Tk considered stateful and can use threads
itself?
You seem to focus much onto a very tight integration which is extremely
hard to do. I would guesstimate it at several man-years with a good
background on both platforms and their implementation.
My own idea of how to do this plugin is as follow:
Start very simple.
A text editor which can send part of the text to an external program
(exactly like emacs is doing now).
Create step-by-step a model of the program text so as to support (from
simplest):
syntax highlighting
lexical analysis
syntaxical analysis (outline)
scope highlighting
static analysis
code completion
abstract interpretation
Only then would I consider a better integration of compilation,
execution and debugging, probably along the line of (3) but maybe with
some temporary shortcuts using (2).
Sincerely,
Craig
P.S. Implementation (2) could be a step towards (3) if (1) is
ruled out. This is all conjecture until I actually write some
code to test it, but I am curious about the thread issue upfront.
I hope my answer did not discourage you from this extremely welcome
contribution. I wrote this to, as much as possible, lead you out of the
deepest pits that I saw in your description.
Cheers,
Yves
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
