Mail Archive Home | asm List | November 2006 Index
| <-- Date Index --> | <-- Thread Index --> |
> 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 --> |
Powered by MHonArc.
Copyright © 2006-2007, OW2 Consortium | contact | webmaster.