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

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=




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




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




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

represented a custom format that mixins was thought to handle? What =



 thingking is something like lisps quotes, then the escaped code coul=



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



 fraction of cases the string might be better but then we could have =



 current syntax)



  {.
 This is the tokens used in nemerle (if I understood their manual righ=


 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=

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

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

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)

{. 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: # 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
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: # 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.
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=


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


 as
 a comment. For example:

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

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


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


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

 thingking is something like lisps quotes, then the escaped code could =

 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=

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

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

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=



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



 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=



 "". 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);



 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 =

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

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