Re: Re: SIDE NOTE: CIL Schema

quick partial reply -

On 18 Jan 2005, at 10:49, Alexander Genaud wrote:

> Martin, it seems to me that you intend MLML to be an
> intermediate language between any two tokenized (plain text) or
> XML languages. Such as: o:XML --> MLML --> Java. On the other
> hand, the philosophy behind SrcML seems to be Tool --> SrcML -->
> Java. Would you agree (at least superficially) with that?

That's one use, but I agree that language conversion has limited 
appeal. It is also fraught with difficulties.

Tool -> MLML (or SrcML) is more interesting, eg UML Models (XMI) -> 
MLML.
Other candidates for sources include WSDL, BPEL.
There's huge potential for fusion with XUL too.

MLML -> MLML processing also opens very interesting possibilities. 
Imagine
XMI -> MLML - [add get/set methods to types] > MLML -> XMI
as a very simple example of use that is completely agnostic to 
programming language.
AOSD instrumentation can be done with this type of transformations - 
Design by Contract can be very elegantly implemented this way (both 
partially documented in an earlier paper).

As Frank points out elsewhere, other end products such as 
documentation, stats etc are also important. Structured code formats 
have potential to deliver benefits on many fronts, which is why I'm 
trying to avoid pinning MLML down to a particular use or application. 
This I know leads to confusion and mixed messages - sorry!

o:XML -> MLML -> Java bytecode is in the cards, with some luck it's 
less than six months away.
Transforming to CIL would be v v nice - anyone know of good .Net 
bytecode generation tools?


regards,

/m