No, A @DSL annotation isn't nearly enough to take care of arbitrary DSLing, or arbitrary literals.
For example, let's try to use this for multi-line: @DSL(lang="longString") { """ I am a really really really long string. I'm also going to contain a bracket: } because I'm annoying like that.""" } tell me how the compiler could possibly sort this out? The only way is for the compiler to hand off the entire process of TOKENIZING this stream to the DSL provider for 'longString', which is an entirely different architecture - right now all java parsers do the fairly usual thing of tokenizing the whole deal, then tree-izing the whole thing, and only then starting the process of resolving 'DSL' into "java.lang.DSL" or whatever you had in mind. You'd have to create very specific rules about how the compiler can find the end of the DSL string. I've thought about this and have not been able to come up with a particularly sensible rule. The only one I can think of is to stick to C-esque rules: strings are things in double or single quotes, and use backslash internally for escapes, and braces are supposed to be matched. However, these restrictions already remove most other languages: You can't put python in there (multi-line strings will screw up java's parser), you can't put regular expressions in there (no rule enforcing matched quotes or braces). You can't put XML in there (no rule enforcing matched braces or quotes). No go. On Sep 2, 4:40 am, Casper Bang <casper.b...@gmail.com> wrote: > Don't know what happens underneath, but they appear to be parsed by > the production rule Block -> {Statement*} and have the Tree node > associated with a com.sun.tools.javac.code.Scope hashtable that's > special in that they can be nested. That would make sense I guess, > going the other way, a member-wide variable is also contained in a > Scope with nested Scopes (methods). That's why I think it would be > possible to allow an annotation type on a block. > > There are more things than just ARM you could want to do. > Transactions, logging, timing etc. As Stephen Colebourne has hinted at > in the past, one could even use it for DSL's: > > @DSL(lang="jpql", variant="hibernate"){ > SELECT FROM foobar; > > } > > That would take care of the need of multi-line strings for most cases. > > /Casper > > On 2 Sep., 03:12, Marcelo Fukushima <takesh...@gmail.com> wrote: > > > > > for local variables, javac actually does almost nothin:it only frees > > that local variable slot for a future local variable > > > theres a nice puzzle about that in the java specialists > > newsletter:http://www.javaspecialists.eu/archive/Issue173.html > > > of course youre not suppose to know its about local variables and > > javac before seeing the puzzle... > > > On Tue, Sep 1, 2009 at 9:44 PM, Mark Derricutt<m...@talios.com> wrote: > > > I've always been intrigued by these blocks we have in java, what does > > > javac > > > actually generate for them? I'd always hoped that the closures proposals > > > might just start small and make these blocks a first class citizen. > > > From: > > > public void test() { > > > int foo = 1; > > > { > > > int bar = foo + 2; > > > } > > > //MARK > > > } > > > to: > > > public void test() { > > > int foo = 1; > > > Method foobar = { > > > int bar = foo + 2; > > > } > > > foobar.invoke(null); > > > //MARK > > > } > > > *sigh* I want my closures and mixins. > > > -- > > > Pull me down under... > > > > Sent from Auckland, Auk, New Zealand > > > > On Wed, Sep 2, 2009 at 5:47 AM, Reinier Zwitserloot <reini...@gmail.com> > > > wrote: > > > >> You can put { (statements) } anywhere in java code where a statement > > >> is legal. Like any other occurrence of {} to delimit code, any > > >> variable declarations inside the {} are not visible outside the > > >> brackets. So, this: > > > --http://mapsdev.blogspot.com/ > > Marcelo Takeshi Fukushima --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---