Replace core language HexStrings with library entity

[Baz via Digitalmars-d]

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.