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.

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.

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

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

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

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

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.

For example, if an editor highlights strings green, then in the following:

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

the blocks A and C will be green but the block B won't. (That's an opposite to the normal code.)

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.

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 = @{ foo }@ ~ @{ bar }@;
>      str ~= "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 = $MyTemplate!();

    str = $MyAlias;
  }@

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

  @{
    val = }@ ~ MyTemplate!() ~ @{

    str = }@ ~ MyAlias ~ @{
  }@

(I.e. "val = " ~ MyTemplate!() ~ "str = " ~ 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 to strings:

  const double v = 1.0;

  int MyFunc() { return 10; }

  @{ val = $MyFunc() + $v; }@

->

  " val = 10 + 1.0; "


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

  const int v = 1;

  @{
    val = $v;

    @{
      val2 = $v;
    }@
  }@

->

  "
    val = 1;

    @{
      val2 = $v;
    }@
  "