Alternate string literal syntax (with mixins)?

[Bill Baxter]

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(...) {
#          ...
#        }
#    }@;


  (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);

I like this too.

Related but somewhat different would be the concept of importing chunks 
from the /current/ file.
Now with import("foo.txt") we can import the entire contents of an 
arbitrary file as a string, but that introduces some distance between 
the content and where it is used.  Sometimes you want locality.  Say 
I've got a little 5-line shader program that I'm using.  In c++ I'll 
often start out putting it in the same file near the point of use with 
an embedded string.  Despite code in strings being kind of a pain to 
work with, it's still less annoying than going back and forth between 
two files to make sure I keep the parameter names in the C++ file in 
sync with shader code as I tweak things.

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


I don't care what the syntax is, but if I'm going to be manipulating 
lots of quoted code, I want something like Perl's here documents, so 
that I can paste anything I want in between the start and end markers 
and know that it'll just work (with 1-epsilon probability).

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