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
-~----------~----~----~----~------~----~------~--~---
