[BUG] nil ~= 1and: [1 isNil] is parsed+compiled without complaint

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[BUG] nil ~= 1and: [1 isNil] is parsed+compiled without complaint

Klaus D. Witzel
This bug is reproducible in 3.7/8/9, entered

- http://bugs.impara.de/view.php?id=3836

/Klaus


Reply | Threaded
Open this post in threaded view
|

Re: [BUG] nil ~= 1and: [1 isNil] is parsed+compiled without complaint

Mathieu SUEN
2006/6/22, Klaus D. Witzel <[hidden email]>:
> This bug is reproducible in 3.7/8/9, entered
>
> - http://bugs.impara.de/view.php?id=3836
>
> /Klaus
>

Yes is strange but the message can't start with a number so i think
the lexical scanner return the good lexem.

Reply | Threaded
Open this post in threaded view
|

Re: [BUG] nil ~= 1and: [1 isNil] is parsed+compiled without complaint

Nicolas Cellier-3
Le Jeudi 22 Juin 2006 11:07, Mathieu SUEN a écrit :
> 2006/6/22, Klaus D. Witzel <[hidden email]>:
> > This bug is reproducible in 3.7/8/9, entered
> >
> > - http://bugs.impara.de/view.php?id=3836
> >
> > /Klaus
>
> Yes is strange but the message can't start with a number so i think
> the lexical scanner return the good lexem.

Agree with Mathieu, you would even write it without any space
    nil~=1and:[1isNil]
that it would still work...
An identifier cannot begin with a digit, thus neither the Scanner nor the
Parser does see any ambiguity in this expression, though it is not really
readable with human eyes...

To me, this feature is good for binary messages like (a+b) that do not need
spaces to be readable, and less good for unary or keyword messages, though
the Complex (3+2i) is perfectly readable... But i would not call that a bug.
You are free to better format your code.

Nicolas


Reply | Threaded
Open this post in threaded view
|

Re: [BUG] nil ~= 1and: [1 isNil] is parsed+compiled without complaint

Klaus D. Witzel
On Thu, 22 Jun 2006 21:58:55 +0200, nicolas cellier wrote:

> Le Jeudi 22 Juin 2006 11:07, Mathieu SUEN a écrit :
>> 2006/6/22, Klaus D. Witzel <[hidden email]>:
>> > This bug is reproducible in 3.7/8/9, entered
>> >
>> > - http://bugs.impara.de/view.php?id=3836
>> >
>> > /Klaus
>>
>> Yes is strange but the message can't start with a number so i think
>> the lexical scanner return the good lexem.
>
> Agree with Mathieu, you would even write it without any space
>     nil~=1and:[1isNil]
> that it would still work...
> An identifier cannot begin with a digit, thus neither the Scanner nor the
> Parser does see any ambiguity in this expression, though it is not really
> readable with human eyes...

I can see what you mean. OTOH teaching the syntax cannot presuppose that  
someone understands the implementation of Scanner and Parser, because they  
have as yet not learned the syntax in which these tools are written.

Not that I complain much, my draft methods have more than often a single  
statement per line regardless of length, after that I ask the system for a  
pretty print view.

> To me, this feature is good for binary messages like (a+b) that do not  
> need
> spaces to be readable, and less good for unary or keyword messages,  
> though
> the Complex (3+2i) is perfectly readable...

Sure. Looks elegant, but only because you KNOW what you have typed. When  
you see the code of somebody else, like " 1wrty " and " qwrty ", this is a  
typical typo on the keyboards here. And if qwrty is a variable and #wrty  
is implemented, chances are that you find the bugs after the program is  
already in production.

'nough. I think I had not much to add.

> But i would not call that a bug.
> You are free to better format your code.

Nice, thank you.

/Klaus

> Nicolas
>
>
>