Alternate string literal syntax (with mixins)?

[Kristian Kilpi]

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. (And because they are used to mark a part of a file as a string
>>>> literal, they are not actually the part of the 'working code' just  
>>>> like
>>>> the "" literals are, if you get what I'm trying to say.)
>>>>
>>>> E.g.
>>>>
>>>>    alias @{
>>>>      str = @{ foo }@ ~ @{ bar }@;
>>>>      str ~= "blah";
>>>>      if(...) {
>>>>        ...
>>>>      }
>>>>    }@ MyCode;
>>>>
>>>>     mixin(MyCode);
>>> Wouldn't it be a better solution if the escape syntax you described
>>> represented a custom format that mixins was thought to handle? What I'm
>>> thingking is something like lisps quotes, then the escaped code could  
>>> be
>>> tokenized and we could modify tokens instead of strings. (for a small
>>> fraction of cases the string might be better but then we could have the
>>> current syntax)
>>  While I'm at it I might suggest using <[ and ]> as tokens instead of  
>> @{.
>> This is the tokens used in nemerle (if I understood their manual right)  
>> and
>> it is unnecessary to use a different token just because.   
>> http://nemerle.org/Syntax_extensions
>
> Probably best is to use one group of symbols that nest naturally (e.g.  
> [] or () or {}) and prefix them with something that unambiguously  
> denotes a string:
>
> alias ${
>    ... anything with balanced {}'s ...
>    ... or with unbalanced \{ and \}'s ...
> } MyCode;
>
> or:
>
> alias $(
>    ... anything with balanced ()'s ...
>    ... or with unbalanced \( and \)'s ...
> ) MyCode;
>
> or:
>
> alias $[
>    ... anything with balanced []'s ...
>    ... or with unbalanced \[ and \]'s ...
> ] MyCode;
>
> This should reasonably cover applications elegantly, especially because  
> code tends to not have three kinds of unbalanced parens at the same time  
> :o).
>
>
> Andrei

Actually I was first considering a @{ } syntax. Then I decided to add the  
second @ (i.e. @{ }@ ) so that unbalanced curly bracets would be allowed  
without escape sequencing them (e.g. \{ \} ). This allows one to construct  
strings from smaller parts containing unbalanced parens that would  
otherwise be balanced, e.g.:

   @{ if(...) { }@ ~ Block!() ~ @{ } }@
->
   " if(...) { " ~ Block!() ~ " } "

Well, a syntax with only one @ (or $) looks nicer though.

The second thing I was considering (with the @{ } syntax) was a different  
way to create user defined string literals, e.g.:

   @MyCode {
     ...
   }

   mixin(@MyCode);

User defined literals would then belong to their own unique namespace  
(@MyCode versus MyCode), which could be nice (or not).