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

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.

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

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

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.

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

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.

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

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

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?