[bug] Compiler bug or feature?

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

[bug] Compiler bug or feature?

Michael Rueger-6
Hi all,

did anybody ever try something like

SmallInteger>>test: self
        ^self

5 test: 7 -> 7

same for nil etc.

Python in Squeak? ;-)

Michael

Reply | Threaded
Open this post in threaded view
|

Re: [bug] Compiler bug or feature?

Bert Freudenberg-3
Am 08.05.2006 um 17:28 schrieb Michael Rueger:

> Hi all,
>
> did anybody ever try something like
>
> SmallInteger>>test: self
> ^self
>
> 5 test: 7 -> 7
>
> same for nil etc.
>

Nice find. That allows to us to find really interesting answers:

whatIsTheAnswerTo: nil
        "self whatIsTheAnswerTo: 6*9"
        | true |
        true := nil printStringBase: 13.
        ^true


> Python in Squeak? ;-)

See? We even had self-as-an-arg first ...

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: [bug] Compiler bug or feature?

Wolfgang Helbig-2
In reply to this post by Michael Rueger-6
>Am 08.05.2006 um 17:28 schrieb Michael Rueger:
>
>> Hi all,
>>
>> did anybody ever try something like
>>
>> SmallInteger>>test: self
>> ^self
>>
>> 5 test: 7 -> 7
>>
>> same for nil etc.

This seems to be a bug.

At least as specified in the Blue Book for Smalltalk-80 the above code should
not be accepted.

And isn't accepted by:
Smalltalk-80 (snapshot from 31 May 1983 10:37:52 am, sources:  1 April 1983)
Squeak 3.8
Squeak 1.18
and an image called xmsmall, that Dan kindly gave me to get at ST-80 fonts.

All of them print:

test:  Name is already defined ->self
        ^self
       
when you type the above code in the system browser and try to save it.

Greetings

Wolfgang
--
Weniger, aber besser.


Reply | Threaded
Open this post in threaded view
|

Re: [bug] Compiler bug or feature?

Andreas.Raab
Wolfgang Helbig wrote:
> All of them print:
>
> test:  Name is already defined ->self
> ^self
>
> when you type the above code in the system browser and try to save it.

Yes, but if you execute, say:

   Object compile: 'testSelf: self'
   Object compile: 'testNil: nil'
   Object compile: 'testTrue: true'
   Object compile: 'testFalse: false'

It compiles just nicely. So the bug seems to be the treatments of
nil,true,false,self as variable nodes instead of literal constants.
Variable nodes may be silently shadowed in some circumstances, literal
constants cannot, e.g.,

   Object compile: 'test123: 123'
   Object compile: 'testString: ''string'''
   Object compile: 'testSymbol: #symbol'

all correctly fail.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: [bug] Compiler bug or feature?

Nicolas Cellier-3
Le Lundi 08 Mai 2006 19:31, Andreas Raab a écrit :

> Wolfgang Helbig wrote:
> > All of them print:
> >
> > test:  Name is already defined ->self
> >       ^self
> >       
> > when you type the above code in the system browser and try to save it.
>
> Yes, but if you execute, say:
>
>    Object compile: 'testSelf: self'
>    Object compile: 'testNil: nil'
>    Object compile: 'testTrue: true'
>    Object compile: 'testFalse: false'
>
> It compiles just nicely. So the bug seems to be the treatments of
> nil,true,false,self as variable nodes instead of literal constants.
> Variable nodes may be silently shadowed in some circumstances, literal
> constants cannot, e.g.,
>
>    Object compile: 'test123: 123'
>    Object compile: 'testString: ''string'''
>    Object compile: 'testSymbol: #symbol'
>
> all correctly fail.
>
> Cheers,
>    - Andreas

I think you forgot super, and maybe thisContext.

Compiler assume they are variables because it searches for variables, and they
are regularly constructed id made of letters...
Do you mean that true false nil should be detected as literals at Scanner
level (tokenization) ?

If literals true, false, nil or variables self, super, thisContext should
always take precedence over arguments and temporaries,
then such arguments would be inaccessible...

IMO, all these tricky constructs would better be forbidden with a hack in the
compiler...

Nicolas


Reply | Threaded
Open this post in threaded view
|

Re: [bug] Compiler bug or feature?

stéphane ducasse-2
In reply to this post by Andreas.Raab
The compiler is terrible.
I could not write tests controlling the error handling.

>   Object compile: 'test123: 123'
>   Object compile: 'testString: ''string'''
>   Object compile: 'testSymbol: #symbol'

Ok I was in a meeting but still...


testPseudoAsArguments
        "self run: #testPseudoAsArguments"
       
        self should: [ DummyForCompiler compile: 'test123: 123' ] raise: Error.
        self should: [ DummyForCompiler compile: 'testString: ''string''' ]  
raise: Error.
        self should: [ DummyForCompiler compile: 'testSymbol: #symbol' ]  
raise: Error.

Reply | Threaded
Open this post in threaded view
|

Re: [bug] Compiler bug or feature?

Pascal Zumkehr-2
What about:
        DummyForCompiler compile: 'testOnce: aString twice: aString'

That might be a feature, but I wouldn't mind a warning message...

Am 11.05.2006 um 18:40 schrieb stéphane ducasse:

> The compiler is terrible.
> I could not write tests controlling the error handling.
>
>>   Object compile: 'test123: 123'
>>   Object compile: 'testString: ''string'''
>>   Object compile: 'testSymbol: #symbol'
>
> Ok I was in a meeting but still...
>
>
> testPseudoAsArguments
> "self run: #testPseudoAsArguments"
>
> self should: [ DummyForCompiler compile: 'test123: 123' ] raise:
> Error.
> self should: [ DummyForCompiler compile: 'testString: ''string''' ]
> raise: Error.
> self should: [ DummyForCompiler compile: 'testSymbol: #symbol' ]
> raise: Error.
>