Alternate string literal syntax (with mixins)?

[Andrei Alexandrescu (See Website For Email)]

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. (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.

And Perl programmers will love it. :o) Perl probably has the most 
comprehensive string notation capabilities, and it's very well thought out.


Andrei