Prism Metaprogramming Tool released

[Laurent Martelli]

>>>>> "Jim" == Jim Little <jiml@inconnect.com> writes:

  Jim> Laurent Martelli wrote:
  >> >> Is it real necessary to have these 4 phases ? Why should we >>
  >> define integer arithmetics before object orientation ?
  >> 
  Jim> Hmm, good question.  The short answer is that new Prism
  Jim> languages are written with existing Prism languages.  It's
  Jim> easier to start by creating small building blocks, then using
  Jim> those to create larger structures.
  >>  Yes, of course. But I'm not sure that integers are required to
  >> do interesting things, other than arithmetics. I think that sets
  >> and operations on them are more powerful and more needed. But
  >> it's a matter of what you want to do.

  Jim> Hmm... come to think of it, I'm not sure if integer support is
  Jim> necessary at this time.  I've been trying to think of
  Jim> situations where they would be necessary, and I can't think of
  Jim> any.  The only situation I can think of is when you're doing a
  Jim> straight counting loop -- 'for (int i=0; i<3; i++)' -- and
  Jim> those are actually pretty rare in real programs.  You much more
  Jim> frequently iterate through a data structure.

  Jim> But integer arithmetic will be needed at some point, and its a
  Jim> nice easy task to start out with.

  Jim> What sorts of operations on sets were you thinking of?  The
  Jim> Prism tool VM already supports lists and bags and operations on
  Jim> them.

I was think about union, intersection, iteration, testing if an object
is a member of a set, adding an element, removing an element, counting
elements ... Very basic operations after all.

  >> Sure. I'm just trying to really separate UI from semantics so
  >> that in the end, semantics do not depend on UI and UI can be
  >> changed easily.

  Jim> That was one of my goals, too.  Prism languages express
  Jim> syntax/UI and Prism metamodels express semantics.  Thus it's
  Jim> possible to have multiple languages for one metamodel.

  Jim> By the way, where can I learn more about OIL?
  >>  http://laurent.penguinpowered.com/~laurent/oip.html

  Jim> OIL seems very similar to Prism:

  Jim> "The goal of this project is to build an open interpretor that
  Jim> will support Aspect Oriented Programming (AOP). It will also be
  Jim> reflexive in the sense that we will reimplement it in itself,
  Jim> so that we can apply AOP's principles to the interpretor."

  Jim> The above statement (from your web page) could equally well
  Jim> apply to Prism, if I understand it correctly.  One thing I'm
  Jim> not clear about: Prism allows new languages and compilers to be
  Jim> added to the tool at runtime -- is that also true of OIL?

It depends on what you call a language :-) 

OIL is not reflexive yet, so it's nothing more than a lisp machine for
the moment. But once it is reflexive, we'll be able to build new UIs,
new syntaxes. But the core semantics of the interpretor will be the
same. Adding new semantics is achieved by adding new services. If you
create a special UI for some special services, you'll somehow have a
new language. 

  Jim> If my understanding of OIL is correct, how do you plan on
  Jim> tackling the interoperability ('aspect weaving') issue?  I'm
  Jim> planning on defining "Interlock metamodels" that will be used
  Jim> to join two disparate models together.  

I think that it won't be an issue with OIL, because the core semantics
won't change. All will always be service invocation. So the only
interoperability problems that we should have will be on the UI side. 

  Jim> Also, how does OIL store programs, 

Programs (services) are first class objects obtained with the `lambda'
service. They are stored like any other objects, currently in a text
file which stores the state of the machine when you quit the
interpretor. Very much like a Smalltalk interpretor. Bindings are also
saved by the UI, so that can use the same names.

  Jim> and how do you write compilers/translators for those programs?

You can't. Yet. But it would just be a matter of adding a builtin
service `body' to access the body of non-builtin services. You then do
anything you want with those bodies. But you won't be able to
dynamically compile programs this way, if that's what you asked. This
will be possible when reflexivity is achieved. You'll then be able to
do anything that you want with the implementation of the
interpretor. Including defining ways to compile services into native
machine code to improve performances. 

-- 
Laurent Martelli
martelli@iie.cnam.fr