digitalmars.D - Replace core language HexStrings with library entity
- Walter Bright (10/10) Mar 15 2015 HexStrings:
- Walter Bright (1/1) Mar 15 2015 The motivation for this came from a post by deadalnix.
- deadalnix (2/3) Mar 15 2015 And I'm obviously all for it :)
- Kagamin (1/1) Mar 15 2015 http://dpaste.dzfl.pl/0f63623cc262a ?
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (2/3) Mar 15 2015 Wrong link? Or wrong thread?
- Kagamin (2/7) Mar 16 2015
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (3/11) Mar 16 2015 Ok, I get it now. But this replaces only `scope(exit)`. What
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (2/14) Mar 15 2015 Can we make it so it returns a ubyte[]?
- bearophile (5/6) Mar 15 2015 There is an enhancement request on this (for the built in hex
- Walter Bright (2/3) Mar 15 2015 A link would be helpful!
- Walter Bright (3/4) Mar 15 2015 Unfortunately, it needs to be a dropin replacement for x"...", which ret...
- bearophile (7/9) Mar 15 2015 This is bad. 99% of the times you don't want a
- FG (2/5) Mar 15 2015 Then maybe hex!"..." should produce the desired ubyte[] and something wi...
- H. S. Teoh via Digitalmars-d (12/25) Mar 15 2015 +1. I like this.
- Baz (17/26) Mar 16 2015 this is the API that's about to be proposed, it named as
- Andrei Alexandrescu (9/39) Mar 16 2015 (Drop the "public", this ain't Java.)
- bearophile (5/7) Mar 16 2015 I suggest to implement only ubyte[] first. And wait for
- Andrei Alexandrescu (2/7) Mar 16 2015 At a minimum we need the built-in replacement. -- Andrei
- David Nadlinger (7/11) Mar 16 2015 cast(string)hex!"…" works just fine as a built-in replacement
- Baz (7/58) Mar 16 2015 I'd like to propose this:
- Baz (11/76) Mar 17 2015 still about
- Walter Bright (23/23) Mar 16 2015 BTW, the motivation for x strings is that dumpers often put out results ...
- Adam D. Ruppe (8/10) Mar 16 2015 The nice thing about CTFE is it could literally just use that
- Andrei Alexandrescu (4/8) Mar 16 2015 hexString just being there accessible for inspection is a good argument
- Walter Bright (4/6) Mar 16 2015 That's right. Being able to read in custom-formatted data into compile t...
- ketmar (2/3) Mar 16 2015 hear, hear!=
- Andrei Alexandrescu (3/8) Mar 15 2015 That's what nice about library artifacts vs. language artifacts: you can...
- Walter Bright (2/4) Mar 15 2015 Yup. Should resist the urge to "fix" hexString, just make it a dropin re...
- Baz (3/12) Mar 15 2015 I'd be interested. Here's a quick draft based on octal:
- Walter Bright (3/20) Mar 15 2015 I think you've got the right idea. Time for a pull request?
- Walter Bright (3/5) Mar 15 2015 Also, HexStrings can handle w and d postfixes. Use the lexer.c code for
- Baz (3/10) Mar 17 2015 Hi, i propose this:
- bearophile (6/7) Mar 17 2015 I suggest to replace "litteral" with "literal", as in computer
- Baz (3/10) Mar 17 2015 Thx, fixed.
- Walter Bright (2/11) Mar 17 2015 Thanks!
- Baz (2/28) Mar 15 2015 Yes, i'll send a PR tomorrow of tuesday.
- Walter Bright (2/3) Mar 15 2015 Good!
- deadalnix (2/3) Mar 16 2015 Thank you !
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (2/20) Mar 16 2015 Nitpick: "Literal" is spelled with one "t".
- Andrei Alexandrescu (2/13) Mar 15 2015 hexString and hexBytes. -- Andrei
- bearophile (4/5) Mar 15 2015 Can you show me one or two different use cases of hexString?
- H. S. Teoh via Digitalmars-d (5/27) Mar 15 2015 Even better!
- Nick Treleaven (12/14) Mar 16 2015 0b1010 binary literals (even though C++11 supports them)
- Kagamin (3/4) Mar 16 2015 I'd just drop nested comments: block comments and version(none)
- ketmar (3/8) Mar 16 2015 and i'll drop `*`. there is no reason to have multiply operator, we=20
- weaselcat (4/13) Mar 16 2015 Just submit an implementation of templated `+` to phobos
- Nick Treleaven (2/6) Mar 16 2015 They need to nest in order to allow block comments in documentation bloc...
- Daniel Murphy (3/5) Mar 16 2015 You can take them when you pry them from my cold, dead hands. These are...
- Andrei Alexandrescu (6/11) Mar 16 2015 Agreed.
- Daniel Murphy (5/8) Mar 17 2015 Associative arrays come close, but only because of their insanely high
- Nick Treleaven (3/6) Mar 17 2015 q"" delimited strings. No one uses them (used once in all of Phobos).
- Daniel Murphy (3/9) Mar 17 2015 They don't have a high complexity though, and that's the point. The amo...
- Nick Treleaven (3/14) Mar 17 2015 They add complexity to tools such as ctags (written in C, the fishman
- Daniel Murphy (3/5) Mar 17 2015 Yes, but only a very little bit. How much code could you delete from a ...
- Artur Skawina via Digitalmars-d (6/11) Mar 17 2015 About 80 lines. Which can actually be a significant portion of a full le...
- Andrei Alexandrescu (18/28) Mar 17 2015 Well said.
- Daniel Murphy (3/12) Mar 17 2015 Just use vibe.d's json library.
- weaselcat (3/18) Mar 17 2015 what is the point of having a half-assed version in the
- weaselcat (3/24) Mar 17 2015 as an addendum, vibe.d reimplements huge amounts of phobos, is
- Daniel Murphy (3/5) Mar 17 2015 Some of it is blocked waiting on other parts to be implemented, the rest...
- Dicebot (7/9) Mar 20 2015 Getting something into Phobos is a huge commitment. For something
- Adam D. Ruppe (8/9) Mar 20 2015 And it ties your hands and comes with all kinds of annoying
- Andrei Alexandrescu (7/15) Mar 20 2015 I disagree with this characterization. When they do occur reviews are
- Andrei Alexandrescu (6/16) Mar 20 2015 What happened is that the design has been approved (I emailed Sönke
- Daniel Murphy (4/6) Mar 17 2015 It predates vibe.d's version by many many years, and nobody has fixed or...
- Andrei Alexandrescu (5/23) Mar 18 2015 The irony is what's now is std is usable albeit "meh", but so poorly
- Andrei Alexandrescu (2/15) Mar 18 2015 That was just an example. -- Andrei
- deadalnix (2/8) Mar 17 2015 Not that much. But q{ string are a pain in the ass.
- H. S. Teoh via Digitalmars-d (7/17) Mar 17 2015 They are very useful for writing readable string mixins though. (Well,
- Artur Skawina via Digitalmars-d (14/16) Mar 17 2015 Why? I'm not sure if you're referring to using or parsing them.
- Baz (5/25) Mar 17 2015 No. I don't agree. `q{` makes sense: it's a helper for a string
- Artur Skawina via Digitalmars-d (9/30) Mar 17 2015 There must be some misunderstanding, because you actually fully agree
- Baz (4/47) Mar 17 2015 I'm completly drunk now and i dont understand what you mean...But
- Kagamin (5/7) Mar 18 2015 The compiler lexer can be of arbitrary complexity, because it's
- Daniel Murphy (3/7) Mar 18 2015 I have no idea what your point is. Lexer complexity matters for every t...
- Kagamin (5/7) Mar 18 2015 Language complexity matters for tools. Lexer complexity is only
- H. S. Teoh via Digitalmars-d (5/14) Mar 18 2015 Not if we have libdmdlexer that they can reuse... ;-)
- Nick Treleaven (2/13) Mar 19 2015 Some tools can't require D due to project limitations.
- ketmar (2/9) Mar 17 2015 hello. let me introduce myself: i'm mr. NoOne!=
- ketmar (2/13) Mar 17 2015 yet i must confess that it was once or twice, and mostly by accident. ;-...
- Nick Treleaven (3/8) Mar 17 2015 Agreed they are more useful, but that does not necessarily mean they
- Biotronic (4/6) Mar 17 2015 And while we're at it, why not remove those pesky base-10
- Nick Treleaven (2/8) Mar 17 2015 Because all programming languages support integer literals.
- ketmar (2/8) Mar 17 2015 i second that!=
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
The motivation for this came from a post by deadalnix.
Mar 15 2015
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
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
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:On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote:http://dpaste.dzfl.pl/0f63623cc262a ?Wrong link? Or wrong thread?Any other ideas on things that can removed from the core language and replaced with library entities?
Mar 16 2015
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:Ok, I get it now. But this replaces only `scope(exit)`. What about `scope(success)` and `scope(failure)`?On Sunday, 15 March 2015 at 19:55:39 UTC, Kagamin wrote:On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote:http://dpaste.dzfl.pl/0f63623cc262a ?Wrong link? Or wrong thread?Any other ideas on things that can removed from the core language and replaced with library entities?
Mar 16 2015
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
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
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
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
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
On 2015-03-15 at 22:41, bearophile wrote:Walter Bright: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.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:
Mar 15 2015
On Sun, Mar 15, 2015 at 11:32:04PM +0100, FG via Digitalmars-d wrote:On 2015-03-15 at 22:41, bearophile wrote:+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' FortuneWalter Bright: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.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:
Mar 15 2015
On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:Walter Bright: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 ---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 16 2015
On 3/16/15 9:29 AM, Baz wrote:On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:(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.Walter Bright: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)() ---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, bearophileadditionally 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
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
On 3/16/15 11:54 AM, bearophile wrote:Andrei Alexandrescu:At a minimum we need the built-in replacement. -- AndreiThat 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.
Mar 16 2015
On Monday, 16 March 2015 at 18:58:11 UTC, Andrei Alexandrescu wrote: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? — DavidI suggest to implement only ubyte[] first. And wait for enhancement requests.At a minimum we need the built-in replacement. -- Andrei
Mar 16 2015
On Monday, 16 March 2015 at 16:45:25 UTC, Andrei Alexandrescu wrote:On 3/16/15 9:29 AM, Baz wrote: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.On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:(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.Walter Bright: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)() ---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, bearophileadditionally 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
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: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.On 3/16/15 9:29 AM, Baz wrote: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.On Sunday, 15 March 2015 at 21:41:06 UTC, bearophile wrote:(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.Walter Bright: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)() ---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, bearophileadditionally 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 17 2015
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
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
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
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. -- AndreiThat'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
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
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:That's what nice about library artifacts vs. language artifacts: you can add more of the former! Define hexBytes and hexString. -- AndreiCan 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
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. -- AndreiYup. Should resist the urge to "fix" hexString, just make it a dropin replacement.
Mar 15 2015
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
On 3/15/2015 2:18 PM, Baz wrote:On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: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.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
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
On Sunday, 15 March 2015 at 21:40:02 UTC, Walter Bright wrote:On 3/15/2015 2:34 PM, Walter Bright wrote:Hi, i propose this: https://github.com/D-Programming-Language/phobos/pull/3058P.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 17 2015
Baz:https://github.com/D-Programming-Language/phobos/pull/3058I suggest to replace "litteral" with "literal", as in computer science: http://en.wikipedia.org/wiki/Literal_%28computer_programming%29 Bye, bearophile
Mar 17 2015
On Tuesday, 17 March 2015 at 16:55:53 UTC, bearophile wrote:Baz:Thx, fixed. This was literally the world wide shame...https://github.com/D-Programming-Language/phobos/pull/3058I suggest to replace "litteral" with "literal", as in computer science: http://en.wikipedia.org/wiki/Literal_%28computer_programming%29 Bye, bearophile
Mar 17 2015
On 3/17/2015 9:39 AM, Baz wrote:On Sunday, 15 March 2015 at 21:40:02 UTC, Walter Bright wrote:Thanks!On 3/15/2015 2:34 PM, Walter Bright wrote:Hi, i propose this: https://github.com/D-Programming-Language/phobos/pull/3058P.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 17 2015
On Sunday, 15 March 2015 at 21:34:22 UTC, Walter Bright wrote:On 3/15/2015 2:18 PM, Baz wrote:Yes, i'll send a PR tomorrow of tuesday.On Sunday, 15 March 2015 at 19:47:06 UTC, Walter Bright wrote: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.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
On 3/15/2015 2:44 PM, Baz wrote:Yes, i'll send a PR tomorrow of tuesday.Good!
Mar 15 2015
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
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:Nitpick: "Literal" is spelled with one "t".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 16 2015
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
Andrei Alexandrescu:hexString and hexBytes. -- AndreiCan you show me one or two different use cases of hexString? Bye, bearophile
Mar 15 2015
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:Even better! T -- Nothing in the world is more distasteful to a man than to take the path that leads to himself. -- Herman HesseHexStrings: 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
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
On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:/++/ - If we made /**/ nest, /++/ would be unnecessaryI'd just drop nested comments: block comments and version(none) are good enough.
Mar 16 2015
On Mon, 16 Mar 2015 14:22:38 +0000, Kagamin wrote:On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:and i'll drop `*`. there is no reason to have multiply operator, we=20 already have `+`!=/++/ - If we made /**/ nest, /++/ would be unnecessary=20 I'd just drop nested comments: block comments and version(none) are good enough.
Mar 16 2015
On Monday, 16 March 2015 at 14:26:27 UTC, ketmar wrote:On Mon, 16 Mar 2015 14:22:38 +0000, Kagamin wrote:Just submit an implementation of templated `+` to phobos a +!5 b ;)On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:and i'll drop `*`. there is no reason to have multiply operator, we already have `+`!/++/ - If we made /**/ nest, /++/ would be unnecessaryI'd just drop nested comments: block comments and version(none) are good enough.
Mar 16 2015
On 16/03/2015 14:22, Kagamin wrote:On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:They need to nest in order to allow block comments in documentation blocks./++/ - If we made /**/ nest, /++/ would be unnecessaryI'd just drop nested comments: block comments and version(none) are good enough.
Mar 16 2015
"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
On 3/16/15 6:45 PM, Daniel Murphy wrote:"Nick Treleaven" wrote in message news:me6jo4$ca$1 digitalmars.com...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. Andrei0b1010 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
"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
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
"Nick Treleaven" wrote in message news:me950a$2boc$1 digitalmars.com...On 17/03/2015 03:28, Andrei Alexandrescu wrote: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.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
On 17/03/2015 12:42, Daniel Murphy wrote:"Nick Treleaven" wrote in message news:me950a$2boc$1 digitalmars.com...They add complexity to tools such as ctags (written in C, the fishman fork supports D but not D-specific strings).On 17/03/2015 03:28, Andrei Alexandrescu wrote: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.On a higher level: there's no subset of the language that's at the same time sufficiently complex and sufficiently obscure to make itsremoval anet 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
"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
On 03/17/15 15:15, Daniel Murphy via Digitalmars-d wrote:"Nick Treleaven" wrote in message news:me98hl$2erf$1 digitalmars.com...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? arturThey 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
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: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"Nick Treleaven" wrote in message news:me98hl$2erf$1 digitalmars.com...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?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
"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
On Wednesday, 18 March 2015 at 00:34:06 UTC, Daniel Murphy wrote:"Andrei Alexandrescu" wrote in message news:me9s2m$308v$1 digitalmars.com...what is the point of having a half-assed version in the _standard_ library???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
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:as an addendum, vibe.d reimplements huge amounts of phobos, is there a reason none of this is ever getting upstreamed?"Andrei Alexandrescu" wrote in message news:me9s2m$308v$1 digitalmars.com...what is the point of having a half-assed version in the _standard_ library???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
"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
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
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
On 3/20/15 9:09 AM, Adam D. Ruppe wrote:On Friday, 20 March 2015 at 16:02:23 UTC, Dicebot wrote: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.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.The short version is you'd do immense good if you chose to contribute to Phobos. Andrei
Mar 20 2015
On 3/20/15 9:02 AM, Dicebot wrote:On Wednesday, 18 March 2015 at 00:55:45 UTC, weaselcat wrote:Not documentation.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: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
On Saturday, 21 March 2015 at 00:30:42 UTC, Andrei Alexandrescu wrote:On 3/20/15 9:02 AM, Dicebot wrote:It was a response to question "why vibe.d has reimplemented so many bits of Phobos without ever contributing it back".On Wednesday, 18 March 2015 at 00:55:45 UTC, weaselcat wrote:Not documentation.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: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.
Mar 22 2015
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
"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
On 3/17/15 5:45 PM, weaselcat wrote:On Wednesday, 18 March 2015 at 00:34:06 UTC, Daniel Murphy wrote: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"Andrei Alexandrescu" wrote in message news:me9s2m$308v$1 digitalmars.com...what is the point of having a half-assed version in the _standard_ library???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 18 2015
On 3/17/15 5:34 PM, Daniel Murphy wrote:"Andrei Alexandrescu" wrote in message news:me9s2m$308v$1 digitalmars.com...That was just an example. -- AndreiIt 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 18 2015
On Tuesday, 17 March 2015 at 14:14:59 UTC, Daniel Murphy wrote:"Nick Treleaven" wrote in message news:me98hl$2erf$1 digitalmars.com...Not that much. But q{ string are a pain in the ass.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
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: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"Nick Treleaven" wrote in message news:me98hl$2erf$1 digitalmars.com...Not that much. But q{ string are a pain in the ass.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
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
On Tuesday, 17 March 2015 at 21:06:04 UTC, Artur Skawina wrote:On 03/17/15 20:47, deadalnix via Digitalmars-d wrote: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.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
Mar 17 2015
On 03/17/15 22:18, Baz via Digitalmars-d wrote:On Tuesday, 17 March 2015 at 21:06:04 UTC, Artur Skawina wrote: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. arturOn 03/17/15 20:47, deadalnix via Digitalmars-d wrote: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.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
Mar 17 2015
On Tuesday, 17 March 2015 at 21:31:58 UTC, Artur Skawina wrote:On 03/17/15 22:18, Baz via Digitalmars-d wrote: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.On Tuesday, 17 March 2015 at 21:06:04 UTC, Artur Skawina wrote: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. arturOn 03/17/15 20:47, deadalnix via Digitalmars-d wrote: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.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
Mar 17 2015
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
"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
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
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...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. KnuthThe 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
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:Some tools can't require D due to project limitations."Kagamin" wrote in message news:pltiewdojqrmgxrwhzoo forum.dlang.org...Not if we have libdmdlexer that they can reuse... ;-)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 19 2015
On Tue, 17 Mar 2015 12:00:09 +0000, Nick Treleaven wrote:On 17/03/2015 03:28, Andrei Alexandrescu wrote:hello. let me introduce myself: i'm mr. NoOne!=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.
Mar 17 2015
On Tue, 17 Mar 2015 13:16:58 +0000, ketmar wrote:On Tue, 17 Mar 2015 12:00:09 +0000, Nick Treleaven wrote: =20yet i must confess that it was once or twice, and mostly by accident. ;-)=On 17/03/2015 03:28, Andrei Alexandrescu wrote:=20 hello. let me introduce myself: i'm mr. NoOne!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.
Mar 17 2015
On 17/03/2015 01:45, Daniel Murphy wrote:"Nick Treleaven" wrote in message news:me6jo4$ca$1 digitalmars.com...Agreed they are more useful, but that does not necessarily mean they should be built-in.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 17 2015
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
On 17/03/2015 11:34, Biotronic wrote:On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:Because all programming languages support integer literals.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
On Tue, 17 Mar 2015 11:34:27 +0000, Biotronic wrote:On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote:i second that!=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
Mar 17 2015