"Walter" <walter digitalmars.com> writes:

Currently, there are 3 kinds of string literals:
'string' : wysiwyg strings
"string" : escaped strings
\ : single character strings

There is no character literal syntax; 1 character long strings are
implicitly converted to character literals based on context. Unfortunately,
this leads to ambiguities with no reasonable way out (other than crafting
arbitrary and confusing rules).

So, I've been thinking of going back to the C way and having ' ' for
character literals. That means that wysiwyg strings are left without a
lexical syntax. Any ideas for something that would look nice? How about
using back quotes ` `, or is that just too hard to distinguish in certain
fonts? One thing to keep in mind is that wysiwyg strings are not going to be
used with nearly the same frequency as escaped strings, so the syntax can be
a bit less convenient for them.

I'd like to use /string/, but that leads to too may lexical ambiguities.

Some possibilities are:
1) prefixing the " with a letter or a character, as in:
    W"string"
    %"string"
    !"string"
2) using a character not used in C, such as:
    `string`
    $string$
     string 
    #string

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

What about double double quotes for wysiwyg?

""string"" : wysiwyg string

I don't really like that syntax, but I think it's better than any of the 
other alternatives proposed so far.  I like the fact that it uses a 
quote character to denote a string, rather than some other, arbitrarily 
selected character.

Walter wrote:
 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings
 
 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context. Unfortunately,
 this leads to ambiguities with no reasonable way out (other than crafting
 arbitrary and confusing rules).
 
 So, I've been thinking of going back to the C way and having ' ' for
 character literals. That means that wysiwyg strings are left without a
 lexical syntax. Any ideas for something that would look nice? How about
 using back quotes ` `, or is that just too hard to distinguish in certain
 fonts? One thing to keep in mind is that wysiwyg strings are not going to be
 used with nearly the same frequency as escaped strings, so the syntax can be
 a bit less convenient for them.
 
 I'd like to use /string/, but that leads to too may lexical ambiguities.
 
 Some possibilities are:
 1) prefixing the " with a letter or a character, as in:
     W"string"
     %"string"
     !"string"
 2) using a character not used in C, such as:
     `string`
     $string$
      string 
     #string
 
 

"Walter" <walter digitalmars.com> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:bfuc2b$5ck$1 digitaldaemon.com...
 What about double double quotes for wysiwyg?

 ""string"" : wysiwyg string

 I don't really like that syntax, but I think it's better than any of the
 other alternatives proposed so far.  I like the fact that it uses a
 quote character to denote a string, rather than some other, arbitrarily
 selected character.

It's a good idea, but it conflicts with using "" to denote an empty string.
I thought of using "'string'", but it looks too weird <g>.

"Sean L. Palmer" <palmer.sean verizon.net> writes:

I thought of that too, but it conflicts with '"' and "'".

What about '' (two single quotes)?

'c' // char
''string''  // wysiwyg string
"string"  // escaped string

I wouldn't be opposed to backquotes, either.

`string`

or

``string``

Unicode has some nice quotes too.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bfucor$64l$1 digitaldaemon.com...
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:bfuc2b$5ck$1 digitaldaemon.com...
 What about double double quotes for wysiwyg?

 ""string"" : wysiwyg string

 I don't really like that syntax, but I think it's better than any of the
 other alternatives proposed so far.  I like the fact that it uses a
 quote character to denote a string, rather than some other, arbitrarily
 selected character.

 It's a good idea, but it conflicts with using "" to denote an empty

string.
 I thought of using "'string'", but it looks too weird <g>.

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bfunju$g8e$1 digitaldaemon.com...
 What about '' (two single quotes)?

 'c' // char
 ''string''  // wysiwyg string
 "string"  // escaped string

In a proportional font, they are nearly indistinguishable.

 I wouldn't be opposed to backquotes, either.

 `string`

 or

 ``string``

Probably ` is the current leading contender.

 Unicode has some nice quotes too.

I want to use something on a regular keyboard <g>.

Ilya Minkov <midiclub 8ung.at> writes:

Walter wrote:
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bfunju$g8e$1 digitaldaemon.com...
 
What about '' (two single quotes)?

'c' // char
''string''  // wysiwyg string
"string"  // escaped string

 
 
 In a proportional font, they are nearly indistinguishable.

I think Python uses something like triple double quotes for something.

"""This is a docstring or a preformatted string, IIRC."""

-i.

Chris Lawson <cl nospamhere.tinfoilhat.ca> writes:

Ilya Minkov wrote:
 Walter wrote:
 
 In a proportional font, they are nearly indistinguishable.

 
 
 I think Python uses something like triple double quotes for something.
 
 """This is a docstring or a preformatted string, IIRC."""

Preformatted.

foo = """
here the \n's
are maintained.
"""

There are some formatting options as well with them (%s etc)

 
 -i.
 

Andy Friesen <andy ikagames.com> writes:

Walter wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:bfuc2b$5ck$1 digitaldaemon.com...
 
What about double double quotes for wysiwyg?

""string"" : wysiwyg string

I don't really like that syntax, but I think it's better than any of the
other alternatives proposed so far.  I like the fact that it uses a
quote character to denote a string, rather than some other, arbitrarily
selected character.

 
 
 It's a good idea, but it conflicts with using "" to denote an empty string.
 I thought of using "'string'", but it looks too weird <g>.
 

Python uses r"string" for raw (wysiwyg) strings.


anywhere else in the language. (as far as I know)

Patrick Down <pat codemoon.com> writes:

"Walter" <walter digitalmars.com> wrote in
news:bfu9kp$3f1$1 digitaldaemon.com: 

 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings
 
 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context.
 Unfortunately, this leads to ambiguities with no reasonable way out
 (other than crafting arbitrary and confusing rules).
 
 So, I've been thinking of going back to the C way and having ' ' for
 character literals. That means that wysiwyg strings are left without a
 lexical syntax. Any ideas for something that would look nice? How
 about using back quotes ` `, or is that just too hard to distinguish
 in certain fonts? One thing to keep in mind is that wysiwyg strings
 are not going to be used with nearly the same frequency as escaped
 strings, so the syntax can be a bit less convenient for them.
 
 I'd like to use /string/, but that leads to too may lexical
 ambiguities. 
 
 Some possibilities are:
 1) prefixing the " with a letter or a character, as in:
     W"string"
     %"string"
     !"string"

These are ok.

 2) using a character not used in C, such as:
     `string`
     $string$
      string 
     #string

I think you should reserve these symbols for
other things.

Python uses """ for multi line strings.  I find it
useful.

a="""
Line 1
Line 2
"""

"Walter" <walter digitalmars.com> writes:

"Patrick Down" <pat codemoon.com> wrote in message
news:Xns93C480D51FA3Dpatcodemooncom 63.105.9.61...
 Python uses """ for multi line strings.  I find it
 useful.

 a="""
 Line 1
 Line 2
 """

That will work. But an empty string would be """""". Hmm. How about perhaps
two single quotes, as in ''f''? Sadly, in a proportional font, it looks just
like "f".

"Fabian Giesen" <rygNO SPAMgmx.net> writes:

 That will work. But an empty string would be """""". Hmm. How about

Yeah, but as there is absolutely no point in using the WYSIWYG syntax
for empty strings, I doubt this will have any practical problems :)

-fg

"Walter" <walter digitalmars.com> writes:

"Fabian Giesen" <rygNO SPAMgmx.net> wrote in message
news:bg05b6$1tnm$1 digitaldaemon.com...
 That will work. But an empty string would be """""". Hmm. How about

 Yeah, but as there is absolutely no point in using the WYSIWYG syntax
 for empty strings, I doubt this will have any practical problems :)

You do have a point.

Ilya Minkov <midiclub 8ung.at> writes:

Walter wrote:
 Some possibilities are:
 2) using a character not used in C, such as:
     `string`
     $string$
      string 
     #string

Using these ugly chacacters seems somewhat... ugly to me. Vote Against.

 1) prefixing the " with a letter or a character, as in:
     W"string"
     %"string"
     !"string"

Why do you want to prefix wysisyg strings? You may also prefix a string 
which is to mean character literal - which seems to make more sense to me.

W"" looks too much like wide-something.

Using % would prohibit overloading % as an operator where string is a 
second parameter. I consider ir useful as a formatting operator or somesuch.

! seems to be OK since it's a unary opertor anyway, and as such cannot 
be overloaded for a built-in types.

-i.

"DeadCow" <deadcow-remove-this free.fr> writes:

what about a perl-like quotation ?

s (for string?) followed by any character as delimiter.

s/.../

s%...%
s!...!

So you can choose the delimiter to avoid escaping.

ok it's a bit ugly.
can the lexer handle this kind of backward reference ?

-- Nicolas Repiquet

"Walter" <walter digitalmars.com> writes:

"DeadCow" <deadcow-remove-this free.fr> wrote in message
news:bfuit9$bnr$1 digitaldaemon.com...
 what about a perl-like quotation ?

 s (for string?) followed by any character as delimiter.

 s/.../

 s%...%
 s!...!

 So you can choose the delimiter to avoid escaping.

 ok it's a bit ugly.

<g>

 can the lexer handle this kind of backward reference ?

Yes.

"Walter" <walter digitalmars.com> writes:

"Walter" <walter digitalmars.com> wrote in message
news:bfussh$kiq$1 digitaldaemon.com...
 "DeadCow" <deadcow-remove-this free.fr> wrote in message
 news:bfuit9$bnr$1 digitaldaemon.com...
 what about a perl-like quotation ?

 s (for string?) followed by any character as delimiter.

 s/.../

 s%...%
 s!...!

 So you can choose the delimiter to avoid escaping.

 ok it's a bit ugly.

 <g>

 can the lexer handle this kind of backward reference ?

 Yes.

My mistake, no it can't. s% would tokenize ambiguously.

"Luna Kid" <lunakid neuropolis.org> writes:

"More spectacularly" distinguishing char literals from string
literals, in that they won't be surrounded by delimiters but
just prefixed with something, may also be a good solution.
(Char literals, after all, are totally different animals than
string literals in many ways.) Then some prefix char and some
simple rules to allow various (unambiguous) representations
of a char need to be defined.

Sz.


"Walter" <walter digitalmars.com> wrote in message
news:bfu9kp$3f1$1 digitaldaemon.com...
 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings

 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context. Unfortunately,
 this leads to ambiguities with no reasonable way out (other than crafting
 arbitrary and confusing rules).

 So, I've been thinking of going back to the C way and having ' ' for
 character literals. That means that wysiwyg strings are left without a
 lexical syntax. Any ideas for something that would look nice? How about
 using back quotes ` `, or is that just too hard to distinguish in certain
 fonts? One thing to keep in mind is that wysiwyg strings are not going to be
 used with nearly the same frequency as escaped strings, so the syntax can be
 a bit less convenient for them.

 I'd like to use /string/, but that leads to too may lexical ambiguities.

 Some possibilities are:
 1) prefixing the " with a letter or a character, as in:
     W"string"
     %"string"
     !"string"
 2) using a character not used in C, such as:
     `string`
     $string$
      string 
     #string

"Luna Kid" <lunakid neuropolis.org> writes:

 simple rules to allow various (unambiguous) representations
 of a char need to be defined.

Umm, those rules are already defined as EscapeSequence. :)

So, how about this?

Strings:

    'verbatim, as before'

    "escaped,\x20as\x20before"

Chars:

    #c    <-- letter 'c'





Sz.

"Walter" <walter digitalmars.com> writes:

"Luna Kid" <lunakid neuropolis.org> wrote in message
news:bfuqr0$irj$1 digitaldaemon.com...
 simple rules to allow various (unambiguous) representations
 of a char need to be defined.

 Umm, those rules are already defined as EscapeSequence. :)

 So, how about this?

 Strings:

     'verbatim, as before'

     "escaped,\x20as\x20before"

 Chars:

     #c    <-- letter 'c'






source through a C preprocessor first!

"Luna Kid" <lunakid neuropolis.org> writes:

 Strings:

     'verbatim, as before'

     "escaped,\x20as\x20before"

 Chars:

     #c    <-- letter 'c'






 source through a C preprocessor first!

I see.

Well, for me, any other prefix would do, if not too
obscure (should be easy to type).

  perhaps? (Familiar to the fingers from emails. ;) )

Sz.

John Reimer <jjreimer telus.net> writes:

I like backquotes:

`string`

I don't think it's too confusing.

"Matthew Wilson" <matthew stlsoft.org> writes:

Make that 3 then. :)

"John Reimer" <jjreimer telus.net> wrote in message
news:bfur97$ieh$1 digitaldaemon.com...
 I like backquotes:

 `string`

 I don't think it's too confusing.

Ilya Minkov <midiclub 8ung.at> writes:

The difference to single quotes is hardly noticable if you have a 160dpi 
display and space is tight. :) Like, my main programming machine is a 
high-performace handheld notebook with a *really* tiny display. :) You 
can guess that i don't have sausage-like fingers. :)

The backquote is better left for something, which cannot be easily 
confused with strings.

Better a sane prefix (like Burton's r -- whatever it means it looks 
good) or """ """.

-i.

John Reimer wrote:
 I like backquotes:
 
 `string`
 
 I don't think it's too confusing.
 

John Reimer <jjreimer telus.net> writes:

Ilya Minkov wrote:

 The difference to single quotes is hardly noticable if you have a 160dpi 
 display and space is tight. :) Like, my main programming machine is a 
 high-performace handheld notebook with a *really* tiny display. :) You 
 can guess that i don't have sausage-like fingers. :)
 
 The backquote is better left for something, which cannot be easily 
 confused with strings.
 
 Better a sane prefix (like Burton's r -- whatever it means it looks 
 good) or """ """.
 

What's sane? That's subjective ;-).

I like `string` because it's simple, clean, and easy.  The other ways 
look ugly, I think.  Not everybody uses a nasty, cramped laptop :-).

With all those syntax highlighting text editors out there, I don't think 
it's much of a problem setting special colours for the string to make it 
more obvious for those with small/dense displays, no?

Later,

John

"Matthew Wilson" <matthew stlsoft.org> writes:

 With all those syntax highlighting text editors out there, I don't think
 it's much of a problem setting special colours for the string to make it
 more obvious for those with small/dense displays, no?

Excellent point

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bg02ei$1qsh$1 digitaldaemon.com...
 With all those syntax highlighting text editors out there, I don't think
 it's much of a problem setting special colours for the string to make it
 more obvious for those with small/dense displays, no?

 Excellent point

But when people write books on D, they'll be using monochrome text. Most
people still use monochrome printers to print source code.

"Sean L. Palmer" <palmer.sean verizon.net> writes:

You can still use a different font, or make them bold, or italicized, or
something.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bg0uo4$2nkk$3 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bg02ei$1qsh$1 digitaldaemon.com...
 With all those syntax highlighting text editors out there, I don't



think
 it's much of a problem setting special colours for the string to make



it
 more obvious for those with small/dense displays, no?

 Excellent point

 But when people write books on D, they'll be using monochrome text. Most
 people still use monochrome printers to print source code.

Ilya Minkov <midiclub 8ung.at> writes:

Sean L. Palmer wrote:

But when people write books on D, they'll be using monochrome text. Most
people still use monochrome printers to print source code.


Go figure out whether this tiny thing is bold, or maybe italics? Serif 
or Sans-Serif? It's next to impossible. Besides, there are so few usable 
formatting styles that they are better used for something else. Unless 
you want yOUR cODE tO lOOK lIKE mADMAN,S pARTY iNVITATION fLYER! :)

-i.

John Reimer <jjreimer telus.net> writes:

Walter wrote:
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bg02ei$1qsh$1 digitaldaemon.com...
 
With all those syntax highlighting text editors out there, I don't think
it's much of a problem setting special colours for the string to make it
more obvious for those with small/dense displays, no?

Excellent point

 
 
 But when people write books on D, they'll be using monochrome text. Most
 people still use monochrome printers to print source code.
 
 

Ok, counter to counter argument coming up... :-)

But when people write books, they seem to still use visual aids of 
different kinds to amplify what that code means -- like a switch in font 
or a bold face or something.  They could always do something like that. 
  People are creative when they need to be :-).  People overcome 
problems and that one seems to be a minor one. We just have to know if 
the problems outweigh the benefits.

The greatest argument against `string` to me would perhaps be the 
"cultural" one or the fact that it's a none-standard/unusual character.

I still vote for it, but I understand the drawbacks people see in it.  I 
still don't think the fact that it may be hard to render on monochrome 
cell phones is a strong argument against it.  At that point, there would 
be other characters that would be hard to see anyway.

Later,

John

Ilya Minkov <midiclub 8ung.at> writes:

John Reimer wrote:

 With all those syntax highlighting text editors out there, I don't think 
 it's much of a problem setting special colours for the string to make it 
 more obvious for those with small/dense displays, no?

Legible colors use up very fast. They are simply too few. And when 
working in the sun, one can hardly distinguish even those. Besides, 
there must be someone with monochrome displays, no? Like, some people 
use an old 486-based Nokia organiser& cell phone, IIRC it's monochrome.

-i.

"Walter" <walter digitalmars.com> writes:

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bg0vsn$2opm$1 digitaldaemon.com...
 Legible colors use up very fast. They are simply too few. And when
 working in the sun, one can hardly distinguish even those. Besides,
 there must be someone with monochrome displays, no? Like, some people
 use an old 486-based Nokia organiser& cell phone, IIRC it's monochrome.

While I agree that working in monochrome is an important issue (heck, *I*
work in monochrome, longtime habits die really, really hard!), I just can't
see anyone writing programs on their cell phone!

Ilya Minkov <midiclub 8ung.at> writes:

Walter wrote:
 While I agree that working in monochrome is an important issue (heck, *I*
 work in monochrome, longtime habits die really, really hard!), I just can't
 see anyone writing programs on their cell phone!

One friend of mine tried to debug my piece of C code using it, as he was 
in their "summer house" in northern finnland. It was midst in winter, 
they had very little electricity, so this thing was the only choice. 
They let the generator run a couple of hours a day. But my notebook 
comes quite close to it in size. :) That old nokia phone is much larger 
than usual, and about the size of a typical old Windows CE handheld and 
half the length of my notebook.

-i.

Burton Radons <loth users.sourceforge.net> writes:

Walter wrote:
 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings
 
 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context. Unfortunately,
 this leads to ambiguities with no reasonable way out (other than crafting
 arbitrary and confusing rules).
 
 So, I've been thinking of going back to the C way and having ' ' for
 character literals. That means that wysiwyg strings are left without a
 lexical syntax. Any ideas for something that would look nice? How about
 using back quotes ` `, or is that just too hard to distinguish in certain
 fonts? One thing to keep in mind is that wysiwyg strings are not going to be
 used with nearly the same frequency as escaped strings, so the syntax can be
 a bit less convenient for them.

I like r"string", which is used in a number of languages already.

"Walter" <walter digitalmars.com> writes:

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bfusdh$k5e$1 digitaldaemon.com...
 I like r"string", which is used in a number of languages already.

Which ones?

Burton Radons <loth users.sourceforge.net> writes:

Walter wrote:
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:bfusdh$k5e$1 digitaldaemon.com...
 
I like r"string", which is used in a number of languages already.

 
 
 Which ones?

I can only find Python right now, but I've seen it used in some other 
languages, prototypes exclusively I think (Xana is one).

I don't think the problem really exists.  There's no reason to have 
single-character variants of functions like string.find; if the benefits 
to such a search is significant, then the cost of matching a check and 
running a special loop is insignificant.  I have never had the problem 
come up outside of calling string module functions.

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

(grin) Php uses this ?>   <? to "quote" literal HTML.  It would look a 
little odd in D, though.

I was about to send this as a joke, but it occurs to me, especially if 
we plan to sometimes embed D in HTML, that HTML tags aren't necessarily 
a bad idea.  What about:

<wysiwyg>string</wysiwyg>

????

Burton Radons wrote:
 Walter wrote:
 
 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings

 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context. 
 Unfortunately,
 this leads to ambiguities with no reasonable way out (other than crafting
 arbitrary and confusing rules).

 So, I've been thinking of going back to the C way and having ' ' for
 character literals. That means that wysiwyg strings are left without a
 lexical syntax. Any ideas for something that would look nice? How about
 using back quotes ` `, or is that just too hard to distinguish in certain
 fonts? One thing to keep in mind is that wysiwyg strings are not going 
 to be
 used with nearly the same frequency as escaped strings, so the syntax 
 can be
 a bit less convenient for them.

 
 
 I like r"string", which is used in a number of languages already.
 

"Vathix" <vathix dprogramming.com> writes:

 I like r"string", which is used in a number of languages already.

I've finally decided I vote for this one.

"J. Daniel Smith" <J_Daniel_Smith HoTMaiL.com> writes:

   Dan

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bfusdh$k5e$1 digitaldaemon.com...
 Walter wrote:
 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings

 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context.


Unfortunately,
 this leads to ambiguities with no reasonable way out (other than


crafting
 arbitrary and confusing rules).

 So, I've been thinking of going back to the C way and having ' ' for
 character literals. That means that wysiwyg strings are left without a
 lexical syntax. Any ideas for something that would look nice? How about
 using back quotes ` `, or is that just too hard to distinguish in


certain
 fonts? One thing to keep in mind is that wysiwyg strings are not going


to be
 used with nearly the same frequency as escaped strings, so the syntax


can be
 a bit less convenient for them.

 I like r"string", which is used in a number of languages already.

"Matthew Wilson" <matthew stlsoft.org> writes:

 1) prefixing the " with a letter or a character, as in:
     W"string"
     %"string"

Neither of these attract me. The % will be confusing with printf() format
strings. The W ... just don't like it.

     !"string"

Definitely not. !"message string" is useful in asserts in C++. I've not
given it any thought, but it seems that this could/would similarly in D.

 2) using a character not used in C, such as:
     `string`

I like this, but probably in a minority of 1 (or 2)

     $string$
      string 
     #string

Hate all of these.


Here's an unpopular thought: why not use  "string" and be consistent with

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bfv0or$oeh$2 digitaldaemon.com...
 Here's an unpopular thought: why not use  "string" and be consistent with


It's aesthetically unpleasing.

"Matthew Wilson" <matthew stlsoft.org> writes:

LOL. What isn't? :)

"Walter" <walter digitalmars.com> wrote in message
news:bfv2s8$ql4$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bfv0or$oeh$2 digitaldaemon.com...
 Here's an unpopular thought: why not use  "string" and be consistent


with


 It's aesthetically unpleasing.

"Walter" <walter digitalmars.com> writes:

That's what I'm trying to find!

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bfv9m8$118q$1 digitaldaemon.com...
 LOL. What isn't? :)

 "Walter" <walter digitalmars.com> wrote in message
 news:bfv2s8$ql4$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bfv0or$oeh$2 digitaldaemon.com...
 Here's an unpopular thought: why not use  "string" and be consistent


 with


 It's aesthetically unpleasing.

"Matthew Wilson" <matthew stlsoft.org> writes:

`string`

"Walter" <walter digitalmars.com> wrote in message
news:bfvihp$19sq$1 digitaldaemon.com...
 That's what I'm trying to find!

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bfv9m8$118q$1 digitaldaemon.com...
 LOL. What isn't? :)

 "Walter" <walter digitalmars.com> wrote in message
 news:bfv2s8$ql4$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bfv0or$oeh$2 digitaldaemon.com...
 Here's an unpopular thought: why not use  "string" and be consistent


 with


 It's aesthetically unpleasing.

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bg02ej$1qsh$2 digitaldaemon.com...
 `string`

The three frontrunners are at the moment:

`string`
"""string"""
r"string"

"Matthew Wilson" <matthew stlsoft.org> writes:

 `string`
 """string"""

Instinct tells me that this is a parsing nightmare, no?

 r"string"

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bg29h0$12sg$1 digitaldaemon.com...
 `string`
 """string"""

 Instinct tells me that this is a parsing nightmare, no?

Not that bad, actually. The clunky ones are the arbitrary lookahead
problems.

Mark T <Mark_member pathlink.com> writes:

The three frontrunners are at the moment:

`string`
"""string"""
r"string"

I vote:
THIS
Python uses r"string" for raw (wysiwyg) strings.
but how about raw"string" - isn't that much clearer
OR 


since they are already in use in another language

"""string"""  is absolutely horrible

Helmut Leitner <helmut.leitner chello.at> writes:

Walter wrote:
 
 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings
 
 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context. Unfortunately,
 this leads to ambiguities with no reasonable way out (other than crafting
 arbitrary and confusing rules).

Just a few thoughts.

I like 
  'string' : wysiwyg strings
  "string" : escaped strings
the way it is (like Perl). 

Perl uses an alternative Syntax for various types of quoting
("any nonwhitespace delimiter may be used in place of / "):
  q/.../ single quote
  qq/.../ double quote
  qr/.../ quote regex expression
  qx/.../ quote execution (instead of backtick)
  qw/.../ word lists
which seems quite handy and open for extensions

On the other hand what would happen if you changed the semantics of
  \n
to single character literal? The problems or ambiguities would 
be different and perhaps easier to solve.

One may also note that VB uses ' and " identically. This is very
handy to build strings containing the opposite type of 
quoting. 
E. g. SQL: "SELECT * FROM Table WHERE Name='Peter';"
       or: 'SELECT * FROM Table WHERE Name="Peter";'
This would also simplify building HTML
  typical Perl: "<td width=\"1%\" align=\"right\">"
         VBish: '<td width="1%" align="right">'
(of course no-one will ever use VB to generate HTML for other reasons)

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com

"Walter" <walter digitalmars.com> writes:

"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3F236984.85F075D1 chello.at...
 Walter wrote:
 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings

 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context.


Unfortunately,
 this leads to ambiguities with no reasonable way out (other than


crafting
 arbitrary and confusing rules).

 Just a few thoughts.

 I like
   'string' : wysiwyg strings
   "string" : escaped strings
 the way it is (like Perl).

 Perl uses an alternative Syntax for various types of quoting
 ("any nonwhitespace delimiter may be used in place of / "):
   q/.../ single quote
   qq/.../ double quote
   qr/.../ quote regex expression
   qx/.../ quote execution (instead of backtick)
   qw/.../ word lists
 which seems quite handy and open for extensions

This is nice, but it won't work due to lexer confusion with:
    a = q/3;


 On the other hand what would happen if you changed the semantics of
   \n
 to single character literal? The problems or ambiguities would
 be different and perhaps easier to solve.

It would work lexically, but I think it just wouldn't look right.

 One may also note that VB uses ' and " identically. This is very
 handy to build strings containing the opposite type of
 quoting.
 E. g. SQL: "SELECT * FROM Table WHERE Name='Peter';"
        or: 'SELECT * FROM Table WHERE Name="Peter";'
 This would also simplify building HTML
   typical Perl: "<td width=\"1%\" align=\"right\">"
          VBish: '<td width="1%" align="right">'
 (of course no-one will ever use VB to generate HTML for other reasons)

Using D to build HTML will happen with CGI apps. A single ' seems to be rare
in HTML, so using 'string' for wysiwyg strings should work well.

"Vathix" <vathix dprogramming.com> writes:

`string` seems good. It doesn't really matter to me. I'm fine with the way
it is now, too.

"Walter" <walter digitalmars.com> wrote in message
news:bfu9kp$3f1$1 digitaldaemon.com...
 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings

 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context.

Unfortunately,
 this leads to ambiguities with no reasonable way out (other than crafting
 arbitrary and confusing rules).

 So, I've been thinking of going back to the C way and having ' ' for
 character literals. That means that wysiwyg strings are left without a
 lexical syntax. Any ideas for something that would look nice? How about
 using back quotes ` `, or is that just too hard to distinguish in certain
 fonts? One thing to keep in mind is that wysiwyg strings are not going to

be
 used with nearly the same frequency as escaped strings, so the syntax can

be
 a bit less convenient for them.

 I'd like to use /string/, but that leads to too may lexical ambiguities.

 Some possibilities are:
 1) prefixing the " with a letter or a character, as in:
     W"string"
     %"string"
     !"string"
 2) using a character not used in C, such as:
     `string`
     $string$
      string 
     #string

<sorry no.spam> writes:

 'string' : wysiwyg strings
 "string" : escaped strings

Should be as they are I think.

What about a basic like syntax? (flames to /dev/null :-)

char( ) || char(' ')
char(0x20)
char(\t)

Can of chourse be made less verbose by shortening to
chr() or c().

Just an idea.

Roald

"Walter" <walter digitalmars.com> writes:

<sorry no.spam> wrote in message news:bg0ktu$2cpc$1 digitaldaemon.com...
 What about a basic like syntax? (flames to /dev/null :-)

 char( ) || char(' ')
 char(0x20)
 char(\t)

 Can of chourse be made less verbose by shortening to
 chr() or c().

 Just an idea.

It'll work, but too much typing!

Burton Radons <loth users.sourceforge.net> writes:

Walter wrote:

 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings
 
 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context. Unfortunately,
 this leads to ambiguities with no reasonable way out (other than crafting
 arbitrary and confusing rules).

All implicit casting rules are arbitrary.  Incorrect even; the value of:

    ubyte a = 64;
    ubyte b = 16;
    ubyte c = a * b / b;

Should be zero by a strict reading of intention, not sixty-four.  I'm 
jiggy with it because its utility trumps its arbitrary and confusing 
rules in my book.  Likewise with preferring a function which takes a 
single character argument over a function which takes a string.

 So, I've been thinking of going back to the C way and having ' ' for
 character literals. That means that wysiwyg strings are left without a
 lexical syntax. Any ideas for something that would look nice? How about
 using back quotes ` `, or is that just too hard to distinguish in certain
 fonts? One thing to keep in mind is that wysiwyg strings are not going to be
 used with nearly the same frequency as escaped strings, so the syntax can be
 a bit less convenient for them.

Just a note.  The "`" character is not a back quote, it's a grave 
accent.  Like the tilde and circumflex accent (the caret), it was 
apparently originally intended as a character modifier, although I can't 
find any history on computer keyboard layout.  That's why it looks 
nothing like a quote character, and more like the window system has made 
a rendering error.

It's likely to be on every Romantic language's keyboard; you can look at 
their layouts at 
(http://www.microsoft.com/globaldev/reference/keyboards.aspx) using 
Internet Explorer only.  But I wouldn't use the symbol; I don't think 
the problem, even if I agreed that it exists, merits the use of a new 
symbol.  There hasn't been a new symbol in C in thirty years.  C++ 
didn't add any new symbols.  This conservatism can get out-of-hand, but 
unless if there is absolutely no way to do otherwise I don't think there 
should be new symbols.

 I'd like to use /string/, but that leads to too may lexical ambiguities.
 
 Some possibilities are:
 1) prefixing the " with a letter or a character, as in:
     W"string"
     %"string"
     !"string"
 2) using a character not used in C, such as:
     `string`
     $string$
      string 
     #string

Dollar, "at", and octothorpe are all language- or culture-specific.  I 
see pretty good keyboard layout coverage though.

"Walter" <walter digitalmars.com> writes:

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:bg0l6c$2d3h$1 digitaldaemon.com...
 All implicit casting rules are arbitrary.  Incorrect even; the value of:

     ubyte a = 64;
     ubyte b = 16;
     ubyte c = a * b / b;

 Should be zero by a strict reading of intention, not sixty-four.  I'm
 jiggy with it because its utility trumps its arbitrary and confusing
 rules in my book.

I know. However, those are the C rules for expression evaluation. They are
very, very ingrained in C programmers, and subtly changing them would be a
disaster for D.

 Likewise with preferring a function which takes a
 single character argument over a function which takes a string.

I can see many uses for such overloading. Also, there's:
    char[23] a;
    a[] = "b";
If "b" is a string, then a[] is set to "b\0\0\0\0\0....". If "b" is a single
character, then a[] is set to "bbbbbb...";

 It's likely to be on every Romantic language's keyboard; you can look at
 their layouts at
 (http://www.microsoft.com/globaldev/reference/keyboards.aspx) using
 Internet Explorer only.  But I wouldn't use the symbol; I don't think
 the problem, even if I agreed that it exists, merits the use of a new
 symbol.  There hasn't been a new symbol in C in thirty years.  C++
 didn't add any new symbols.  This conservatism can get out-of-hand, but
 unless if there is absolutely no way to do otherwise I don't think there
 should be new symbols.

I feel the same way.

Burton Radons <loth users.sourceforge.net> writes:

Walter wrote:

Likewise with preferring a function which takes a
single character argument over a function which takes a string.

 
 
 I can see many uses for such overloading. Also, there's:
     char[23] a;
     a[] = "b";
 If "b" is a string, then a[] is set to "b\0\0\0\0\0....". If "b" is a single
 character, then a[] is set to "bbbbbb...";

No, the first's a length mismatch; "Error: lengths don't match for array
copy".  It's a good error, results in a little overspecification at
times, but keeps the nonsense code down.

Ilya Minkov <midiclub 8ung.at> writes:

Burton Radons wrote:

 Dollar, "at", and octothorpe are all language- or culture-specific.  I 
 see pretty good keyboard layout coverage though.

Being language- or culture-specific is OK. In Russia, Israel, and other 
countries with non-roman characters, dual layout keyboards are used: you 
switch between the native language and U.S. -English layout. It is 
accepted that you need next to all symbols from it to program and 
everyday configuration and somesuch.

http://www.cyrillicstore.com/kbd/ru-btc.gif

http://www.translation.net/keyshots.html

-i.

"Matthew Wilson" <matthew stlsoft.org> writes:

 It's likely to be on every Romantic language's keyboard; you can look at
 their layouts at
 (http://www.microsoft.com/globaldev/reference/keyboards.aspx) using
 Internet Explorer only.  But I wouldn't use the symbol; I don't think
 the problem, even if I agreed that it exists, merits the use of a new
 symbol.  There hasn't been a new symbol in C in thirty years.  C++
 didn't add any new symbols.  This conservatism can get out-of-hand, but
 unless if there is absolutely no way to do otherwise I don't think there
 should be new symbols.

That is a good point.

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Walter" <walter digitalmars.com> escreveu na mensagem
news:bfu9kp$3f1$1 digitaldaemon.com...
 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings

 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context.

Unfortunately,
 this leads to ambiguities with no reasonable way out (other than crafting
 arbitrary and confusing rules).

 So, I've been thinking of going back to the C way and having ' ' for
 character literals. That means that wysiwyg strings are left without a
 lexical syntax. Any ideas for something that would look nice? How about
 using back quotes ` `, or is that just too hard to distinguish in certain
 fonts? One thing to keep in mind is that wysiwyg strings are not going to

be
 used with nearly the same frequency as escaped strings, so the syntax can

be
 a bit less convenient for them.

 I'd like to use /string/, but that leads to too may lexical ambiguities.

 Some possibilities are:
 1) prefixing the " with a letter or a character, as in:
     W"string"
     %"string"
     !"string"
 2) using a character not used in C, such as:
     `string`
     $string$
      string 
     #string

Hi,

    Couldn't we use a symbol for character literals, like other languages,
like #a or $a for the letter "a"? It would probably be simpler, and we could
keep '' and "" for strings. Also \ would be character literals, instead of
single character strings.

    Best regards,
    Daniel Yokomiso.

"Whenever I climb I am followed by a dog called 'Ego'."
 - Friedrich Nietzsche (1844-1900)

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 18/7/2003

"Carlos Santander B." <carlos8294 msn.com> writes:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bg0q5t$2ieb$1 digitaldaemon.com...
|
| Hi,
|
|     Couldn't we use a symbol for character literals, like other languages,
| like #a or $a for the letter "a"? It would probably be simpler, and we
could
| keep '' and "" for strings. Also \ would be character literals, instead of
| single character strings.
|
|     Best regards,
|     Daniel Yokomiso.
|

I was going to vote for $"wysiwyg string", but now this seems like a better
idea, IMHO.

—————————————————————————
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.504 / Virus Database: 302 - Release Date: 2003-07-24

"Sean L. Palmer" <palmer.sean verizon.net> writes:

I don't see the point of wysiwyg string.  You will need escapes for the
quotes anyway, and in order to have escapes you have to have an escape for
the escape character.  Next thing you know you're back at the "normal" C
string.

Why do we need two kinds of string again?  So people can embed control
characters in the string or something?

Sean

"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:bg2469$ta2$1 digitaldaemon.com...
 I was going to vote for $"wysiwyg string", but now this seems like a

better
 idea, IMHO.

"Charles Sanders" <sanders-consulting comcast.net> writes:

I don't see the point either, I vote not to include it.

Charles

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bg2kii$1fs0$1 digitaldaemon.com...
 I don't see the point of wysiwyg string.  You will need escapes for the
 quotes anyway, and in order to have escapes you have to have an escape for
 the escape character.  Next thing you know you're back at the "normal" C
 string.

 Why do we need two kinds of string again?  So people can embed control
 characters in the string or something?

 Sean

 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:bg2469$ta2$1 digitaldaemon.com...
 I was going to vote for $"wysiwyg string", but now this seems like a

 better
 idea, IMHO.

Andy Friesen <andy ikagames.com> writes:

Charles Sanders wrote:
 I don't see the point either, I vote not to include it.
 
 Charles
 
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bg2kii$1fs0$1 digitaldaemon.com...
 
I don't see the point of wysiwyg string.  You will need escapes for the
quotes anyway, and in order to have escapes you have to have an escape for
the escape character.  Next thing you know you're back at the "normal" C
string.

Why do we need two kinds of string again?  So people can embed control
characters in the string or something?

Sean

"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:bg2469$ta2$1 digitaldaemon.com...

I was going to vote for $"wysiwyg string", but now this seems like a

better

idea, IMHO.


 
 

Regexps. :)

If you want to match "c:\con\*.exe" you'd have to write the regexp as 
"c\\:\\\\con\\\\.*\\.\\*" if raw strings were not available.

"Sean L. Palmer" <palmer.sean verizon.net> writes:

It strikes me that perhaps backslash is a poor choice for regexp escape
character, since it conflicts with both C escapes and path separators.

Sean

"Andy Friesen" <andy ikagames.com> wrote in message
news:bg3gqj$2c6t$1 digitaldaemon.com...
 Regexps. :)

 If you want to match "c:\con\*.exe" you'd have to write the regexp as
 "c\\:\\\\con\\\\.*\\.\\*" if raw strings were not available.

Mark Evans <Mark_member pathlink.com> writes:

Regexps. :)

If you want to match "c:\con\*.exe" you'd have to write the regexp as 
"c\\:\\\\con\\\\.*\\.\\*" if raw strings were not available.


So true, and reason to avoid regex-meaningful chars when inventing a string


Mark

Ilya Minkov <midiclub 8ung.at> writes:

Charles Sanders wrote:
 I don't see the point either, I vote not to include it.

However, a way to conveniently include tabs and linebreaks without 
cluttering text with excape characters would be good.

Actually, D has no parsing problems with all of this, so why not make "" 
and '' be semi-escaped strings, with a difference that with one the 
single and with the other the double quotes don't have to be escaped. 
Besides, since D faces no severe parsing problems (unlike Python), these 
*both* can be made to include tabs and linebreaks as plain text without 
replacing them by escapes.

And yet we need some character designator - why not use a "c" prefix for 
any kind of string which would cast it into a character?

Yet another possibility would be """string""" and '''string''' for 
strings completely without escape characters - being basically both the 
same. This clunky syntax could only get better if you allow to ignore 
(or force) the first linebreak directly after the opening """, as well 
as the last one just before the closing ones? These things are intended 
for writing blocks of text anyway.

-i.

Bill Cox <bill viasic.com> writes:

Charles Sanders wrote:
 I don't see the point either, I vote not to include it.
 
 Charles

Ditto.

Frank Wills <name host.com> writes:

I definitely go for something like this, using
single quotes '' and double quotes, with something
else, for single characters. I would hate to see
the syntax get cluttered up just to diferentiate
single characters from strings. The syntax of ''
and "" is simple, clean, and attractive.

Carlos Santander B. wrote:
 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bg0q5t$2ieb$1 digitaldaemon.com...
 |
 | Hi,
 |
 |     Couldn't we use a symbol for character literals, like other languages,
 | like #a or $a for the letter "a"? It would probably be simpler, and we
 could
 | keep '' and "" for strings. Also \ would be character literals, instead of
 | single character strings.
 |
 |     Best regards,
 |     Daniel Yokomiso.
 |
 
 I was going to vote for $"wysiwyg string", but now this seems like a better
 idea, IMHO.
 
 —————————————————————————
 Carlos Santander
 
 
 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.504 / Virus Database: 302 - Release Date: 2003-07-24
 
 

BenjiSmith <BenjiSmith_member pathlink.com> writes:

I agree. I use WYSIWYG strings and escaped strings all the time. I very rarely
use character literals. So, I'd prefer a syntax that uses traditional '' and "",
respectively for WYSIWYG and escaped strings, giving an oddball syntax to the
character literals.

And the nice thing about character literals is that, by definition, they are
only once character long, so there is no need for a closing delimiter, only a
starting delimiter.

My favorite options for character literals are:

\c
\\n     (for an escaped single-character, in this case a newline)
 c
#c
{c}
<c>

--Benji Smith


"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bg0q5t$2ieb$1 digitaldaemon.com...

 Hi,

     Couldn't we use a symbol for character literals, like other languages,
 like #a or $a for the letter "a"? It would probably be simpler, and we
could
 keep '' and "" for strings. Also \ would be character literals, instead of
 single character strings.

     Best regards,
     Daniel Yokomiso.

Karl Bochert <kbochert copper.net> writes:

 
 Some possibilities are:
 1) prefixing the " with a letter or a character, as in:
     W"string"
     %"string"
     !"string"
 2) using a character not used in C, such as:
     `string`
     $string$
      string 
     #string

I vote for method 1)
It has the advantage of changing from one to the other
more easily -- as in
"oops - that should be the other kind"

*"string" might work.

Karl Bochert

w <w_member pathlink.com> writes:

I vote for ( a bit verbose ) 
W"string"
C"string"
E"string"

In article <1103_1059382594 bose>, Karl Bochert says..

w <w_member pathlink.com> writes:

I vote for ( a bit verbose ) 
Ws"string"
Cs"string"
Es"string"
Sorry on the previos post

In article <1103_1059382594 bose>, Karl Bochert says..

Mark Evans <Mark_member pathlink.com> writes:

Walter,

Do things the C way as your intuition suggests.  Revert 'x' to char literal and
find something else for WYSIWYGs.  In a language so heavily based on C it makes
no sense to confuse end users about the meaning of 'x'.


Perl, and   makes me think about the Internet.  These are ugly solutions.

    Ilya Minkov <midiclub 8ung.at>  writes:
Mark Evans wrote:
 There is always =ABFrench=BB or Python triple-quotes for WYSIWYGs.  I d=

o not think
 they will be as rare as you imagine.

How do i enter these "french" ones with my keyboard? "<< >>"? Ugly.

-i.

 Jul 28 2003

    "Walter" <walter digitalmars.com>  writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:bg42f2$2ucm$1 digitaldaemon.com...
 Walter,

 Do things the C way as your intuition suggests.  Revert 'x' to char

literal and
 find something else for WYSIWYGs.  In a language so heavily based on C it

makes
 no sense to confuse end users about the meaning of 'x'.

Yes. Excellent point. I will do away with, however, the C notion of 'abcd'
to stuff 4 characters into a long. Not only is it poorly supported in C, it
is never clear what order the chars appear in the long.




of
 Perl, and   makes me think about the Internet.  These are ugly solutions.

Yes.

    "Sean L. Palmer" <palmer.sean verizon.net>  writes:
"Walter" <walter digitalmars.com> wrote in message
news:bg4b89$57s$1 digitaldaemon.com...
 Yes. Excellent point. I will do away with, however, the C notion of 'abcd'
 to stuff 4 characters into a long. Not only is it poorly supported in C,

it
 is never clear what order the chars appear in the long.

I actually use this sometimes to make FourCC codes or signature markers for
file headers.  It can be convenient.

Which is best?

cast(uint) 'FHdr'

or

('F' | ('H' << 8) | ('d' << 16) | ('r' << 24))

or

0x72644846

?

Yes, it'd be great if there were some way to know for sure the endianness of
the ordering.

That said, it's a minor feature, and has its problems, and I wouldn't cry
much if it were lost.

Sean

 Jul 28 2003

    "Walter" <walter digitalmars.com>  writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bg5351$sp1$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:bg4b89$57s$1 digitaldaemon.com...
 Yes. Excellent point. I will do away with, however, the C notion of


'abcd'
 to stuff 4 characters into a long. Not only is it poorly supported in C,

 it
 is never clear what order the chars appear in the long.

 I actually use this sometimes to make FourCC codes or signature markers

for
 file headers.  It can be convenient.

 Which is best?

 cast(uint) 'FHdr'

 or

 ('F' | ('H' << 8) | ('d' << 16) | ('r' << 24))

 or

 0x72644846

 ?

 Yes, it'd be great if there were some way to know for sure the endianness

of
 the ordering.

 That said, it's a minor feature, and has its problems, and I wouldn't cry
 much if it were lost.

I tend to use such things only once every 30,000 lines of code or so <g> and
the shift example you give above will serve nicely and reliably.

 Jul 28 2003

    Dario <Dario_member pathlink.com>  writes:
What about dropping the escaped strings?
You can always write escape sequences out of the string, can't you?
E.G. "Hello" \n "World" \n instead of "Hello\nWorld\n".
Yes, it's more typing but IMO it looks prettier and cleaner,
especially considering that editors show strings with a different color,
so escape sequences would be more visible.
-Dario

Walter:
It's beginning to look like to me the only solutions are bad and worse.


 Jul 29 2003

    Mark Evans <Mark_member pathlink.com>  writes:

was a bad choice on Microsoft's part.  They really should have known better.
Too many preprocessors and languages use   for special purposes.  Think SWIG,
JavaDoc, etc.

Use r"string"r or raw"string"raw.  The advantage here is that you can later
define new types of strings with a new letter (Unicode? a string of bits,
b"101010101111111000000" or hexadecimal bit groups, x"ABCD12340000FFFF11111"?).
So in a sense it's extensible and future-proof.  This syntax is also reminiscent
of C's numeric prefix and suffix notations, 0xABCD, 0b1010, 1.234L, etc.

The numeric string concept is convenient for static pre-assignment of memory.
The alternatives in C are not pretty:  arrays of smaller things (comma, comma,

So this notation is extra candy on top for embedded programming work.

The redundant closing letter is optional but recommended.  It solves the
meta-escape problem very cleanly.  (Actually it's dumbed-down XML.)  The b and x
variants would not require closing letters, as their contents are intrinsically
limited.  Whitespace should be allowed in them of course, x"ABCD 1234 FF00".

Mark

 Jul 29 2003

    "j anderson" <anderson badmama.com.au.REMOVE>  writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:bg6rkb$2k4p$1 digitaldaemon.com...


That
 was a bad choice on Microsoft's part.  They really should have known

better.
 Too many preprocessors and languages use   for special purposes.  Think

SWIG,
 JavaDoc, etc.

 Use r"string"r or raw"string"raw.  The advantage here is that you can

later
 define new types of strings with a new letter (Unicode? a string of bits,
 b"101010101111111000000" or hexadecimal bit groups,

x"ABCD12340000FFFF11111"?).
 So in a sense it's extensible and future-proof.  This syntax is also

reminiscent
 of C's numeric prefix and suffix notations, 0xABCD, 0b1010, 1.234L, etc.

 The numeric string concept is convenient for static pre-assignment of

memory.
 The alternatives in C are not pretty:  arrays of smaller things (comma,

comma,
 comma, comma, another comma,...) or an unreadable string


 So this notation is extra candy on top for embedded programming work.

 The redundant closing letter is optional but recommended.  It solves the
 meta-escape problem very cleanly.  (Actually it's dumbed-down XML.)  The b

and x
 variants would not require closing letters, as their contents are

intrinsically
 limited.  Whitespace should be allowed in them of course, x"ABCD 1234

FF00".
 Mark

I came to a simular conclusion. The there suggested syntaxes (I haven't read
all the replies) would make it much harder for the transition from C to D.
Explaining that a character is put in front of the quote is easier then
explaining that you need to use a particular symbol instead of quote.

 There may be some use for this syntax on array's as well.

u{10,12,16}; //enforce unsigned.
r{10,12,16}; //read only.
o{10,12,16}; //ordered.
fi{c:\data.txt}; //file to import integer array from.

I can't think of anything *good* right now, but it's an option for latter
down the track.

 Aug 07 2003

    "j anderson" <anderson badmama.com.au.REMOVE>  writes:
"j anderson" <anderson badmama.com.au.REMOVE> wrote in message
news:bgte8b$2cs$1 digitaldaemon.com...
 "Mark Evans" <Mark_member pathlink.com> wrote in message
 news:bg6rkb$2k4p$1 digitaldaemon.com...



it.
 That
 was a bad choice on Microsoft's part.  They really should have known

 better.
 Too many preprocessors and languages use   for special purposes.  Think

 SWIG,
 JavaDoc, etc.

 Use r"string"r or raw"string"raw.  The advantage here is that you can

 later
 define new types of strings with a new letter (Unicode? a string of


bits,
 b"101010101111111000000" or hexadecimal bit groups,

 x"ABCD12340000FFFF11111"?).
 So in a sense it's extensible and future-proof.  This syntax is also

 reminiscent
 of C's numeric prefix and suffix notations, 0xABCD, 0b1010, 1.234L, etc.

 The numeric string concept is convenient for static pre-assignment of

 memory.
 The alternatives in C are not pretty:  arrays of smaller things (comma,

 comma,
 comma, comma, another comma,...) or an unreadable string


 So this notation is extra candy on top for embedded programming work.

 The redundant closing letter is optional but recommended.  It solves the
 meta-escape problem very cleanly.  (Actually it's dumbed-down XML.)  The


b
 and x
 variants would not require closing letters, as their contents are

 intrinsically
 limited.  Whitespace should be allowed in them of course, x"ABCD 1234

 FF00".
 Mark

 I came to a simular conclusion. The there suggested syntaxes (I haven't

read
 all the replies) would make it much harder for the transition from C to D.
 Explaining that a character is put in front of the quote is easier then
 explaining that you need to use a particular symbol instead of quote.

  There may be some use for this syntax on array's as well.

 u{10,12,16}; //enforce unsigned.
 r{10,12,16}; //read only.
 o{10,12,16}; //ordered.
 fi{c:\data.txt}; //file to import integer array from.

 I can't think of anything *good* right now, but it's an option for latter
 down the track.

Another idea would be {" "}
The {" "} would imply it's an array of chars. Of course " would still need
to be overloaded, but that could be done with a double quote.

i.e.
char a[] = {"This is an in-text quote ""."};

or parhaps even better

char a[] = {"This is an in-text quote ", 34, ".");
char a[] = {"This is an in-text quote ", '"', ".");

All would print
This is an in-text quote ".

Although I still don't mind the append char "r" to front of string
technique.

-
J Anderson

 Aug 07 2003

    "Yeric" <REMOVEamigabloke yahoo.co.ukREMOVE>  writes:
Just to put my two penneth worth in why not

^string^

that is the hat symbol above key 6 on a standard UK keyboard.


"Walter" <walter digitalmars.com> wrote in message
news:bfu9kp$3f1$1 digitaldaemon.com...
 Currently, there are 3 kinds of string literals:
 'string' : wysiwyg strings
 "string" : escaped strings
 \ : single character strings

 There is no character literal syntax; 1 character long strings are
 implicitly converted to character literals based on context.

Unfortunately,
 this leads to ambiguities with no reasonable way out (other than crafting
 arbitrary and confusing rules).

 So, I've been thinking of going back to the C way and having ' ' for
 character literals. That means that wysiwyg strings are left without a
 lexical syntax. Any ideas for something that would look nice? How about
 using back quotes ` `, or is that just too hard to distinguish in certain
 fonts? One thing to keep in mind is that wysiwyg strings are not going to

be
 used with nearly the same frequency as escaped strings, so the syntax can

be
 a bit less convenient for them.

 I'd like to use /string/, but that leads to too may lexical ambiguities.

 Some possibilities are:
 1) prefixing the " with a letter or a character, as in:
     W"string"
     %"string"
     !"string"
 2) using a character not used in C, such as:
     `string`
     $string$
      string 
     #string


 Jul 28 2003

    "Walter" <walter digitalmars.com>  writes:
"Yeric" <REMOVEamigabloke yahoo.co.ukREMOVE> wrote in message
news:bg4afp$4io$1 digitaldaemon.com...
 Just to put my two penneth worth in why not

 ^string^

Since ^ is also a binary operator, the lexer won't be independent from the
parser.

 Jul 28 2003

    "Walter" <walter digitalmars.com>  writes:
This has been a most entertaining discussion, with a lot of great ideas. But
I have to pick one. I personally liked the `string`, but there are too many
problems with it, such as unreadable fonts, using a non-C character, etc.
The """string""" was just too ugly for me (sorry).

That leaves r"string" for wysiwyg string literals. The justifications are
(thanks to Mark, etc., who pointed them all out):

1) It sticks to the C character set.
2) No problems with different fonts.
3) Establishes a precedent for new types of special strings.
4) Easy to tokenize.
5) There's precedent experience with it in other languages, such as Python.

 Jul 29 2003

    "Matthew Wilson" <matthew stlsoft.org>  writes:
Only """string""" would have had me talking to God on the big white
telephone (I'm learning Australian, and that means "puking"), so am
perfectly content. r"string" is a good one.  "string" was also good, but on


"Walter" <walter digitalmars.com> wrote in message
news:bg70ml$2oo8$1 digitaldaemon.com...
 This has been a most entertaining discussion, with a lot of great ideas.

But
 I have to pick one. I personally liked the `string`, but there are too

many
 problems with it, such as unreadable fonts, using a non-C character, etc.
 The """string""" was just too ugly for me (sorry).

 That leaves r"string" for wysiwyg string literals. The justifications are
 (thanks to Mark, etc., who pointed them all out):

 1) It sticks to the C character set.
 2) No problems with different fonts.
 3) Establishes a precedent for new types of special strings.
 4) Easy to tokenize.
 5) There's precedent experience with it in other languages, such as

Python.


 Jul 29 2003

    John Reimer <jjreimer telus.net>  writes:
Matthew Wilson wrote:

 Only """string""" would have had me talking to God on the big white
 telephone (I'm learning Australian, and that means "puking"), so am
 perfectly content. r"string" is a good one.  "string" was also good, but on


I agree.

 Jul 29 2003

    Mark T <Mark_member pathlink.com>  writes:
...would have had me talking to God on the big white
telephone (I'm learning Australian, and that means "puking"), 

I think that is  "calling God on the big white phone"
I'm American and we used that expression back in the 1970's.

 Jul 30 2003

    "Walter" <walter digitalmars.com>  writes:
"Mark T" <Mark_member pathlink.com> wrote in message
news:bg9g0a$2b7v$1 digitaldaemon.com...
...would have had me talking to God on the big white
telephone (I'm learning Australian, and that means "puking"),

 I think that is  "calling God on the big white phone"
 I'm American and we used that expression back in the 1970's.

Hmm. I always heard it as "praying to the porcelain gods."

 Jul 31 2003

    Mark T <Mark_member pathlink.com>  writes:
In article <bgblpp$1d3a$1 digitaldaemon.com>, Walter says...
"Mark T" <Mark_member pathlink.com> wrote in message
news:bg9g0a$2b7v$1 digitaldaemon.com...
...would have had me talking to God on the big white
telephone (I'm learning Australian, and that means "puking"),

 I think that is  "calling God on the big white phone"
 I'm American and we used that expression back in the 1970's.

Hmm. I always heard it as "praying to the porcelain gods."

I also did some of that, it helped to clear my head for doing programming
homework in Algol, with all those BEGIN-END pairs

 Aug 01 2003

    "Rich C" <no spam.com>  writes:
"Walter" <walter digitalmars.com> wrote in message
news:bgblpp$1d3a$1 digitaldaemon.com...

 Hmm. I always heard it as "praying to the porcelain gods."

My favorite was always "driving the big white bus."

Rich C.

 Aug 01 2003

    Ilya Minkov <midiclub 8ung.at>  writes:
Walter wrote:
 That leaves r"string" for wysiwyg string literals. The justifications are
 (thanks to Mark, etc., who pointed them all out):

Good. How do i insert a " in such a string? Perhaps with ""?

-i.

 Jul 29 2003

    "Walter" <walter digitalmars.com>  writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bg729k$2qfc$1 digitaldaemon.com...
 Walter wrote:
 That leaves r"string" for wysiwyg string literals. The justifications


are
 (thanks to Mark, etc., who pointed them all out):

 Good. How do i insert a " in such a string? Perhaps with ""?

Two ways:

r"string" \" r"more"
"string\"more"

 Jul 29 2003

    Ilya Minkov <midiclub 8ung.at>  writes:
Walter wrote:
 Two ways:
 
 r"string" \" r"more"
 "string\"more"

Both being totally awful. One would run over many " when outputting any 
kind of markup or source. 'string' had solved that problem quite neatly.

-i.

 Jul 30 2003

    Mark Evans <Mark_member pathlink.com>  writes:
Walter wrote:
 Two ways:
 
 r"string" \" r"more"
 "string\"more"


The second idea is wrong.  In a WYSIWYG string backslash means backslash, not
meta-escape.  Raw strings should have no meta-escapes.  That's one reason I
suggested r"string"more"r with a tail delimiter.  It alleviates some of the
problem.

The only way to deal with the whole problem (e.g. now you want to embed "r in
the string) is to use a smarter (less greedy) lexer with (possibly, but not
ideally) semantic feedback from the parser.  That gets messy.

I think "r is a reasonable compromise in that it permits embedded quote marks,
the most common need, but beyond that point, one should realize that static
strings are just a small subset of any program, and a little manual
divide-and-conquer is not that hard for the really hairy ones.  There aren't
that many to begin with.

If a lot of them are staring at you, then at that point you should use a Python
script to output proper D code, and automate the labor of implementing


Mark

 Jul 30 2003

    Burton Radons <loth users.sourceforge.net>  writes:
Mark Evans wrote:

Walter wrote:

Two ways:

r"string" \" r"more"
"string\"more"


 
 
 The second idea is wrong.  In a WYSIWYG string backslash means backslash, not
 meta-escape.  Raw strings should have no meta-escapes.  That's one reason I
 suggested r"string"more"r with a tail delimiter.  It alleviates some of the
 problem.

Which is why he didn't USE a raw string.  I think using a character 
terminator is a good recipe for confusing lexing.  I think about the 
consequence of the symbols I write.  Characters, no.

This should be solved in the text editor.  Hit Control-Quote to enter a 
quote, hit Control-Quote to exit one, and handle control characters 
automatically.  The only real solution at the language level is to put 
in a count indicator before the string which is then read as raw UTF-8; 
everything else is just an inferior simulacrum.  But the IDE can do it 
correctly.

 Jul 30 2003

    Burton Radons <loth users.sourceforge.net>  writes:
Burton Radons wrote:

 This should be solved in the text editor.  Hit Control-Quote to enter a 
 quote, hit Control-Quote to exit one, and handle control characters 
 automatically.  The only real solution at the language level is to put 
 in a count indicator before the string which is then read as raw UTF-8; 
 everything else is just an inferior simulacrum.  But the IDE can do it 
 correctly.

Ack, ambiguous.  I mean that if you put in a control character - an 
escape, an out-of-range value - while in an enforced quote, the IDE will 
simply show the string as it really means, not with escapes.  It could 
use any number of schemes for indicating a string; something that would 
change when the caret is within the string.  When saving, this would be 
unpacked into escaped data.

The IDE would also be careful of rendering characters like NUL, which 
should be drawn with a special symbol.  \n would be transformed into a 
special symbol (typed using Control-Enter?), while a newline would be 
rendered normally.

I think it would work.  I'll play with it in dedit.

 Jul 30 2003

    Mark Evans <Mark_member pathlink.com>  writes:
Oh, I see now, it was a regular string wherein meta-escape is allowed.  Thanks
Burton.

Still that leaves open how you put " into a raw string.  Maybe the lexer will be
smart enough to search for the outermost feasible close-quote token.

I think using a character 
terminator is a good recipe for confusing lexing.  I think about the 
consequence of the symbols I write.  Characters, no.

I don't follow this statement.  If it means "I'm a sloppy thinker when I see
characters so please no characters as terminator tokens," then why are they
valid as initiator tokens.  And why not complain about 1.23L in D.  I can buy
the argument both ways, but not endwise only.  Considering that perspective,
initiator r" should presumably become raw" instead.  Now we're on the path to
XML...

What might align with good D taste and simpler lexing is,

r["string"more"]
x["ABCD FFFF 0000"]

The important thing to me is not how characters as tokens feel, but what buys
maximum code readability and minimum forbidden embeddings for the minimum
keystrokes and lexing hassle.

Mark

 Jul 30 2003

    "Sean L. Palmer" <palmer.sean verizon.net>  writes:
r["string"] conflicts with syntax for associative arrays.

To be honest, I really don't give a damn about raw strings.  If you want a
string in D, run it through a teeny program that escapes it properly and
paste it in.  The IDE can assist with this.

As far as the language goes, I see it as a non-issue, one already solved
perfectly well in C.

Sean

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:bg9lu5$2gpt$1 digitaldaemon.com...
 Oh, I see now, it was a regular string wherein meta-escape is allowed.

Thanks
 Burton.

 Still that leaves open how you put " into a raw string.  Maybe the lexer

will be
 smart enough to search for the outermost feasible close-quote token.

I think using a character
terminator is a good recipe for confusing lexing.  I think about the
consequence of the symbols I write.  Characters, no.

 I don't follow this statement.  If it means "I'm a sloppy thinker when I

see
 characters so please no characters as terminator tokens," then why are

they
 valid as initiator tokens.  And why not complain about 1.23L in D.  I can

buy
 the argument both ways, but not endwise only.  Considering that

perspective,
 initiator r" should presumably become raw" instead.  Now we're on the path

to
 XML...

 What might align with good D taste and simpler lexing is,

 r["string"more"]
 x["ABCD FFFF 0000"]

 The important thing to me is not how characters as tokens feel, but what

buys
 maximum code readability and minimum forbidden embeddings for the minimum
 keystrokes and lexing hassle.

 Mark


 Jul 30 2003

    Mark Evans <Mark_member pathlink.com>  writes:
Sean L. Palmer says...
r["string"] conflicts with syntax for associative arrays.

To be honest, I really don't give a damn about raw strings.  If you want a
string in D, run it through a teeny program that escapes it properly and
paste it in.

You are right about the square brackets.  They just came off the top of my head.

Raw strings help in specialized niches.  Embedded work is one.  C offers no way
to declare a readable block of hexadecimal digits larger than one integer word.
You either have lots of commas, or lots of backslashes, or cryptic gibberish,
depending how you go about it.  Variable-width spacing of the hex is hard if not
impossible, though often desirable in embedded work, e.g.
x"04EAC AB CD FAF 1234FFFFDDEE".

Not only have I written the translator scripts you suggest (only too many
times), but I have programmed dynamic regex construction for communications
protocols.  That means the program creates and uses regular expressions which
are unknowable at compile time.  These expressions are heavy with escape
characters.  Writing and debugging such code is hard without raw strings.

Mark
P.S. Walter I don't know what you mean about Unicode but consider
utf8"string" vs. utf16"string" vs. utf32"string"...just thinking out loud.

 Jul 31 2003

    "Walter" <walter digitalmars.com>  writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:bgbr92$1j3j$1 digitaldaemon.com...
 P.S. Walter I don't know what you mean about Unicode but consider
 utf8"string" vs. utf16"string" vs. utf32"string"...just thinking out loud.

1) Unicode source text will be accepted.
2) Use of \uXXXX and \UXXXXXXXX will be accepted in strings.
3) String literals can be converted at compile time between UTF-8, UTF-16
and UCS-32 all by doing the appropriate cast.

 Jul 31 2003

    Ilya Minkov <midiclub 8ung.at>  writes:
Walter wrote:
 1) Unicode source text will be accepted.
 2) Use of \uXXXX and \UXXXXXXXX will be accepted in strings.
 3) String literals can be converted at compile time between UTF-8, UTF-16
 and UCS-32 all by doing the appropriate cast.

Then why not convert single-character-strings into character literals 
using a cast?

-i.

 Jul 31 2003

    "Matthew Wilson" <matthew stlsoft.org>  writes:
Overloadability

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bgc8ut$210h$1 digitaldaemon.com...
 Walter wrote:
 1) Unicode source text will be accepted.
 2) Use of \uXXXX and \UXXXXXXXX will be accepted in strings.
 3) String literals can be converted at compile time between UTF-8,


UTF-16
 and UCS-32 all by doing the appropriate cast.

 Then why not convert single-character-strings into character literals
 using a cast?

 -i.


 Jul 31 2003

    "Walter" <walter digitalmars.com>  writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bgc8ut$210h$1 digitaldaemon.com...
 Walter wrote:
 1) Unicode source text will be accepted.
 2) Use of \uXXXX and \UXXXXXXXX will be accepted in strings.
 3) String literals can be converted at compile time between UTF-8,


UTF-16
 and UCS-32 all by doing the appropriate cast.

 Then why not convert single-character-strings into character literals
 using a cast?

Because it's too much typing:

    cast(char)"a"

for a list of them.

 Jul 31 2003

    "Sean L. Palmer" <palmer.sean verizon.net>  writes:
Perhaps I was a bit too hasty.  On reflection, it would be nice to be able
to declare large binary or hex arrays without so many extra 0x and commas.
And I guess for paths and regex it'd be nice to disable escapes.

What if you put the "raw" signifier *into* the string instead?  As an
escape.

"string\n"
"\:Rraw string"
"\:Xdeadbeef"
"\:B01001110"

"\:" would be the escape trigger for string mode in the above (I chose
backslash colon because I believe it to be unused currently, but it could be
anything).  This escape code doesn't emit any character at all, just changes
string mode to raw, hex, or binary (or whatever).

Would that work?  Seems more C compatible than the other alternatives.

Sean

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:bgbr92$1j3j$1 digitaldaemon.com...
 Sean L. Palmer says...
r["string"] conflicts with syntax for associative arrays.

To be honest, I really don't give a damn about raw strings.  If you want


a
string in D, run it through a teeny program that escapes it properly and
paste it in.

 You are right about the square brackets.  They just came off the top of my

head.
 Raw strings help in specialized niches.  Embedded work is one.  C offers

no way
 to declare a readable block of hexadecimal digits larger than one integer

word.
 You either have lots of commas, or lots of backslashes, or cryptic

gibberish,
 depending how you go about it.  Variable-width spacing of the hex is hard

if not
 impossible, though often desirable in embedded work, e.g.
 x"04EAC AB CD FAF 1234FFFFDDEE".

 Not only have I written the translator scripts you suggest (only too many
 times), but I have programmed dynamic regex construction for

communications
 protocols.  That means the program creates and uses regular expressions

which
 are unknowable at compile time.  These expressions are heavy with escape
 characters.  Writing and debugging such code is hard without raw strings.

 Mark
 P.S. Walter I don't know what you mean about Unicode but consider
 utf8"string" vs. utf16"string" vs. utf32"string"...just thinking out loud.


 Jul 31 2003

    Frank Wills <name host.com>  writes:
I'm glad this is the choice. I was worried (just a little) that
we were going to end up with something ugly and complicated.

Walter wrote:
 This has been a most entertaining discussion, with a lot of great ideas. But
 I have to pick one. I personally liked the `string`, but there are too many
 problems with it, such as unreadable fonts, using a non-C character, etc.
 The """string""" was just too ugly for me (sorry).
 
 That leaves r"string" for wysiwyg string literals. The justifications are
 (thanks to Mark, etc., who pointed them all out):
 
 1) It sticks to the C character set.
 2) No problems with different fonts.
 3) Establishes a precedent for new types of special strings.
 4) Easy to tokenize.
 5) There's precedent experience with it in other languages, such as Python.
 
 


 Jul 30 2003

    "Walter" <walter digitalmars.com>  writes:
"Frank Wills" <name host.com> wrote in message
news:bg84t6$ujs$1 digitaldaemon.com...
 I'm glad this is the choice. I was worried (just a little) that
 we were going to end up with something ugly and complicated.

I hate ugly and complicated, that's why I'm doing D <G>.

 Jul 30 2003

    Burton Radons <loth users.sourceforge.net>  writes:
Walter wrote:

 That leaves r"string" for wysiwyg string literals. The justifications are
 (thanks to Mark, etc., who pointed them all out):

If RE had an escape for the double-quote that would be even more 
helpful; \q is available and not used in Python RE or Perl RE.

 Jul 30 2003

    Mark Evans <Mark_member pathlink.com>  writes:
Walter wrote,

1) It sticks to the C character set.
2) No problems with different fonts.
3) Establishes a precedent for new types of special strings.
4) Easy to tokenize.
5) There's precedent experience with it in other languages, such as Python.

6) Permits qualifiers such as n (null), hN (length header of size N bytes),
and pN (pad to next Nth byte).  These fine-tuning controls could become
important without C's single-quote 'abcd' construct.  Here are some C
language translations.

D proposed              ANSI C

r"string"          --> 'string'
rn"string"         --> 'string\0'
rh2"string"        --> '\0\6string'
rh4"string"        --> '\0\0\0\6string'
rh7"string"        --> '\0\0\0\0\0\0\6string'
rh4n"string"       --> '\0\0\0\6string\0'
rp4"string"        --> 'string\0\0'
rnp4"string"       --> 'string\0\0'

Python also has u for Unicode, which I would simply copy like r.

Maybe going over the top here, I suggest that all of these have
command line default settings so that the meaning of r can be
set once and forgotten.  The - symbol could be used to override
in the source code for special cases.

rn- means turn off null even if defaulted 'on'
rh- means turn off header
rp- means turn off padding
rn-h-p- means turn off all

The b and x strings would address a serious need in embedded work and could
benefit from the header and padding qualifiers.

Strings should concatenate by simple juxtaposition.  That behavior enables
embedded comments:

// comment
myVar = x"ABCD 0000"
// another comment
x"FFFF BCDA"
// a final comment
;

means

myVar = x"ABCD0000FFFFBCDA";

Word alignment issues would be decided after concatenation, not before.  Strings
concatenate bit by bit.

Mark

 Jul 30 2003

    Mark Evans <Mark_member pathlink.com>  writes:
Different string types concatenate, too:

myVar = x"0123" r"string";  -->  myVar = '\0\1\2\3string';

while

myVar = x"0123" r"string" b"101";

creates an 83-bit entity whose alignment issues are open to discussion, but
should be controllable.  Then D will be a real systems language.

Mark

 Jul 30 2003

    Dario <Dario_member pathlink.com>  writes:
Mark Evans:
Different string types concatenate, too:
myVar = x"0123" r"string";  -->  myVar = '\0\1\2\3string';

What should x"0123" be? A byte array like [0x01, 0x23] or
like [0x0, 0x1, 0x2, 0x3]?
This seems strange this to me. It's not that intuitive.
-Dario

 Jul 31 2003

    Mark Evans <Mark_member pathlink.com>  writes:
Dario says...
Mark Evans:
Different string types concatenate, too:
myVar = x"0123" r"string";  -->  myVar = '\0\1\2\3string';

What should x"0123" be? A byte array like [0x01, 0x23] or
like [0x0, 0x1, 0x2, 0x3]?
This seems strange this to me. It's not that intuitive.
-Dario

Sorry that my memory for C escape syntax is getting rusty.

x"0123"

would be a 16-bit data chunk with C equivalents

'\x01\x23'

{0x01,0x23}

 Jul 31 2003

    "Walter" <walter digitalmars.com>  writes:
Some good ideas here.

Some nits:
1) D already concatenates strings that are juxtaposed.
2) Embedded unicode in strings will be fully supported in the next release,
no special prefix needed.

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:bg96tv$21cf$1 digitaldaemon.com...
 Walter wrote,

1) It sticks to the C character set.
2) No problems with different fonts.
3) Establishes a precedent for new types of special strings.
4) Easy to tokenize.
5) There's precedent experience with it in other languages, such as


Python.
 6) Permits qualifiers such as n (null), hN (length header of size N

bytes),
 and pN (pad to next Nth byte).  These fine-tuning controls could become
 important without C's single-quote 'abcd' construct.  Here are some C
 language translations.

 D proposed              ANSI C

 r"string"          --> 'string'
 rn"string"         --> 'string\0'
 rh2"string"        --> '\0\6string'
 rh4"string"        --> '\0\0\0\6string'
 rh7"string"        --> '\0\0\0\0\0\0\6string'
 rh4n"string"       --> '\0\0\0\6string\0'
 rp4"string"        --> 'string\0\0'
 rnp4"string"       --> 'string\0\0'

 Python also has u for Unicode, which I would simply copy like r.

 Maybe going over the top here, I suggest that all of these have
 command line default settings so that the meaning of r can be
 set once and forgotten.  The - symbol could be used to override
 in the source code for special cases.

 rn- means turn off null even if defaulted 'on'
 rh- means turn off header
 rp- means turn off padding
 rn-h-p- means turn off all

 The b and x strings would address a serious need in embedded work and

could
 benefit from the header and padding qualifiers.

 Strings should concatenate by simple juxtaposition.  That behavior enables
 embedded comments:

 // comment
 myVar = x"ABCD 0000"
 // another comment
 x"FFFF BCDA"
 // a final comment
 ;

 means

 myVar = x"ABCD0000FFFFBCDA";

 Word alignment issues would be decided after concatenation, not before.

Strings
 concatenate bit by bit.

 Mark


 Jul 31 2003