OW2 Consortium
Search OW2 Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | asm List | November 2006 Index

<--  Date Index  --> <--  Thread Index  -->

Re: [asm] asm as a compiler?


> that wasn't ment to say to use Groovy instead of your meta language. I 
> suggested to produce Groovy code, evaluate it using Groovy and then use 
> the resulting class as a class of your MetaLanguage. You would still 
> have to write a parser/lexer then. I thought that was the way you wanted 
> to got when using Java, or not?

I have a parser/lexer for my own concrete syntax, but from there on, I
apparently haven't made my idea clear enough.

So please read on...

> as long as all of your meta language is expressable in Java... That most 
> possibly means your language must be static typed and other things. And 
> of course... ever thought what you do about compiletime errors? You will 
> hae to make semantic checks oin the expressions written in your 
> metalanguage to ensure this can't happen.

Not exactly like this. Read on...

> > - the users of the metalanguage can understand and debug the generated
> > java sources
> 
> if you don't write the files to the filesystem, then not.... They will 
> do that for debugging then?

A general answer to mostly everything above: no, I didn't mean that :-)

Okay, maybe I need to explain my language more. This explanation is an
oversimplification, but in this context the language can be understood as
a template language for producing (e.g.) java sources. So the language
doesn't need to resemble java any more than JSP or Velocity have to
resemble HTML.

Of course we need to be careful with the term template, because 99% of the
time the term concerns _string_ generation.

Ngrease (that's the name of my language; maybe it's easier from now on to
use the name, although I'm not yet ready to "market" the project more (see
sourceforge if you are interested) :-) transforms stuff that could be
regarded as Abstract Syntax Trees, not just strings.

So the usage scenario I'm most interested in so far (until ngrease is
mature enough to be used for images, sounds, documents etc) is to take an
AST of some high level of abstraction (= a high level language with its
own abstract syntax and ngrease's concrete syntax) and transform it into
an AST on the java source code level (java class definitions inside
packages inside source directories inside projects inside a workspace),
from which it is straightforward to produce an AST on the filesystem level
(files inside directories inside directories).

This is where the actual functional ngrease part ends, and the resulting
"lowest possible level AST" can be output according to the command-line
and to the "type" (the symbol of the root node) of the AST.

In the java case, the filesystem level AST can be written either to stdout
(as a tar stream, for example) or directly to the disk as a directory
structure. And then published to the client.

And this is where we have the motive for my question: it feels somewhat
stupid to generate the class files as a separate phase on the file level,
because everything else can be done on the AST level.

I've worked on this for several years so it's quite difficult to determine
what is essential in (and perhaps unique to) this project and worth
explaining in this context, so I hope I made myself clear enough this time
:-)

> Maybe you should take a look at the eclipse compiler. It is possible to 
> use it outside eclipse and I think it can be used/extended to write the 
> bytecode not to files. But I never took a close look at it, it is just a 
> guess. And of course that compiler is complex and big.

Yes, I also found it when googling, but somehow the ASM way would feel
better if it's practical. The eclipse compiler is bound to come with an
eclipse workspace view of the world. I don't need workspaces, projects and
concepts like that here, I just need an sources and classes -> classes
filter.

- Ville Oikarinen



<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 2006-2007, OW2 Consortium | contact | webmaster.