Re: CLI - MLML

Thanks for the links Alex, interesting stuff

> http://research.microsoft.com/Comega/

There are some immediate similarities with o:XML concepts, for example  
how function calls are mapped over object sets that are selected with  
XPath-ish expressions. Of course I prefer the full XPath expressions of  
o:XML, with axis and predicates, to the Cw way of overloading the  
dot-operator :)
As a language it seems very keyword-heavy, which is a limitation of  
'traditional' programming languages, but it has some nice, innovative  
ideas. Static typing means that XPath-style and SQL-style expressions  
are much harder to integrate, and is probably the reason they've not  
done a more complete XPath.

> The advantage of MLML,
> as I see it, is to achieve language independance so that
> UML, documentation, compilation, runtime, and development
> tools can interact more seemlessly without lock-in.

Yes, definitely. Many tools could be developed for 'generic' MLML and  
used across any number of languages.
For example, a documentation tool operating on MLML could be as simple  
as an XSL stylesheet producing HTML. Deriving all necessary information  
from the MLML structure, it can be agnostic to what source language was  
used.
A new breed of tools would also be possible, for example transforming  
from dynamic to statically typed function calls according to specific  
semantic rules.

> Mapping Java and o:xml via MLML is a very good start. However,
> The Common Language Infrastructure (CLI) already maps to a
> common base for a greater number of languages, ...

Code integration is _one_ use of MLML, but not the primary one (in  
spite of what my last mail may have sounded like!).
CLI probably does code integration much better, and provides a  
comprehensive, portable execution environment. But the CIL (Common  
Intermediate Language) is a language-independent bytecode, rather than  
a source-code representation. That is, regardless of source language,  
the source code has to first be compiled to the CIL instruction set.
The operations you can do on a low-level instruction set are quite  
limited, compared to what you can do (meta-programming etc) on a  
higher-level, effectively source-level, representation.

I'd not heard of SrcML before so I googled it and found:
http://bach.informatik.uni-ulm.de/srcml/wiki/index.php/SrcMLWiki: 
Overview

 From the overview there are many goals that are shared with MLML, which  
I think highlights the difference with CLI.
CLI would however make a great code target for an MLML code compiler!

> I believe MLML has to consider those factors to
> avoid obselences before it is born. It might be
> best to consider the ECMA CLI over Java.
> Writing an XML schema for (a subset of?) CLI
> code might be a good next step for MLML?:

You mean a schema for the CIL - or for the CLI types?
The CLI spec comes with type definitions in what looks like a bespoke  
XML format. Should be easy-ish to XSL transform these into something  
that looks more like MLML.
Java has the advantage of being, these days, a mature, accepted  
platform. CLI is worth keeping an eye on, but until there's mainstream  
VMs available (are there any?) there's not much point in writing a  
compiler-backend to generate CLI code from MLML, or o:XML.

Another interesting possibility is to incorporate CLI types directly  
into o:XML, possibly as an external library.


/m


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________