www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Replace core language HexStrings with library entity

reply Walter Bright <newshound2 digitalmars.com> writes:
HexStrings:

     http://dlang.org/lex.html#HexString

They're rarely used, but very useful when needed. But, as the octal literals 
have shown, they can be easily replaced with a library template:

     x"00 FBCD 32FD 0A"

becomes:

     hex!"00 FBCD 32FD 0A"

It'll simplify the core language slightly.

Thoughts? Anyone want to write the hex template? Any other ideas on things that 
can removed from the core language and replaced with library entities?
Mar 15 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
The motivation for this came from a post by deadalnix.
Mar 15 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 15 March 2015 at 19:48:22 UTC, Walter Bright wrote:
 The motivation for this came from a post by deadalnix.
And I'm obviously all for it :)
Mar 15 2015
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
http://dpaste.dzfl.pl/0f63623cc262a ?
Mar 15 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Sunday, 15 March 2015 at 19:55:39 UTC, Kagamin wrote:
 http://dpaste.dzfl.pl/0f63623cc262a ?
Wrong link? Or wrong thread?
Mar 15 2015
parent reply "Kagamin" <spam here.lot> writes:
On Sunday, 15 March 2015 at 20:36:18 UTC, Marc Schütz wrote:
 On Sunday, 15 March 2015 at 19:55:39 UTC, Kagamin wrote:
 http://dpaste.dzfl.pl/0f63623cc262a ?
Wrong link? Or wrong thread?
On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote:
 Any other ideas on things that can removed from the core 
 language and replaced with library entities?
Mar 16 2015
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Monday, 16 March 2015 at 07:45:16 UTC, Kagamin wrote:
 On Sunday, 15 March 2015 at 20:36:18 UTC, Marc Schütz wrote:
 On Sunday, 15 March 2015 at 19:55:39 UTC, Kagamin wrote:
 http://dpaste.dzfl.pl/0f63623cc262a ?
Wrong link? Or wrong thread?
On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote:
 Any other ideas on things that can removed from the core 
 language and replaced with library entities?
Ok, I get it now. But this replaces only `scope(exit)`. What about `scope(success)` and `scope(failure)`?
Mar 16 2015
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote:
 HexStrings:

     http://dlang.org/lex.html#HexString

 They're rarely used, but very useful when needed. But, as the 
 octal literals have shown, they can be easily replaced with a 
 library template:

     x"00 FBCD 32FD 0A"

 becomes:

     hex!"00 FBCD 32FD 0A"

 It'll simplify the core language slightly.

 Thoughts? Anyone want to write the hex template? Any other 
 ideas on things that can removed from the core language and 
 replaced with library entities?
Can we make it so it returns a ubyte[]?
Mar 15 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Marc Schütz:

 Can we make it so it returns a ubyte[]?
There is an enhancement request on this (for the built in hex strings). Bye, bearophile
Mar 15 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/15/2015 2:29 PM, bearophile wrote:
 There is an enhancement request on this (for the built in hex strings).
A link would be helpful!
Mar 15 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/15/2015 1:38 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" wrote:
 Can we make it so it returns a ubyte[]?
Unfortunately, it needs to be a dropin replacement for x"...", which returns a string/wstring/dstring.
Mar 15 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Unfortunately, it needs to be a dropin replacement for x"...", 
 which returns a string/wstring/dstring.
This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string: https://issues.dlang.org/show_bug.cgi?id=10454 https://issues.dlang.org/show_bug.cgi?id=5909 Bye, bearophile
Mar 15 2015
next sibling parent reply FG <home fgda.pl> writes:
On 2015-03-15 at 22:41, bearophile wrote:
 Walter Bright:

 Unfortunately, it needs to be a dropin replacement for x"...", which returns a
string/wstring/dstring.
This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string:
Then maybe hex!"..." should produce the desired ubyte[] and something with a different name (for example hexString!"...") would be the drop-in replacement for x"...", returning a string. The more complex name being a hint that what you really need is hex.
Mar 15 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Mar 15, 2015 at 11:32:04PM +0100, FG via Digitalmars-d wrote:
 On 2015-03-15 at 22:41, bearophile wrote:
Walter Bright:

Unfortunately, it needs to be a dropin replacement for x"...", which
returns a string/wstring/dstring.
This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string:
Then maybe hex!"..." should produce the desired ubyte[] and something with a different name (for example hexString!"...") would be the drop-in replacement for x"...", returning a string. The more complex name being a hint that what you really need is hex.
+1. I like this. I was quite disappointed when I first learned that x"..." returns a string rather than immutable(ubyte)[]. I have quite a number of use cases in mind where I'd want to specify hex values to represent binary data, but can't think of any where I'd want to do that to represent string data. Needing to use casts with x"..." just looks wrong. So using hex!"..." for immutable(ubyte)[] gets +1 from me. Leave hexString!"..." to emulate the current behaviour of x"...". T -- War doesn't prove who's right, just who's left. -- BSD Games' Fortune
Mar 15 2015
prev sibling parent reply "Baz" <bb.temp gmx.com> writes:
On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:
 Walter Bright:

 Unfortunately, it needs to be a dropin replacement for x"...", 
 which returns a string/wstring/dstring.
This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string: https://issues.dlang.org/show_bug.cgi?id=10454 https://issues.dlang.org/show_bug.cgi?id=5909 Bye, bearophile
this is the API that's about to be proposed, it named as suggested by A.A., and it handles the two issues you point out: --- public string hexString(string hexData, bool putWhites = false)() public string hexString(dstring hexData, bool putWhites = false)() public string hexString(wstring hexData, bool putWhites = false)() public ubyte[] hexBytes(string hexData)() public ubyte[] hexBytes(dstring hexData)() public ubyte[] hexBytes(wstring hexData)() --- additionally to x string, a template parameter allows to put raw whites, e.g --- assert(hexString!("30 30", true) == "0 1"); assert(hexString!("30 31") == "01"); // standard x string ---
Mar 16 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/15 9:29 AM, Baz wrote:
 On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:
 Walter Bright:

 Unfortunately, it needs to be a dropin replacement for x"...", which
 returns a string/wstring/dstring.
This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string: https://issues.dlang.org/show_bug.cgi?id=10454 https://issues.dlang.org/show_bug.cgi?id=5909 Bye, bearophile
this is the API that's about to be proposed, it named as suggested by A.A., and it handles the two issues you point out: --- public string hexString(string hexData, bool putWhites = false)() public string hexString(dstring hexData, bool putWhites = false)() public string hexString(wstring hexData, bool putWhites = false)() public ubyte[] hexBytes(string hexData)() public ubyte[] hexBytes(dstring hexData)() public ubyte[] hexBytes(wstring hexData)() ---
(Drop the "public", this ain't Java.) I don't see a necessity for the input string having different widths; string is enough. There may be a necessity to choose the width of the output with changes in function name, e.g. hexWString and hexDString. That opens the question whether we want only ubyte[] for hex bytes or all integral types.
 additionally to x string, a template parameter allows to put raw whites,
 e.g

 ---
 assert(hexString!("30 30", true) == "0 1");
 assert(hexString!("30 31") == "01"); // standard x string
 ---
I don't see a need for this. Andrei
Mar 16 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 That opens the question whether we want only ubyte[] for hex 
 bytes or all integral types.
I suggest to implement only ubyte[] first. And wait for enhancement requests. Bye, bearophile
Mar 16 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/15 11:54 AM, bearophile wrote:
 Andrei Alexandrescu:

 That opens the question whether we want only ubyte[] for hex bytes or
 all integral types.
I suggest to implement only ubyte[] first. And wait for enhancement requests.
At a minimum we need the built-in replacement. -- Andrei
Mar 16 2015
parent "David Nadlinger" <code klickverbot.at> writes:
On Monday, 16 March 2015 at 18:58:11 UTC, Andrei Alexandrescu 
wrote:
 I suggest to implement only ubyte[] first. And wait for 
 enhancement
 requests.
At a minimum we need the built-in replacement. -- Andrei
cast(string)hex!"…" works just fine as a built-in replacement (where hex returns an ubyte array). Why should we repeat the same design mistake if we are going to break people's code anyway? — David
Mar 16 2015
prev sibling next sibling parent reply "Baz" <bb.temp gmx.com> writes:
On Monday, 16 March 2015 at 16:45:25 UTC, Andrei Alexandrescu 
wrote:
 On 3/16/15 9:29 AM, Baz wrote:
 On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:
 Walter Bright:

 Unfortunately, it needs to be a dropin replacement for 
 x"...", which
 returns a string/wstring/dstring.
This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string: https://issues.dlang.org/show_bug.cgi?id=10454 https://issues.dlang.org/show_bug.cgi?id=5909 Bye, bearophile
this is the API that's about to be proposed, it named as suggested by A.A., and it handles the two issues you point out: --- public string hexString(string hexData, bool putWhites = false)() public string hexString(dstring hexData, bool putWhites = false)() public string hexString(wstring hexData, bool putWhites = false)() public ubyte[] hexBytes(string hexData)() public ubyte[] hexBytes(dstring hexData)() public ubyte[] hexBytes(wstring hexData)() ---
(Drop the "public", this ain't Java.) I don't see a necessity for the input string having different widths; string is enough. There may be a necessity to choose the width of the output with changes in function name, e.g. hexWString and hexDString. That opens the question whether we want only ubyte[] for hex bytes or all integral types.
 additionally to x string, a template parameter allows to put 
 raw whites,
 e.g

 ---
 assert(hexString!("30 30", true) == "0 1");
 assert(hexString!("30 31") == "01"); // standard x string
 ---
I don't see a need for this. Andrei
I'd like to propose this: http://dpaste.dzfl.pl/044958878fd9 But after reading D.Nadlinger mind about the whole thing i realize that's the opposite the things should be done in the opposite way.
Mar 16 2015
parent "Baz" <basile.burg gmx.com> writes:
On Monday, 16 March 2015 at 21:32:45 UTC, Baz wrote:
 On Monday, 16 March 2015 at 16:45:25 UTC, Andrei Alexandrescu 
 wrote:
 On 3/16/15 9:29 AM, Baz wrote:
 On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:
 Walter Bright:

 Unfortunately, it needs to be a dropin replacement for 
 x"...", which
 returns a string/wstring/dstring.
This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string: https://issues.dlang.org/show_bug.cgi?id=10454 https://issues.dlang.org/show_bug.cgi?id=5909 Bye, bearophile
this is the API that's about to be proposed, it named as suggested by A.A., and it handles the two issues you point out: --- public string hexString(string hexData, bool putWhites = false)() public string hexString(dstring hexData, bool putWhites = false)() public string hexString(wstring hexData, bool putWhites = false)() public ubyte[] hexBytes(string hexData)() public ubyte[] hexBytes(dstring hexData)() public ubyte[] hexBytes(wstring hexData)() ---
(Drop the "public", this ain't Java.) I don't see a necessity for the input string having different widths; string is enough. There may be a necessity to choose the width of the output with changes in function name, e.g. hexWString and hexDString. That opens the question whether we want only ubyte[] for hex bytes or all integral types.
 additionally to x string, a template parameter allows to put 
 raw whites,
 e.g

 ---
 assert(hexString!("30 30", true) == "0 1");
 assert(hexString!("30 31") == "01"); // standard x string
 ---
I don't see a need for this. Andrei
I'd like to propose this: http://dpaste.dzfl.pl/044958878fd9 But after reading D.Nadlinger mind about the whole thing i realize that's the opposite the things should be done in the opposite way.
still about http://dpaste.dzfl.pl/044958878fd9 Despite of the personnal opinion over the idea of removing x strings from the lang and integrate them as a phobos template is there any particulur "no no no" that would automatically prevent this to be an acceptable PR (style, guidline, foreach vs range iterator, etc)? Sorry to insist but this is the first time i try to propose something and i'm usually less strict with my own things. Thx to reply, otherwise i give it up.
Mar 17 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
BTW, the motivation for x strings is that dumpers often put out results like
this:

0000: 80 14  0 12 43 3a 5c 63 62 78 5c 6d 61 72 73 5c    ....C:\cbx\mars\
0010: 74 6f 69 72 2e 63  0 88  6  0  0 9d 37 6e 4f  0    toir.c......7nO.
0020: 88  6  0  0 a1  1 43 56  0 96 4c  0  0  4 46 4c    ......CV..L...FL
0030: 41 54  5 5f 54 45 58 54  4 43 4f 44 45  5 5f 44    AT._TEXT.CODE._D
0040: 41 54 41  4 44 41 54 41  5 43 4f 4e 53 54  4 5f    ATA.DATA.CONST._
0050: 42 53 53  3 42 53 53  7 24 24 54 59 50 45 53  6    BSS.BSS.$$TYPES.
0060: 44 45 42 54 59 50  9 24 24 53 59 4d 42 4f 4c 53    DEBTYP.$$SYMBOLS
0070:  6 44 45 42 53 59 4d  0 99  9  0 a9 d7 11  0  0    .DEBSYM.........
0080:  3  4  1  0 99  9  0 a9 78 10  0  0  5  6  1  0    ........x.......
0090: 99  9  0 a9  0  0  0  0  7  7  1  0 99  9  0 a9    ................
00a0:  0  0  0  0  8  9  1  0 99  9  0 a1 15  e  0  0    ................
00b0:  c  d  1  0 99  9  0 a1 e3 39  0  0  a  b  1  0    .........9......
00c0: 9a  2  0  2  0 91 73  0  0  1 2e 3f 69 6e 63 55    ......s....?incU
00d0: 73 61 67 65 45 6c 65 6d 40 40 59 41 50 41 55 65    sageElem  YAPAUe
00e0: 6c 65 6d 40 40 50 41 55 49 52 53 74 61 74 65 40    lem  PAUIRState 
00f0: 40 55 4c 6f 63 40 40 40 5a 10  0  0  0  0 36 3f     ULoc   Z.....6?
0100: 67 65 74 45 74 68 69 73 40 40 59 41 50 41 55 65    getEthis  YAPAUe
0110: 6c 65 6d 40 40 55 4c 6f 63 40 40 50 41 55 49 52    lem  ULoc  PAUIR
0120: 53 74 61 74 65 40 40 50 41 56 44 73 79 6d 62 6f    State  PAVDsymbo
0130: 6c 40 40 40 5a  7  1  0  0  0  0 95  1  2  0  1    l   Z...........

and it's a giant pain to add all the \x notations, besides making it unreadably 
ugly.
Mar 16 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 16 March 2015 at 21:40:25 UTC, Walter Bright wrote:
 BTW, the motivation for x strings is that dumpers often put out 
 results like this:
The nice thing about CTFE is it could literally just use that string and snip out the pieces as needed. I really think users should learn the language more than the library.... if you know the implementation of hexString, you can do so much more with it than if you just know the function name. (this is also a benefit to this kind of function over a built in, of course)
Mar 16 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/15 3:02 PM, Adam D. Ruppe wrote:
 I really think users should learn the language more than the library....
 if you know the implementation of hexString, you can do so much more
 with it than if you just know the function name. (this is also a benefit
 to this kind of function over a built in, of course)
hexString just being there accessible for inspection is a good argument for its existence. People can use it as inspiration for their own abstractions. -- Andrei
Mar 16 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2015 3:49 PM, Andrei Alexandrescu wrote:
 hexString just being there accessible for inspection is a good argument for its
 existence. People can use it as inspiration for their own abstractions. --
Andrei
That's right. Being able to read in custom-formatted data into compile time literals is a big deal. It's a lot better than the way idgen.d (dmd compiler source) works.
Mar 16 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 16 Mar 2015 22:02:38 +0000, Adam D. Ruppe wrote:

 I really think users should learn the language more than the library....
hear, hear!=
Mar 16 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/15/15 2:37 PM, Walter Bright wrote:
 On 3/15/2015 1:38 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>"
 wrote:
 Can we make it so it returns a ubyte[]?
Unfortunately, it needs to be a dropin replacement for x"...", which returns a string/wstring/dstring.
That's what nice about library artifacts vs. language artifacts: you can add more of the former! Define hexBytes and hexString. -- Andrei
Mar 15 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/15/2015 4:28 PM, Andrei Alexandrescu wrote:
 That's what nice about library artifacts vs. language artifacts: you can add
 more of the former! Define hexBytes and hexString. -- Andrei
Yup. Should resist the urge to "fix" hexString, just make it a dropin replacement.
Mar 15 2015
prev sibling next sibling parent reply "Baz" <bb.temp gmx.com> writes:
On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote:
 HexStrings:

     http://dlang.org/lex.html#HexString

 They're rarely used, but very useful when needed. But, as the 
 octal literals have shown, they can be easily replaced with a 
 library template:

     x"00 FBCD 32FD 0A"

 becomes:

     hex!"00 FBCD 32FD 0A"

 Thoughts? Anyone want to write the hex template?
I'd be interested. Here's a quick draft based on octal: http://dpaste.dzfl.pl/656a94cdfdba
Mar 15 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/15/2015 2:18 PM, Baz wrote:
 On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote:
 HexStrings:

     http://dlang.org/lex.html#HexString

 They're rarely used, but very useful when needed. But, as the octal literals
 have shown, they can be easily replaced with a library template:

     x"00 FBCD 32FD 0A"

 becomes:

     hex!"00 FBCD 32FD 0A"

 Thoughts? Anyone want to write the hex template?
I'd be interested. Here's a quick draft based on octal: http://dpaste.dzfl.pl/656a94cdfdba
I think you've got the right idea. Time for a pull request? P.S. Also need to include all the examples in the dlang reference as unittest cases.
Mar 15 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/15/2015 2:34 PM, Walter Bright wrote:
 P.S. Also need to include all the examples in the dlang reference as unittest
 cases.
Also, HexStrings can handle w and d postfixes. Use the lexer.c code for TOK::hexStringConstant() as a guide to be sure all the permutations are covered.
Mar 15 2015
parent reply "Baz" <basile.burg gmx.com> writes:
On Sunday, 15 March 2015 at 21:40:02 UTC, Walter Bright wrote:
 On 3/15/2015 2:34 PM, Walter Bright wrote:
 P.S. Also need to include all the examples in the dlang 
 reference as unittest
 cases.
Also, HexStrings can handle w and d postfixes. Use the lexer.c code for TOK::hexStringConstant() as a guide to be sure all the permutations are covered.
Hi, i propose this: https://github.com/D-Programming-Language/phobos/pull/3058
Mar 17 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Baz:

 https://github.com/D-Programming-Language/phobos/pull/3058
I suggest to replace "litteral" with "literal", as in computer science: http://en.wikipedia.org/wiki/Literal_%28computer_programming%29 Bye, bearophile
Mar 17 2015
parent "Baz" <basile.burg gmx.com> writes:
On Tuesday, 17 March 2015 at 16:55:53 UTC, bearophile wrote:
 Baz:

 https://github.com/D-Programming-Language/phobos/pull/3058
I suggest to replace "litteral" with "literal", as in computer science: http://en.wikipedia.org/wiki/Literal_%28computer_programming%29 Bye, bearophile
Thx, fixed. This was literally the world wide shame...
Mar 17 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2015 9:39 AM, Baz wrote:
 On Sunday, 15 March 2015 at 21:40:02 UTC, Walter Bright wrote:
 On 3/15/2015 2:34 PM, Walter Bright wrote:
 P.S. Also need to include all the examples in the dlang reference as unittest
 cases.
Also, HexStrings can handle w and d postfixes. Use the lexer.c code for TOK::hexStringConstant() as a guide to be sure all the permutations are covered.
Hi, i propose this: https://github.com/D-Programming-Language/phobos/pull/3058
Thanks!
Mar 17 2015
prev sibling parent reply "Baz" <bb.temp gmx.com> writes:
On Sunday, 15 March 2015 at 21:34:22 UTC, Walter Bright wrote:
 On 3/15/2015 2:18 PM, Baz wrote:
 On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote:
 HexStrings:

    http://dlang.org/lex.html#HexString

 They're rarely used, but very useful when needed. But, as the 
 octal literals
 have shown, they can be easily replaced with a library 
 template:

    x"00 FBCD 32FD 0A"

 becomes:

    hex!"00 FBCD 32FD 0A"

 Thoughts? Anyone want to write the hex template?
I'd be interested. Here's a quick draft based on octal: http://dpaste.dzfl.pl/656a94cdfdba
I think you've got the right idea. Time for a pull request? P.S. Also need to include all the examples in the dlang reference as unittest cases.
Yes, i'll send a PR tomorrow of tuesday.
Mar 15 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/15/2015 2:44 PM, Baz wrote:
 Yes, i'll send a PR tomorrow of tuesday.
Good!
Mar 15 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 15 March 2015 at 21:44:38 UTC, Baz wrote:
 Yes, i'll send a PR tomorrow of tuesday.
Thank you !
Mar 16 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Sunday, 15 March 2015 at 21:18:11 UTC, Baz wrote:
 On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote:
 HexStrings:

    http://dlang.org/lex.html#HexString

 They're rarely used, but very useful when needed. But, as the 
 octal literals have shown, they can be easily replaced with a 
 library template:

    x"00 FBCD 32FD 0A"

 becomes:

    hex!"00 FBCD 32FD 0A"

 Thoughts? Anyone want to write the hex template?
I'd be interested. Here's a quick draft based on octal: http://dpaste.dzfl.pl/656a94cdfdba
Nitpick: "Literal" is spelled with one "t".
Mar 16 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/15/15 12:46 PM, Walter Bright wrote:
 HexStrings:

      http://dlang.org/lex.html#HexString

 They're rarely used, but very useful when needed. But, as the octal
 literals have shown, they can be easily replaced with a library template:

      x"00 FBCD 32FD 0A"

 becomes:

      hex!"00 FBCD 32FD 0A"

 It'll simplify the core language slightly.

 Thoughts? Anyone want to write the hex template? Any other ideas on
 things that can removed from the core language and replaced with library
 entities?
hexString and hexBytes. -- Andrei
Mar 15 2015
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 hexString and hexBytes. -- Andrei
Can you show me one or two different use cases of hexString? Bye, bearophile
Mar 15 2015
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Mar 15, 2015 at 04:21:09PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 3/15/15 12:46 PM, Walter Bright wrote:
HexStrings:

     http://dlang.org/lex.html#HexString

They're rarely used, but very useful when needed. But, as the octal
literals have shown, they can be easily replaced with a library
template:

     x"00 FBCD 32FD 0A"

becomes:

     hex!"00 FBCD 32FD 0A"

It'll simplify the core language slightly.

Thoughts? Anyone want to write the hex template? Any other ideas on
things that can removed from the core language and replaced with
library entities?
hexString and hexBytes. -- Andrei
Even better! T -- Nothing in the world is more distasteful to a man than to take the path that leads to himself. -- Herman Hesse
Mar 15 2015
prev sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 15/03/2015 19:46, Walter Bright wrote:
 Any other ideas on things that can removed from the core language and
 replaced with library entities?
0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) Also, there are some things which I think are unnecessary: /++/ - If we made /**/ nest, /++/ would be unnecessary. It would potentially break code, but I think it would always cause a compiler error so breakage wouldn't be silent. I think good C code tends to avoid having /* /* */ comments (and instead uses #if 0 ... #endif). q"''" non-nested delimited strings. Delimited strings seem to be quite rarely used, but the non-matching form I've never seem in the wild. Probably any intended use of these could instead use the q"[]" matching form or raw `` or heredoc strings instead.
Mar 16 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
 /++/ - If we made /**/ nest, /++/ would be unnecessary
I'd just drop nested comments: block comments and version(none) are good enough.
Mar 16 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 16 Mar 2015 14:22:38 +0000, Kagamin wrote:

 On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
 /++/ - If we made /**/ nest, /++/ would be unnecessary
=20 I'd just drop nested comments: block comments and version(none) are good enough.
and i'll drop `*`. there is no reason to have multiply operator, we=20 already have `+`!=
Mar 16 2015
parent "weaselcat" <weaselcat gmail.com> writes:
On Monday, 16 March 2015 at 14:26:27 UTC, ketmar wrote:
 On Mon, 16 Mar 2015 14:22:38 +0000, Kagamin wrote:

 On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
 /++/ - If we made /**/ nest, /++/ would be unnecessary
I'd just drop nested comments: block comments and version(none) are good enough.
and i'll drop `*`. there is no reason to have multiply operator, we already have `+`!
Just submit an implementation of templated `+` to phobos a +!5 b ;)
Mar 16 2015
prev sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 16/03/2015 14:22, Kagamin wrote:
 On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
 /++/ - If we made /**/ nest, /++/ would be unnecessary
I'd just drop nested comments: block comments and version(none) are good enough.
They need to nest in order to allow block comments in documentation blocks.
Mar 16 2015
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Nick Treleaven"  wrote in message news:me6jo4$ca$1 digitalmars.com...

 0b1010 binary literals (even though C++11 supports them)
 0xABCD hex literals (but useful for porting C)
You can take them when you pry them from my cold, dead hands. These are 1000x times more useful than octal and deserve to be built in.
Mar 16 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/15 6:45 PM, Daniel Murphy wrote:
 "Nick Treleaven"  wrote in message news:me6jo4$ca$1 digitalmars.com...

 0b1010 binary literals (even though C++11 supports them)
 0xABCD hex literals (but useful for porting C)
You can take them when you pry them from my cold, dead hands. These are 1000x times more useful than octal and deserve to be built in.
Agreed. On a higher level: there's no subset of the language that's at the same time sufficiently complex and sufficiently obscure to make its removal a net positive. Andrei
Mar 16 2015
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:me870h$1fnc$1 digitalmars.com...

 On a higher level: there's no subset of the language that's at the same 
 time sufficiently complex and sufficiently obscure to make its removal a 
 net positive.
Associative arrays come close, but only because of their insanely high complexity. Complex numbers are another one, although they can be safely ignored most of the time.
Mar 17 2015
prev sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 17/03/2015 03:28, Andrei Alexandrescu wrote:
 On a higher level: there's no subset of the language that's at the same
 time sufficiently complex and sufficiently obscure to make its removal a
 net positive.
q"" delimited strings. No one uses them (used once in all of Phobos). They are obscure and add some complexity to lexing D.
Mar 17 2015
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Nick Treleaven"  wrote in message news:me950a$2boc$1 digitalmars.com...

 On 17/03/2015 03:28, Andrei Alexandrescu wrote:
 On a higher level: there's no subset of the language that's at the same
 time sufficiently complex and sufficiently obscure to make its removal a
 net positive.
q"" delimited strings. No one uses them (used once in all of Phobos). They are obscure and add some complexity to lexing D.
They don't have a high complexity though, and that's the point. The amount of code in the compiler to support them is trivial.
Mar 17 2015
parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 17/03/2015 12:42, Daniel Murphy wrote:
 "Nick Treleaven"  wrote in message news:me950a$2boc$1 digitalmars.com...

 On 17/03/2015 03:28, Andrei Alexandrescu wrote:
 On a higher level: there's no subset of the language that's at the same
 time sufficiently complex and sufficiently obscure to make its
removal a
 net positive.
q"" delimited strings. No one uses them (used once in all of Phobos). They are obscure and add some complexity to lexing D.
They don't have a high complexity though, and that's the point. The amount of code in the compiler to support them is trivial.
They add complexity to tools such as ctags (written in C, the fishman fork supports D but not D-specific strings).
Mar 17 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Nick Treleaven"  wrote in message news:me98hl$2erf$1 digitalmars.com...

 They add complexity to tools such as ctags (written in C, the fishman fork 
 supports D but not D-specific strings).
Yes, but only a very little bit. How much code could you delete from a D lexer if they were removed?
Mar 17 2015
next sibling parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 03/17/15 15:15, Daniel Murphy via Digitalmars-d wrote:
 "Nick Treleaven"  wrote in message news:me98hl$2erf$1 digitalmars.com...
 
 They add complexity to tools such as ctags (written in C, the fishman fork
supports D but not D-specific strings).
Yes, but only a very little bit. How much code could you delete from a D lexer if they were removed?
About 80 lines. Which can actually be a significant portion of a full lexer (~15%). That still does not mean that they should go; they are useful, for example for writing multiline embedded DSLs. OTOH this would be just one more random weekly language change, so why not? artur
Mar 17 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/17/15 10:33 AM, Artur Skawina via Digitalmars-d wrote:
 On 03/17/15 15:15, Daniel Murphy via Digitalmars-d wrote:
 "Nick Treleaven"  wrote in message news:me98hl$2erf$1 digitalmars.com...

 They add complexity to tools such as ctags (written in C, the fishman fork
supports D but not D-specific strings).
Yes, but only a very little bit. How much code could you delete from a D lexer if they were removed?
About 80 lines. Which can actually be a significant portion of a full lexer (~15%). That still does not mean that they should go; they are useful, for example for writing multiline embedded DSLs. OTOH this would be just one more random weekly language change, so why not?
Well said. It pains me to no end to see energy going in all the wrong places. Just now I was reviewing some code using std.json. Most everybody admits that library could be improved or rewritten. There's been some work on the latter, which has not been pursued to completion. Until then, we've had for _years_ a mediocre - albeit let's say passable - implementation with a shockingly bad documentation - http://dlang.org/phobos/std_json.html has not ONE example, like literally not ONE line of code on it. It's been like that for YEARS. I'd find it difficult to imagine a simpler and more impactful way to contribute to D, than improving on that documentation. And that has nothing to do with the quality of generating e.g. template constraints etc. It's simply about a good soul writing some documentation. I wouldn't even be too bothered about it if only a handful of folks were working on D. But there's all this churn in the group, all this spinning of the wheels, all to so little outcome. Until we mobilize ourselves to get good work done, D doesn't deserve more notoriety than it has. Andrei
Mar 17 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:me9s2m$308v$1 digitalmars.com...

 It pains me to no end to see energy going in all the wrong places. Just 
 now I was reviewing some code using std.json. Most everybody admits that 
 library could be improved or rewritten. There's been some work on the 
 latter, which has not been pursued to completion. Until then, we've had 
 for _years_ a mediocre - albeit let's say passable - implementation with a 
 shockingly bad documentation - http://dlang.org/phobos/std_json.html has 
 not ONE example, like literally not ONE line of code on it. It's been like 
 that for YEARS. I'd find it difficult to imagine a simpler and more 
 impactful way to contribute to D, than improving on that documentation.
Just use vibe.d's json library.
Mar 17 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 18 March 2015 at 00:34:06 UTC, Daniel Murphy wrote:
 "Andrei Alexandrescu"  wrote in message 
 news:me9s2m$308v$1 digitalmars.com...

 It pains me to no end to see energy going in all the wrong 
 places. Just now I was reviewing some code using std.json. 
 Most everybody admits that library could be improved or 
 rewritten. There's been some work on the latter, which has not 
 been pursued to completion. Until then, we've had for _years_ 
 a mediocre - albeit let's say passable - implementation with a 
 shockingly bad documentation - 
 http://dlang.org/phobos/std_json.html has not ONE example, 
 like literally not ONE line of code on it. It's been like that 
 for YEARS. I'd find it difficult to imagine a simpler and more 
 impactful way to contribute to D, than improving on that 
 documentation.
Just use vibe.d's json library.
what is the point of having a half-assed version in the _standard_ library???
Mar 17 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 18 March 2015 at 00:45:56 UTC, weaselcat wrote:
 On Wednesday, 18 March 2015 at 00:34:06 UTC, Daniel Murphy 
 wrote:
 "Andrei Alexandrescu"  wrote in message 
 news:me9s2m$308v$1 digitalmars.com...

 It pains me to no end to see energy going in all the wrong 
 places. Just now I was reviewing some code using std.json. 
 Most everybody admits that library could be improved or 
 rewritten. There's been some work on the latter, which has 
 not been pursued to completion. Until then, we've had for 
 _years_ a mediocre - albeit let's say passable - 
 implementation with a shockingly bad documentation - 
 http://dlang.org/phobos/std_json.html has not ONE example, 
 like literally not ONE line of code on it. It's been like 
 that for YEARS. I'd find it difficult to imagine a simpler 
 and more impactful way to contribute to D, than improving on 
 that documentation.
Just use vibe.d's json library.
what is the point of having a half-assed version in the _standard_ library???
as an addendum, vibe.d reimplements huge amounts of phobos, is there a reason none of this is ever getting upstreamed?
Mar 17 2015
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"weaselcat"  wrote in message news:cfxrrvjnhlofsxpxxqpx forum.dlang.org...

 as an addendum, vibe.d reimplements huge amounts of phobos, is there a 
 reason none of this is ever getting upstreamed?
Some of it is blocked waiting on other parts to be implemented, the rest is waiting for someone to champion it.
Mar 17 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 18 March 2015 at 00:55:45 UTC, weaselcat wrote:
 as an addendum, vibe.d reimplements huge amounts of phobos, is 
 there a reason none of this is ever getting upstreamed?
Getting something into Phobos is a huge commitment. For something widely used like json library the API discissions can destroy your spare time in blink of an eye. Sonke actually attempted to do that at some point, you can see http://forum.dlang.org/thread/lt5s76$is$1 digitalmars.com#post-lt5s76:24is:2 1:40digitalmars.com for what happened.
Mar 20 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 20 March 2015 at 16:02:23 UTC, Dicebot wrote:
 Getting something into Phobos is a huge commitment.
And it ties your hands and comes with all kinds of annoying trivial nonsense baggage like spaces vs tabs. I have a hard enough time bringing myself to write small functions for phobos due to the sum total of these little pains. I certainly wouldn't want to go through that for a whole module, it is so much easier to just tell people to download the file from my own website.
Mar 20 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/20/15 9:09 AM, Adam D. Ruppe wrote:
 On Friday, 20 March 2015 at 16:02:23 UTC, Dicebot wrote:
 Getting something into Phobos is a huge commitment.
And it ties your hands and comes with all kinds of annoying trivial nonsense baggage like spaces vs tabs.
I disagree with this characterization. When they do occur reviews are helpful. In this particular case a professional chooses spaces without so much as thinking about it.
 I have a hard enough time bringing myself to write small functions for
 phobos due to the sum total of these little pains. I certainly wouldn't
 want to go through that for a whole module, it is so much easier to just
 tell people to download the file from my own website.
The short version is you'd do immense good if you chose to contribute to Phobos. Andrei
Mar 20 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/20/15 9:02 AM, Dicebot wrote:
 On Wednesday, 18 March 2015 at 00:55:45 UTC, weaselcat wrote:
 as an addendum, vibe.d reimplements huge amounts of phobos, is there a
 reason none of this is ever getting upstreamed?
Getting something into Phobos is a huge commitment.
Not documentation.
 For something widely
 used like json library the API discissions can destroy your spare time
 in blink of an eye. Sonke actually attempted to do that at some point,
 you can see
 http://forum.dlang.org/thread/lt5s76$is$1 digitalmars.com#post-lt5s76:24is:241:40digitalmars.com
 for what happened.
What happened is that the design has been approved (I emailed Sönke personally) but he moved places so he didn't have time. Yes, it is a time commitment. When it wasn't you get things like std.json. Andrei
Mar 20 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 21 March 2015 at 00:30:42 UTC, Andrei Alexandrescu 
wrote:
 On 3/20/15 9:02 AM, Dicebot wrote:
 On Wednesday, 18 March 2015 at 00:55:45 UTC, weaselcat wrote:
 as an addendum, vibe.d reimplements huge amounts of phobos, 
 is there a
 reason none of this is ever getting upstreamed?
Getting something into Phobos is a huge commitment.
Not documentation.
 For something widely
 used like json library the API discissions can destroy your 
 spare time
 in blink of an eye. Sonke actually attempted to do that at 
 some point,
 you can see
 http://forum.dlang.org/thread/lt5s76$is$1 digitalmars.com#post-lt5s76:24is:241:40digitalmars.com
 for what happened.
What happened is that the design has been approved (I emailed Sönke personally) but he moved places so he didn't have time. Yes, it is a time commitment. When it wasn't you get things like std.json.
It was a response to question "why vibe.d has reimplemented so many bits of Phobos without ever contributing it back".
Mar 22 2015
parent "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 22 March 2015 at 10:36:27 UTC, Dicebot wrote:

 It was a response to question "why vibe.d has reimplemented so 
 many bits of Phobos without ever contributing it back".
I apologize if it came off this way, I meant it as "vibe shouldn't have to be reimplementing these things, they're already in the stdlib so there's an obvious issue here"
Mar 22 2015
prev sibling next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"weaselcat"  wrote in message news:vlrwhuvaxxhsvvtdztrr forum.dlang.org...

 what is the point of having a half-assed version in the _standard_ 
 library???
It predates vibe.d's version by many many years, and nobody has fixed or replaced it. As Andrei said, nobody has even bothered documenting it. It will most likely stay where it is until there is a suitable replacement.
Mar 17 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/17/15 5:45 PM, weaselcat wrote:
 On Wednesday, 18 March 2015 at 00:34:06 UTC, Daniel Murphy wrote:
 "Andrei Alexandrescu"  wrote in message
 news:me9s2m$308v$1 digitalmars.com...

 It pains me to no end to see energy going in all the wrong places.
 Just now I was reviewing some code using std.json. Most everybody
 admits that library could be improved or rewritten. There's been some
 work on the latter, which has not been pursued to completion. Until
 then, we've had for _years_ a mediocre - albeit let's say passable -
 implementation with a shockingly bad documentation -
 http://dlang.org/phobos/std_json.html has not ONE example, like
 literally not ONE line of code on it. It's been like that for YEARS.
 I'd find it difficult to imagine a simpler and more impactful way to
 contribute to D, than improving on that documentation.
Just use vibe.d's json library.
what is the point of having a half-assed version in the _standard_ library???
The irony is what's now is std is usable albeit "meh", but so poorly documented it looks damn straight useless. I need to figure why folks willing to write small novels in this forum will neglect literally for years to apply some of that energy to D's documentation. -- Andrei
Mar 18 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/17/15 5:34 PM, Daniel Murphy wrote:
 "Andrei Alexandrescu"  wrote in message
 news:me9s2m$308v$1 digitalmars.com...

 It pains me to no end to see energy going in all the wrong places.
 Just now I was reviewing some code using std.json. Most everybody
 admits that library could be improved or rewritten. There's been some
 work on the latter, which has not been pursued to completion. Until
 then, we've had for _years_ a mediocre - albeit let's say passable -
 implementation with a shockingly bad documentation -
 http://dlang.org/phobos/std_json.html has not ONE example, like
 literally not ONE line of code on it. It's been like that for YEARS.
 I'd find it difficult to imagine a simpler and more impactful way to
 contribute to D, than improving on that documentation.
Just use vibe.d's json library.
That was just an example. -- Andrei
Mar 18 2015
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 17 March 2015 at 14:14:59 UTC, Daniel Murphy wrote:
 "Nick Treleaven"  wrote in message 
 news:me98hl$2erf$1 digitalmars.com...

 They add complexity to tools such as ctags (written in C, the 
 fishman fork supports D but not D-specific strings).
Yes, but only a very little bit. How much code could you delete from a D lexer if they were removed?
Not that much. But q{ string are a pain in the ass.
Mar 17 2015
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Mar 17, 2015 at 07:47:05PM +0000, deadalnix via Digitalmars-d wrote:
 On Tuesday, 17 March 2015 at 14:14:59 UTC, Daniel Murphy wrote:
"Nick Treleaven"  wrote in message news:me98hl$2erf$1 digitalmars.com...

They add complexity to tools such as ctags (written in C, the
fishman fork supports D but not D-specific strings).
Yes, but only a very little bit. How much code could you delete from a D lexer if they were removed?
Not that much. But q{ string are a pain in the ass.
They are very useful for writing readable string mixins though. (Well, string mixins themselves could also be construed to be a pain, so *shrug*.) T -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr
Mar 17 2015
prev sibling parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 03/17/15 20:47, deadalnix via Digitalmars-d wrote:
 
 Not that much. But q{ string are a pain in the ass.
Why? I'm not sure if you're referring to using or parsing them. The only problem with the former is the lack of a non-brace-nesting variant. Lexing is quite trivial, as long as the lexer supports recursion. For example, this is a complete implementation: TokenString: "q{" TokenStringBody "}" TokenStringBody: ( ( ![{}] TokenClass )+ / BracedTokenSequence )* BracedTokenSequence: "{" ( ( ![{}] TokenClass )+ / BracedTokenSequence )* "}" That's PEG, but the mapping to code should be fairly obvious. For syntax highlighting purposes it can actually be even simpler - it's enough to treat a `q{` token just like a `{`; everything that follows will be valid D tokens. artur
Mar 17 2015
parent reply "Baz" <basile.burg gmx.com> writes:
On Tuesday, 17 March 2015 at 21:06:04 UTC, Artur Skawina wrote:
 On 03/17/15 20:47, deadalnix via Digitalmars-d wrote:
 
 Not that much. But q{ string are a pain in the ass.
Why? I'm not sure if you're referring to using or parsing them. The only problem with the former is the lack of a non-brace-nesting variant. Lexing is quite trivial, as long as the lexer supports recursion. For example, this is a complete implementation: TokenString: "q{" TokenStringBody "}" TokenStringBody: ( ( ![{}] TokenClass )+ / BracedTokenSequence )* BracedTokenSequence: "{" ( ( ![{}] TokenClass )+ / BracedTokenSequence )* "}" That's PEG, but the mapping to code should be fairly obvious. For syntax highlighting purposes it can actually be even simpler - it's enough to treat a `q{` token just like a `{`; everything that follows
No. I don't agree. `q{` makes sense: it's a helper for a string you want to mix. `q{` means: don't highlight me as a string even if i'm one. It's clearly made for the people who writes text editors and IDEs.
Mar 17 2015
parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 03/17/15 22:18, Baz via Digitalmars-d wrote:
 On Tuesday, 17 March 2015 at 21:06:04 UTC, Artur Skawina wrote:
 On 03/17/15 20:47, deadalnix via Digitalmars-d wrote:
 Not that much. But q{ string are a pain in the ass.
Why? I'm not sure if you're referring to using or parsing them. The only problem with the former is the lack of a non-brace-nesting variant. Lexing is quite trivial, as long as the lexer supports recursion. For example, this is a complete implementation: TokenString: "q{" TokenStringBody "}" TokenStringBody: ( ( ![{}] TokenClass )+ / BracedTokenSequence )* BracedTokenSequence: "{" ( ( ![{}] TokenClass )+ / BracedTokenSequence )* "}" That's PEG, but the mapping to code should be fairly obvious. For syntax highlighting purposes it can actually be even simpler - it's enough to treat a `q{` token just like a `{`; everything that follows
No. I don't agree. `q{` makes sense: it's a helper for a string you want to mix. `q{` means: don't highlight me as a string even if i'm one. It's clearly made for the people who writes text editors and IDEs.
There must be some misunderstanding, because you actually fully agree with me. :) The only problem with token-strings is that there isn't a version that lets you write /incomplete/ code sequences. Eg q{ int blah(){ return } ~ text(42) ~ q{ ; } } clearly isn't valid. What's missing is either a variant where {} don't nest, or one that allows some kind of string interpolation. artur
Mar 17 2015
parent "Baz" <basile.burg gmx.com> writes:
On Tuesday, 17 March 2015 at 21:31:58 UTC, Artur Skawina wrote:
 On 03/17/15 22:18, Baz via Digitalmars-d wrote:
 On Tuesday, 17 March 2015 at 21:06:04 UTC, Artur Skawina wrote:
 On 03/17/15 20:47, deadalnix via Digitalmars-d wrote:
 Not that much. But q{ string are a pain in the ass.
Why? I'm not sure if you're referring to using or parsing them. The only problem with the former is the lack of a non-brace-nesting variant. Lexing is quite trivial, as long as the lexer supports recursion. For example, this is a complete implementation: TokenString: "q{" TokenStringBody "}" TokenStringBody: ( ( ![{}] TokenClass )+ / BracedTokenSequence )* BracedTokenSequence: "{" ( ( ![{}] TokenClass )+ / BracedTokenSequence )* "}" That's PEG, but the mapping to code should be fairly obvious. For syntax highlighting purposes it can actually be even simpler - it's enough to treat a `q{` token just like a `{`; everything that follows
No. I don't agree. `q{` makes sense: it's a helper for a string you want to mix. `q{` means: don't highlight me as a string even if i'm one. It's clearly made for the people who writes text editors and IDEs.
There must be some misunderstanding, because you actually fully agree with me. :) The only problem with token-strings is that there isn't a version that lets you write /incomplete/ code sequences. Eg q{ int blah(){ return } ~ text(42) ~ q{ ; } } clearly isn't valid. What's missing is either a variant where {} don't nest, or one that allows some kind of string interpolation. artur
I'm completly drunk now and i dont understand what you mean...But if we agree that token strings are not to be removed, then we agree. We are on the same channel.
Mar 17 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 17 March 2015 at 14:14:59 UTC, Daniel Murphy wrote:
 Yes, but only a very little bit.  How much code could you 
 delete from a D lexer if they were removed?
The compiler lexer can be of arbitrary complexity, because it's already written. If you write a compiler, you just grab the ready lexer and use it, you don't need to count lines. The problem is with other, non-compiler tools.
Mar 18 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Kagamin"  wrote in message news:pltiewdojqrmgxrwhzoo forum.dlang.org...

 The compiler lexer can be of arbitrary complexity, because it's already 
 written. If you write a compiler, you just grab the ready lexer and use 
 it, you don't need to count lines. The problem is with other, non-compiler 
 tools.
I have no idea what your point is. Lexer complexity matters for every tool that needs to lex D code.
Mar 18 2015
next sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 18 March 2015 at 08:45:53 UTC, Daniel Murphy wrote:
 I have no idea what your point is.  Lexer complexity matters 
 for every tool that needs to lex D code.
Language complexity matters for tools. Lexer complexity is only download and build, it doesn't matter what is the lexer, complexity is roughly the same, only compilation of bigger lexer can take longer if it has more lines.
Mar 18 2015
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Mar 18, 2015 at 07:45:54PM +1100, Daniel Murphy via Digitalmars-d wrote:
 "Kagamin"  wrote in message news:pltiewdojqrmgxrwhzoo forum.dlang.org...
 
The compiler lexer can be of arbitrary complexity, because it's
already written. If you write a compiler, you just grab the ready
lexer and use it, you don't need to count lines. The problem is with
other, non-compiler tools.
I have no idea what your point is. Lexer complexity matters for every tool that needs to lex D code.
Not if we have libdmdlexer that they can reuse... ;-) T -- A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth
Mar 18 2015
parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 18/03/2015 14:45, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Mar 18, 2015 at 07:45:54PM +1100, Daniel Murphy via Digitalmars-d
wrote:
 "Kagamin"  wrote in message news:pltiewdojqrmgxrwhzoo forum.dlang.org...

 The compiler lexer can be of arbitrary complexity, because it's
 already written. If you write a compiler, you just grab the ready
 lexer and use it, you don't need to count lines. The problem is with
 other, non-compiler tools.
I have no idea what your point is. Lexer complexity matters for every tool that needs to lex D code.
Not if we have libdmdlexer that they can reuse... ;-)
Some tools can't require D due to project limitations.
Mar 19 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 17 Mar 2015 12:00:09 +0000, Nick Treleaven wrote:

 On 17/03/2015 03:28, Andrei Alexandrescu wrote:
 On a higher level: there's no subset of the language that's at the same
 time sufficiently complex and sufficiently obscure to make its removal
 a net positive.
=20 q"" delimited strings. No one uses them (used once in all of Phobos). They are obscure and add some complexity to lexing D.
hello. let me introduce myself: i'm mr. NoOne!=
Mar 17 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 17 Mar 2015 13:16:58 +0000, ketmar wrote:

 On Tue, 17 Mar 2015 12:00:09 +0000, Nick Treleaven wrote:
=20
 On 17/03/2015 03:28, Andrei Alexandrescu wrote:
 On a higher level: there's no subset of the language that's at the
 same time sufficiently complex and sufficiently obscure to make its
 removal a net positive.
=20 q"" delimited strings. No one uses them (used once in all of Phobos). They are obscure and add some complexity to lexing D.
=20 hello. let me introduce myself: i'm mr. NoOne!
yet i must confess that it was once or twice, and mostly by accident. ;-)=
Mar 17 2015
prev sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 17/03/2015 01:45, Daniel Murphy wrote:
 "Nick Treleaven"  wrote in message news:me6jo4$ca$1 digitalmars.com...

 0b1010 binary literals (even though C++11 supports them)
 0xABCD hex literals (but useful for porting C)
You can take them when you pry them from my cold, dead hands. These are 1000x times more useful than octal and deserve to be built in.
Agreed they are more useful, but that does not necessarily mean they should be built-in.
Mar 17 2015
prev sibling parent reply "Biotronic" <simen.kjaras gmail.com> writes:
On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
 0b1010 binary literals (even though C++11 supports them)
 0xABCD hex literals (but useful for porting C)
And while we're at it, why not remove those pesky base-10 literals as well? Shouldn't be too hard to write dec!"123456" instead of 123456. :p
Mar 17 2015
next sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 17/03/2015 11:34, Biotronic wrote:
 On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
 0b1010 binary literals (even though C++11 supports them)
 0xABCD hex literals (but useful for porting C)
And while we're at it, why not remove those pesky base-10 literals as well? Shouldn't be too hard to write dec!"123456" instead of 123456. :p
Because all programming languages support integer literals.
Mar 17 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 17 Mar 2015 11:34:27 +0000, Biotronic wrote:

 On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:
 0b1010 binary literals (even though C++11 supports them)
 0xABCD hex literals (but useful for porting C)
=20 And while we're at it, why not remove those pesky base-10 literals as well? Shouldn't be too hard to write dec!"123456" instead of 123456. :p
i second that!=
Mar 17 2015