Alternate string literal syntax (with mixins)?

[Kristian Kilpi]

On Mon, 12 Feb 2007 08:13:34 +0200, Bill Baxter  
<dnewsgroup at billbaxter.com> wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Kristian Kilpi wrote:
>>> On Sun, 11 Feb 2007 20:08:59 +0200, Andrei Alexandrescu (See Website  
>>> For Email) <SeeWebsiteForEmail at erdani.org> wrote:
>>>> Johan Granberg wrote:
>>>>> Johan Granberg wrote:
>>>>>
>>>>>> Kristian Kilpi wrote:
>>>>>>
>>>>>>> String literals with mixins are a bit awkward sometimes (editor
>>>>>>> highlighting etc).
>>>>>>>
>>>>>>> Some special marks -- I use @{ }@ here -- could be used to mark a  
>>>>>>> part of
>>>>>>> a source file as a string literal, just like /* */ marks a part of  
>>>>>>> code
>>>>>>> as a comment. For example:
>>>>>>>
>>>>>>>    mixin(
>>>>>>>      @{
>>>>>>>        //this is a string literal block
>>>>>>>        if(...) {
>>>>>>>          ...
>>>>>>>        }
>>>>>>>      }@
>>>>>>>    );
>>>>>>>
>>>>>>> The @{ }@ marks have a close relation, of course, with quotation  
>>>>>>> marks
>>>>>>> "". But because there is a starting mark and an ending mark, you  
>>>>>>> can nest
>>>>>>> them.
>
> I like these ideas.
> Here's another thought -- just let "mixin" be followed directly by a  
> string literal.
>
> Then this:
> #    mixin(
> #      @{
> #        //this is a string literal block
> #        if(...) {
> #          ...
> #        }
> #      }@
> #    );
>
> becomes:
> #    mixin@{
> #        //this is a string literal block
> #        if(...) {
> #          ...
> #        }
> #    }@;

That's a good idea. Getting rid of the parenthesis may not seem to be a  
big deal, but IMHO it makes the mixin syntax clearer and easier to read.


[snip]
> Maybe your string alias idea is enough for that.  I think the wisdom of  
> perl, though, is that if the token delimiting start-of-string is fixed,  
> then as soon as you start manipulating code that manipulates code, you  
> end up finding you want to embed that very token in a text literal, and  
> need to escape it.  Using nest-able symbols helps but doesn't solve the  
> problem if you want to have a literal "@{" without it's mate in the  
> block.  It's the same reason you wanted to have @{ }@,  so you could  
> nest { and } independantly.  The same need will arise for @{ and }@.
>
> Perl's solution ("here documents") is to make it possible to make unique  
> delimiters that are very much less likely to clash with anything in  
> arbitrary code fragments:
>
> <<"SomeUniqueStringICameUpWithToSignalTheEND";
> stuff here
> more "stuff"
>     whitespace is all significant
>     "quotes" don't matter
> SomeStringICameUpWithToSignalTheEND
>

Hm, I guess you're absolutely right. The syntax should be able to handle  
all the possible cases.

For example:

   @{:MyStringId
     if(...) {
       ...
     }
   }@:MyStringId

Hmm, this syntax is not fool proof, though. That is because colons belong  
to D's grammar ("? :" operator). So, the following, for example, should do  
the trick:

   @{@MyStringId
     if(...) {
       ...
     }
   @}@MyStringId


>
> It might also be nice to combine that with the import chunk idea so that  
> the label could be used to import the chunk:
>
>     import(SomeUniqueStringICameUpWithToSignalTheEND);
>
> --bb

Gets my vote.