> 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.
Oh sure, I should had mentioned explicitly how this obviously won't work with a vanilla javac. Anyway here's the original post I was referring: http://www.jroller.com/scolebourne/entry/enhancing_java_multi_lingual_blocks > 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. Well it's not a trivial issue no, but this is how it work in Fan: http://fandev.org/sidewalk/topic/438 /Casper --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
