www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Alternate string literal syntax (with mixins)?

reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
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 o=
f  =

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 =3D  { foo }  ~  { bar } ;
     str ~=3D "blah";
     if(...) {
       ...
     }
   }  MyCode;

    mixin(MyCode);
Feb 11 2007
next sibling parent reply Johan Granberg <lijat.meREM OVE.gmail.com> writes:
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)
Feb 11 2007
next sibling parent reply Johan Granberg <lijat.meREM OVE.gmail.com> writes:
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
Feb 11 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
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
Feb 11 2007
parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Sun, 11 Feb 2007 20:08:59 +0200, Andrei Alexandrescu (See Website For=
  =

Email) <SeeWebsiteForEmail 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 ma=








rks

 "". But because there is a starting mark and an ending mark, you ca=








n  =


 nest
 them. (And because they are used to mark a part of a file as a stri=








ng

 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 =3D  { foo }  ~  { bar } ;
      str ~=3D "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 coul=






d  =


 be
 tokenized and we could modify tokens instead of strings. (for a smal=






l

 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 righ=




t)  =


 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 becaus=


e  =


 code tends to not have three kinds of unbalanced parens at the same ti=


me  =


 :o).


 Andrei


Actually I was first considering a  { } syntax. Then I decided to add th=
e  =

second   (i.e.  { }  ) so that unbalanced curly bracets would be allowed=
  =

without escape sequencing them (e.g. \{ \} ). This allows one to constru=
ct  =

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 differen=
t  =

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).
Feb 11 2007
parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Kristian Kilpi wrote:

 On Sun, 11 Feb 2007 20:08:59 +0200, Andrei Alexandrescu (See Website For 
 Email) <SeeWebsiteForEmail 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
Feb 11 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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 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:









becomes:








  (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
Feb 11 2007
parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Mon, 12 Feb 2007 08:13:34 +0200, Bill Baxter  
<dnewsgroup 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 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:









 becomes:








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.
Feb 12 2007
prev sibling parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Sun, 11 Feb 2007 18:39:35 +0200, Johan Granberg  =

<lijat.meREM OVE.gmail.com> 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 par=




t  =


 of
 a source file as a string literal, just like /* */ marks a part of co=




de  =


 as
 a comment. For example:

    mixin(
       {
        //this is a string literal block
        if(...) {
          ...
        }
      } 
    );

 The  { }  marks have a close relation, of course, with quotation mark=




s  =


 "".
 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 li=




ke

 the "" literals are, if you get what I'm trying to say.)

 E.g.

    alias  {
      str =3D  { foo }  ~  { bar } ;
      str ~=3D "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 th=


e

 current syntax)



Sounds like a good idea. :) That would/could simplify things. Hmm, I'm  =

wondering if tuples could be used here?
Feb 11 2007
prev sibling next sibling parent janderson <askme me.com> writes:
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);


It's a good idea.  Whatever the symbols are, they should be nestable and 
should be generic so they can be used for normal strings.

-Joel
Feb 11 2007
prev sibling next sibling parent Xinok <xnknet gmail.com> writes:
Just throwing another suggestion out there for tokens, I personally like </ />.
I find them easier to type and easier to read without the need for an editor to
highlight them.



    alias </
      str = </ foo /> ~ </ bar />;
      str ~= "blah";
      if(...) {
        ...
      }
    /> MyCode;
 
     mixin(MyCode);
Feb 11 2007
prev sibling next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
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. 


Maybe, instead of special marks, we could use something like XML DOM's 
"innerXml":

void Somefunc()
{
//code here
}


auto code = SomeFunc.innerD;

The problem with this is that you can't use invented operators, since 
everything will have to be correct D code..

L.
Feb 12 2007
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
 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.


How about supporting the Unicode open and close quotation marks for this?


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


<snip>

I don't....

Stewart.
Feb 12 2007
parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Tue, 13 Feb 2007 05:05:14 +0200, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

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


 <snip>

 I don't....

 Stewart.


Well, I was thinking that there was a slight distinction between them. The  
"" literals being first class strings, and the  { }  literals being second  
class 'meta-like' strings. But, because both of them do ultimately the  
same thing, there is no actual distinction between them. So please ignore  
my earlier comment. ;)
Feb 13 2007
prev sibling next sibling parent reply janderson <askme me.com> writes:
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);


Just a thought what about keeping this in the same spirit of D's other 
string prefixes. ie

char[] string = l"


";

I do like the label idea suggested before:

Perhaps:

char[] string = :something"


":something;

Which would work with the  other postfixes:

char[] string = r:something"


"d:something;

And you could also choose not to label it:

char[] string = :"


":;

Best of all worlds.

-Joel
Feb 15 2007
parent reply janderson <askme me.com> writes:
janderson 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);


 
 Just a thought what about keeping this in the same spirit of D's other 
 string prefixes. ie
 
 char[] string = l"
 
 
 ";
 
 I do like the label idea suggested before:
 
 Perhaps:
 
 char[] string = :something"
 
 
 ":something;
 
 Which would work with the  other postfixes:
 
 char[] string = r:something"
 
 
 "d:something;
 
 And you could also choose not to label it:
 
 char[] string = :"
 
 
 ":;
 
 Best of all worlds.
 
 -Joel



Humm would be problomatic with ()?:

Well   or $ would be fine. I guess although it looks syntacticly ugly to me.

char[] string =  label"


" label;

-Joel
Feb 15 2007
parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Fri, 16 Feb 2007 07:54:01 +0200, janderson <askme me.com> wrote:


 janderson 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 pa=






rt  =


 of a source file as a string literal, just like /* */ marks a part o=






f  =


 code as a comment. For example:

   mixin(
      {
       //this is a string literal block
       if(..) {
         ...
       }
     } 
   );

 The  { }  marks have a close relation, of course, with quotation mar=






ks  =


 "". 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 =3D  { foo }  ~  { bar } ;
     str ~=3D "blah";
     if(...) {
       ...
     }
   }  MyCode;

    mixin(MyCode);


  Just a thought what about keeping this in the same spirit of D's oth=




er  =


 string prefixes. ie
  char[] string =3D l"
   ";
  I do like the label idea suggested before:
  Perhaps:
  char[] string =3D :something"
   ":something;
  Which would work with the  other postfixes:
  char[] string =3D r:something"
   "d:something;
  And you could also choose not to label it:
  char[] string =3D :"
   ":;
  Best of all worlds.
  -Joel



 Humm would be problomatic with ()?:

 Well   or $ would be fine. I guess although it looks syntacticly ugly =


to  =


 me.

 char[] string =3D  label"


 " label;

 -Joel


Well, one could use ::" ":: syntax which is not ambiguous. However, that=
's  =

a bit lengthy.

In addition, because the syntax contains quotation marks, editors will  =

treat the text between them as normal strings. Instead, it would be nice=
,  =

IMO, that (meta)code between the marks would be highlighted normally.

For example, if an editor highlights strings green, then in the followin=
g:

   import(::"
     //block A
     a =3D 1;
     s =3D "block B";
     //block C
     b =3D 2;
   "::);

the blocks A and C will be green but the block B won't. (That's an  =

opposite to the normal code.)
Feb 16 2007
parent janderson <askme me.com> writes:
Kristian Kilpi wrote:

 On Fri, 16 Feb 2007 07:54:01 +0200, janderson <askme me.com> wrote:
 

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


  Just a thought what about keeping this in the same spirit of D's 
 other string prefixes. ie
  char[] string = l"
   ";
  I do like the label idea suggested before:
  Perhaps:
  char[] string = :something"
   ":something;
  Which would work with the  other postfixes:
  char[] string = r:something"
   "d:something;
  And you could also choose not to label it:
  char[] string = :"
   ":;
  Best of all worlds.
  -Joel



 Humm would be problomatic with ()?:

 Well   or $ would be fine. I guess although it looks syntacticly ugly 
 to me.

 char[] string =  label"


 " label;

 -Joel


 
 Well, one could use ::" ":: syntax which is not ambiguous. However, 
 that's a bit lengthy.
 
 In addition, because the syntax contains quotation marks, editors will 
 treat the text between them as normal strings. Instead, it would be 
 nice, IMO, that (meta)code between the marks would be highlighted normally.


It's a nice idea, however if you do a partial bit of code inside the 
mixin, some IDE's will choke.  Maybe using {} in some form would be 
helpful, although I think many IDE's will still have issues.

ie mixin(  int A;
int
 

Ok the example is contrived, but I could imagine cases where you want to 
join string together.
Feb 16 2007
prev sibling parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Sun, 11 Feb 2007 17:55:39 +0200, Kristian Kilpi <kjkilpi gmail.com>  =

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 =3D  { foo }  ~  { bar } ;
      str ~=3D "blah";
      if(...) {
        ...
      }
    }  MyCode;

     mixin(MyCode);


I think the following would also be nice (in addition to other ideas  =

suggested in this thread):

   template MyTemplate() {...}

   alias  { ... }  MyAlias;

    {
     val =3D $MyTemplate!();

     str =3D $MyAlias;
   } 

And the string literal would be treaded by the compiler as:

    {
     val =3D }  ~ MyTemplate!() ~  {

     str =3D }  ~ MyAlias ~  {
   } 

(I.e. "val =3D " ~ MyTemplate!() ~ "str =3D " ~ MyAlias ~ "")

I use $ here, but   or some other (unambiguous) character could be used =
 =

instead, of course.


In addition, the compiler could convert numeric literals automatically t=
o  =

strings:

   const double v =3D 1.0;

   int MyFunc() { return 10; }

    { val =3D $MyFunc() + $v; } 

->

   " val =3D 10 + 1.0; "


I think the $ marks inside nested  { } s should not be converted. For  =

example:

   const int v =3D 1;

    {
     val =3D $v;

      {
       val2 =3D $v;
     } 
   } 

->

   "
     val =3D 1;

      {
       val2 =3D $v;
     } 
   "
 =
Feb 18 2007