Replace core language HexStrings with library entity

[Artur Skawina via Digitalmars-d]

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