Mark Evans wrote:
> There is always «French» or Python triple-quotes for WYSIWYGs.  I do not think
> they will be as rare as you imagine.

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

-i.

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

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


> I dislike # or $ or @ because # is a comment in some files, $ reminds me
of
> Perl, and @ makes me think about the Internet.  These are ugly solutions.

Yes.

> There is always «French» or Python triple-quotes for WYSIWYGs.  I do not
think
> they will be as rare as you imagine.

I find the """ rather awful looking. For example,

struct A { char[] a, b, c; }
A a = { """a""","""b""", """c""" }

It looks like some sort of funky micro-barcode that would make sense if you looked at it with a magnifying glass <g>.

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

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

"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

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

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.

>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
C# uses @"string"

since they are already in use in another language

"""string"""  is absolutely horrible

OK, Walter, here is my final answer.  Do not use @ even though C# uses 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 ("#$~H*G_#@jdkBG$*&"). 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

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.