Scoping rules for shared variables ?

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

Scoping rules for shared variables ?

Hannes Hirzel
On 7/19/15, Peter van Rooijen <[hidden email]> wrote:
....
 I
> recently changed the scoping rules for shared variables (I think they're
> done wrong in the base image). I could change what I wanted easily. So I
> think I am not in some outsider author group. Instead I am happy that I
> could change what I wanted without needing anyone's approval or
> cooperation.

A note:
This applies to any version / distribution of Smalltalk. But it means
that you have your own version of the core system.

Could you elaborate on the issue of the shared variables, maybe it is
something to include in the core Cuis image?

--Hannes

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Scoping rules for shared variables ?

Juan Vuletich-4
On 7/19/2015 6:01 PM, H. Hirzel wrote:
> On 7/19/15, Peter van Rooijen<[hidden email]>  wrote:
> ....
>   I
>> recently changed the scoping rules for shared variables (I think they're
>> done wrong in the base image). I could change what I wanted easily. So I
>> think I am not in some outsider author group. Instead I am happy that I
>> could change what I wanted without needing anyone's approval or
>> cooperation.

Great!

> A note:
> This applies to any version / distribution of Smalltalk. But it means
> that you have your own version of the core system.
>
> Could you elaborate on the issue of the shared variables, maybe it is
> something to include in the core Cuis image?
>
> --Hannes

Agree. It would be nice to know.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Scoping rules for shared variables ?

Peter van Rooijen-2
Hi Juan, Hannes,

since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW, ST/X, VSE, IIRC) already do it as I want it to work
(Squeak does it "wrong" so perhaps it's not really a Smalltalk implementation)

This is about the lookup logic when we see a name that is not a local name (local to the block, method or object)

To resolve it (i.e., determine if it is a valid reference to a shared variable), this is the order of searching for the name:

1 pool dictionaries declared in this class (from left to right I presume but I don't care so I haven't paid attention)
2 classPool (i.e. the class variables defined in this class)
3 classPools in superclass chain
4 globals

The code in Squeak (and Cuis) does something recursive in the lookup logic when it should not, which is probably based on an incorrect understanding of the lookup rules. I have to admit that it is not easy to find how this should be done, I have studied the Blue Book and ANSI-98 Smalltalk standard (long long ago) and they were a bit fuzzy. But the logic all the other dialects have also makes the most sense (to me) and works for some "clever" stuff I do to make code 100% portable between dialects, so that's how I like it to work.

Cheers, Peter

BTW Hannes, I'm not sure I would be able to change this in Dolphin, but in the other dialects, probably. But like I said, there is no need, it is Squeak (and Cuis) that's the odd one out.

On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <[hidden email]> wrote:
On 7/19/2015 6:01 PM, H. Hirzel wrote:
On 7/19/15, Peter van Rooijen<[hidden email]>  wrote:
....
  I
recently changed the scoping rules for shared variables (I think they're
done wrong in the base image). I could change what I wanted easily. So I
think I am not in some outsider author group. Instead I am happy that I
could change what I wanted without needing anyone's approval or
cooperation.

Great!

A note:
This applies to any version / distribution of Smalltalk. But it means
that you have your own version of the core system.

Could you elaborate on the issue of the shared variables, maybe it is
something to include in the core Cuis image?

--Hannes

Agree. It would be nice to know.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Scoping rules for shared variables ?

Nicolas Cellier


2015-07-21 21:13 GMT+02:00 Peter van Rooijen <[hidden email]>:
Hi Juan, Hannes,

since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW, ST/X, VSE, IIRC) already do it as I want it to work
(Squeak does it "wrong" so perhaps it's not really a Smalltalk implementation)

This is about the lookup logic when we see a name that is not a local name (local to the block, method or object)

To resolve it (i.e., determine if it is a valid reference to a shared variable), this is the order of searching for the name:

1 pool dictionaries declared in this class (from left to right I presume but I don't care so I haven't paid attention)
2 classPool (i.e. the class variables defined in this class)
3 classPools in superclass chain
4 globals

The code in Squeak (and Cuis) does something recursive in the lookup logic when it should not, which is probably based on an incorrect understanding of the lookup rules. I have to admit that it is not easy to find how this should be done, I have studied the Blue Book and ANSI-98 Smalltalk standard (long long ago) and they were a bit fuzzy. But the logic all the other dialects have also makes the most sense (to me) and works for some "clever" stuff I do to make code 100% portable between dialects, so that's how I like it to work.


Ah, you probably mean that you would not want the superclass pool dictionaries to be inherited, right?

Nicolas
 
Cheers, Peter

BTW Hannes, I'm not sure I would be able to change this in Dolphin, but in the other dialects, probably. But like I said, there is no need, it is Squeak (and Cuis) that's the odd one out.

On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <[hidden email]> wrote:
On 7/19/2015 6:01 PM, H. Hirzel wrote:
On 7/19/15, Peter van Rooijen<[hidden email]>  wrote:
....
  I
recently changed the scoping rules for shared variables (I think they're
done wrong in the base image). I could change what I wanted easily. So I
think I am not in some outsider author group. Instead I am happy that I
could change what I wanted without needing anyone's approval or
cooperation.

Great!

A note:
This applies to any version / distribution of Smalltalk. But it means
that you have your own version of the core system.

Could you elaborate on the issue of the shared variables, maybe it is
something to include in the core Cuis image?

--Hannes

Agree. It would be nice to know.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Scoping rules for shared variables ?

Peter van Rooijen-2
Hi Nicolas,

On Tue, Jul 21, 2015 at 10:16 PM, Nicolas Cellier <[hidden email]> wrote:
 
Ah, you probably mean that you would not want the superclass pool dictionaries to be inherited, right?

Indeed they should not be inherited. If the variables are relevant for the whole hierarchy, the place to put them is in the classPool.

But there is a problem with the class variables by themselves too, although I always forget what it is. If you really want to know I can look it up of course.

Cheers, Peter



 


Nicolas
 
Cheers, Peter

BTW Hannes, I'm not sure I would be able to change this in Dolphin, but in the other dialects, probably. But like I said, there is no need, it is Squeak (and Cuis) that's the odd one out.

On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <[hidden email]> wrote:
On 7/19/2015 6:01 PM, H. Hirzel wrote:
On 7/19/15, Peter van Rooijen<[hidden email]>  wrote:
....
  I
recently changed the scoping rules for shared variables (I think they're
done wrong in the base image). I could change what I wanted easily. So I
think I am not in some outsider author group. Instead I am happy that I
could change what I wanted without needing anyone's approval or
cooperation.

Great!

A note:
This applies to any version / distribution of Smalltalk. But it means
that you have your own version of the core system.

Could you elaborate on the issue of the shared variables, maybe it is
something to include in the core Cuis image?

--Hannes

Agree. It would be nice to know.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



On Tue, Jul 21, 2015 at 10:16 PM, Nicolas Cellier <[hidden email]> wrote:


2015-07-21 21:13 GMT+02:00 Peter van Rooijen <[hidden email]>:
Hi Juan, Hannes,

since you asked: the other Smaltalks I have looked at (Dolphin, VA, VW, ST/X, VSE, IIRC) already do it as I want it to work
(Squeak does it "wrong" so perhaps it's not really a Smalltalk implementation)

This is about the lookup logic when we see a name that is not a local name (local to the block, method or object)

To resolve it (i.e., determine if it is a valid reference to a shared variable), this is the order of searching for the name:

1 pool dictionaries declared in this class (from left to right I presume but I don't care so I haven't paid attention)
2 classPool (i.e. the class variables defined in this class)
3 classPools in superclass chain
4 globals

The code in Squeak (and Cuis) does something recursive in the lookup logic when it should not, which is probably based on an incorrect understanding of the lookup rules. I have to admit that it is not easy to find how this should be done, I have studied the Blue Book and ANSI-98 Smalltalk standard (long long ago) and they were a bit fuzzy. But the logic all the other dialects have also makes the most sense (to me) and works for some "clever" stuff I do to make code 100% portable between dialects, so that's how I like it to work.


Ah, you probably mean that you would not want the superclass pool dictionaries to be inherited, right?

Nicolas
 
Cheers, Peter

BTW Hannes, I'm not sure I would be able to change this in Dolphin, but in the other dialects, probably. But like I said, there is no need, it is Squeak (and Cuis) that's the odd one out.

On Tue, Jul 21, 2015 at 3:36 AM, Juan Vuletich <[hidden email]> wrote:
On 7/19/2015 6:01 PM, H. Hirzel wrote:
On 7/19/15, Peter van Rooijen<[hidden email]>  wrote:
....
  I
recently changed the scoping rules for shared variables (I think they're
done wrong in the base image). I could change what I wanted easily. So I
think I am not in some outsider author group. Instead I am happy that I
could change what I wanted without needing anyone's approval or
cooperation.

Great!

A note:
This applies to any version / distribution of Smalltalk. But it means
that you have your own version of the core system.

Could you elaborate on the issue of the shared variables, maybe it is
something to include in the core Cuis image?

--Hannes

Agree. It would be nice to know.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org