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