A lexical change (a breaking change, but trivial to fix)

Mehrdad wfunction at hotmail.com
Sun Jul 8 00:59:38 PDT 2012


On Saturday, 7 July 2012 at 22:54:15 UTC, Timon Gehr wrote:
> On 07/08/2012 12:23 AM, Mehrdad wrote:
>> On Saturday, 7 July 2012 at 22:00:43 UTC, H. S. Teoh wrote:
>>> On Sat, Jul 07, 2012 at 11:39:59PM +0200, Mehrdad wrote:
>>>> This might sound silly, but how about if D stopped allowing 
>>>> 0..2
>>>> as a range, and instead just said "invalid floating-point 
>>>> number"?
>>> [...]
>>>
>>> I like writing 0..2 as a range. It's especially nice in array 
>>> slice
>>> notation, where you _want_ to have it as concise as possible.
>>
>> Hmm... true..
>>
>>> OTOH, having implemented a D lexer before (just for practice, 
>>> not
>>> production quality), I do see how ambiguities with 
>>> floating-point
>>> numbers can cause a lot of code convolutions.
>>
>> Yeah that's exactly what happened to me lol.
>> (Mainly the problem I ran into was that I was REALLY trying to 
>> avoid
>> extra lookaheads if possible, since I was sticking to the range
>> interface of front/popFront, and trying not to consume more 
>> than I can
>> handle... and this was the edge case that broke it.)
>>
>
> You could go like this:
>
> switch(input.front) {
>     case '0'..'9':
>         bool consumedtrailingdot;
>         output.put(parseNumber(input, consumedtrailingdot));
>         if(!consumedtrailingdot) continue;
>         if(input.front != '.') {
>             output.put(Token("."));
>             continue;
>         }
>         input.popFront();
>         if(input.front != '.') {
>             output.put(Token(".."));
>             continue;
>         }
>         output.put(Token("..."));
>         continue;
> }


Right, it's trivial to fix with an extra state variable like 
'consumedtrailingdot'.

The point was, it requires an extra lookahead character, which I 
was trying to avoid (mainly for fun).

In this case, it doesn't really make a difference in practice -- 
but in general I don't like lookaheads, because depending on 
future data makes it hard for e.g. the user to enter data via the 
console.


More information about the Digitalmars-d mailing list