August 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Smalltalk = strongly typed

by Igor Stasenko

On 2 August 2013 15:27, Milan Mimica <milan.mimica(a)gmail.com> wrote: > On 2 August 2013 06:03, <btc(a)openinworld.com> wrote: >> >> >> "A strongly typed language prevents any operation on the wrong type of >> data. In weakly typed languages there are ways to escape this restriction: >> type conversions" >> >> meaning that getting a MNU is a form of Strong Typing since you can't make >> a Smalltalk object run a method that is not its own. > > > How is that preventing? > by implementation? Otherwise if it not preventing, then it will be 'weak typed'. > > -- > Milan Mimica > http://sparklet.sf.net -- Best regards, Igor Stasenko.

Aug. 2, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by Max Leske

On 02.08.2013, at 15:35, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 2 August 2013 15:27, Max Leske <maxleske(a)gmail.com> wrote: >> >> Sorry, yes, "dict" should be "collection". >> >> >> On 02.08.2013, at 15:16, ClÃ©ment BÃ©ra <bera.clement(a)gmail.com> wrote: >> >> This is not a bug. >> > > yes, the expression: > > [ methodScope ] > > does not capturing the current value of methodScope variable. > > means that closure, when evaluated will always return the value > methodScope at the moment of evaluation. > > Closures do not capturing values of free variables, because then it > will mean different semantic than rest of code (in method's body). Ok, thanks. > > >> Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope. >> >> >> Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one. >> >> I totally agree with you that the variables belong to the block and should be declared there. >> >> >> Your code is the same as if you wrote : >> | methodScope | >> methodScope := 1. >> methodScope := 2. >> At the end, methodScope is of course 2. >> >> If you want the result : >> 1 >> 2 >> you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block. >> >> collection := OrderedCollection new. >> 1 to: 2 do: [ :index | >> | methodScope | >> methodScope := index. >> dict add: [ methodScope ] ]. >> collection do: [ :block | Transcript show: block value; cr ] >> >> >> 2013/8/2 Max Leske <maxleske(a)gmail.com> >>> >>> >>> I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): >>> >>> expected (by my feeble mind): >>> 1 >>> 2 >>> >>> actual: >>> 2 >>> 2 >>> >>> | methodScope | >>> collection := OrderedCollection new. >>> 1 to: 2 do: [ :index | >>> methodScope := index. >>> dict add: [ methodScope ] ]. >>> >>> collection do: [ :block | Transcript show: block value; cr ] >>> >>> I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. >>> >>> Should I open a bug report? >>> >>> Cheers, >>> Max >> >> >> >> > > > > -- > Best regards, > Igor Stasenko. >

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Camille Teruel

Just a citation: âI spent a few weeks ... trying to sort out the terminology of âstrongly typedâ, âstatically typedâ, âsafeâ, etc., and found it amazingly difï¬cult ... The usage of these terms is so various as to render them almost useless.â -- Benjamin C. Pierce If you use one of these terms, you should give a definition. And if you hear one, you shouldn't assume the author means what you think. For example some people could argue that Smalltalk is untyped (or unityped [1]), while you argued that it is strongly typed since there is no implicit type conversion. For most people, the static/dynamic and the weak/strong distinctions are supposed to be orthogonal. So, for most people, strong typing is not a synonymous of static typing. [1] http://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-stati… On 2 aoÃ»t 2013, at 06:03, btc(a)openInWorld.com wrote: > greetings all, > > I'm in the final weeks of writing up my Masters dissertation and seeking some scholarly references to Smalltalk being "Strongly Typed." > > I my review of Smalltalk I was surprised to find that [1] describes Smalltalk as Strongly Typed, since Smalltalk is sometimes denigrated as being untyped / weakly typed. From reviewing discussion forums this now makes sense, but I can only find one of scholarly reference that briefly mentions this [2]. The most enlightening is [3] which defines Type Strength as: > > "A strongly typed language prevents any operation on the wrong type of data. In weakly typed languages there are ways to escape this restriction: type conversions" > > meaning that getting a MNU is a form of Strong Typing since you can't make a Smalltalk object run a method that is not its own. The problem appears to be that Strong Typing has been synonymous with Static Typing for a long time, and Static Typing strongly ties types to variables, except in Dynamically Typed languages, I think types can be considered independently from variables, in which case the definition of [3] has some merit, hence Smalltalk is Strongly Typed. > > Sounds controversial, so I'm just hoping for some peer reviewed backup - but only you have something easily to hand. This is just a small thing I can just leave out if necessary. > > cheers -ben > > [1] http://www.squeak.org/Features/ > [2] p15, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.35.7507&rep=rep1&t… > [3] http://www.cs.kuleuven.ac.be/publicaties/rapporten/cw/CW415.pdf >

Aug. 2, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by Igor Stasenko

On 2 August 2013 15:27, Max Leske <maxleske(a)gmail.com> wrote: > > Sorry, yes, "dict" should be "collection". > > > On 02.08.2013, at 15:16, ClÃ©ment BÃ©ra <bera.clement(a)gmail.com> wrote: > > This is not a bug. > yes, the expression: [ methodScope ] does not capturing the current value of methodScope variable. means that closure, when evaluated will always return the value methodScope at the moment of evaluation. Closures do not capturing values of free variables, because then it will mean different semantic than rest of code (in method's body). > Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope. > > > Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one. > > I totally agree with you that the variables belong to the block and should be declared there. > > > Your code is the same as if you wrote : > | methodScope | > methodScope := 1. > methodScope := 2. > At the end, methodScope is of course 2. > > If you want the result : > 1 > 2 > you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block. > > collection := OrderedCollection new. > 1 to: 2 do: [ :index | > | methodScope | > methodScope := index. > dict add: [ methodScope ] ]. > collection do: [ :block | Transcript show: block value; cr ] > > > 2013/8/2 Max Leske <maxleske(a)gmail.com> >> >> >> I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): >> >> expected (by my feeble mind): >> 1 >> 2 >> >> actual: >> 2 >> 2 >> >> | methodScope | >> collection := OrderedCollection new. >> 1 to: 2 do: [ :index | >> methodScope := index. >> dict add: [ methodScope ] ]. >> >> collection do: [ :block | Transcript show: block value; cr ] >> >> I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. >> >> Should I open a bug report? >> >> Cheers, >> Max > > > > -- Best regards, Igor Stasenko.

Aug. 2, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by Max Leske

Sorry, yes, "dict" should be "collection". On 02.08.2013, at 15:16, ClÃ©ment BÃ©ra <bera.clement(a)gmail.com> wrote: > This is not a bug. > > Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope. Yes, I understand that. I just wanted to make sure that's the intended functionality. The reason I ask is that the error isn't easy to spot and there's no cue that one might be doing something wrong (It's not my code by the way :P). Especially for newcomers this can be a tricky one. I totally agree with you that the variables belong to the block and should be declared there. > > Your code is the same as if you wrote : > | methodScope | > methodScope := 1. > methodScope := 2. > At the end, methodScope is of course 2. > > If you want the result : > 1 > 2 > you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block. > > collection := OrderedCollection new. > 1 to: 2 do: [ :index | > | methodScope | > methodScope := index. > dict add: [ methodScope ] ]. > collection do: [ :block | Transcript show: block value; cr ] > > > 2013/8/2 Max Leske <maxleske(a)gmail.com> > > I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): > > expected (by my feeble mind): > 1 > 2 > > actual: > 2 > 2 > > | methodScope | > collection := OrderedCollection new. > 1 to: 2 do: [ :index | > methodScope := index. > dict add: [ methodScope ] ]. > > collection do: [ :block | Transcript show: block value; cr ] > > I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. > > Should I open a bug report? > > Cheers, > Max >

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Milan Mimica

On 2 August 2013 06:03, <btc(a)openinworld.com> wrote: > > "A strongly typed language *prevents* any operation on the wrong type of > data. In weakly typed languages there are ways to escape this restriction: > type conversions" > > meaning that getting a MNU is a form of Strong Typing since you can't make > a Smalltalk object run a method that is not its own. How is that preventing? -- Milan Mimica http://sparklet.sf.net

Aug. 2, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by ClÃ©ment BÃ©ra

This is not a bug. Here your variable methodScope is defined outside the block, therefore all the blocks and the method refers to the same variable when calling methodScope. Your code is the same as if you wrote : | methodScope | methodScope := 1. methodScope := 2. At the end, methodScope is of course 2. If you want the result : 1 2 you have to declare the variable in the block (then there are different variable named methodScope, actually 1 per activation of the block. collection := OrderedCollection new. 1 to: 2 do: [ :index | | methodScope | methodScope := index. dict add: [ methodScope ] ]. collection do: [ :block | Transcript show: block value; cr ] 2013/8/2 Max Leske <maxleske(a)gmail.com> > > I just came across this (possible) bug and I'm able to reproduce it in > Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): > > expected (by my feeble mind): > 1 > 2 > > actual: > 2 > 2 > > | methodScope | > collection := OrderedCollection new. > 1 to: 2 do: [ :index | > methodScope := index. > dict add: [ methodScope ] ]. > > collection do: [ :block | Transcript show: block value; cr ] > > I'm aware that using method temps in this way is not good programming > style (usually) but I still think this behavior is curious if not at least > very likely to cause a lot of weird errors. > > Should I open a bug report? > > Cheers, > Max

Aug. 2, 2013

Re: [Pharo-dev] [Vm-dev] modified method temp references in closures: possible bug?

by Igor Stasenko

On 2 August 2013 15:08, Max Leske <maxleske(a)gmail.com> wrote: > > I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): > > expected (by my feeble mind): > 1 > 2 > > actual: > 2 > 2 > > | methodScope | > collection := OrderedCollection new. > 1 to: 2 do: [ :index | > methodScope := index. > dict add: [ methodScope ] ]. > > collection do: [ :block | Transcript show: block value; cr ] > err.. i see dict add: but where dict was declared? > I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. > > Should I open a bug report? > > Cheers, > Max -- Best regards, Igor Stasenko.

Aug. 2, 2013

modified method temp references in closures: possible bug?

by Max Leske

I just came across this (possible) bug and I'm able to reproduce it in Pharo 2.0 and 3.0 with the latest PharoVM (found in a 1.3 with NBCog): expected (by my feeble mind): 1 2 actual: 2 2 | methodScope | collection := OrderedCollection new. 1 to: 2 do: [ :index | methodScope := index. dict add: [ methodScope ] ]. collection do: [ :block | Transcript show: block value; cr ] I'm aware that using method temps in this way is not good programming style (usually) but I still think this behavior is curious if not at least very likely to cause a lot of weird errors. Should I open a bug report? Cheers, Max

Aug. 2, 2013

Morph inspect weird behavior

by Erwan Douaille

Hi, I found something else weird, When i inspect a Morph the bounds are resized. Do it : a := Morph newBounds: (Rectangle origin: (0@0) corner: (300@300) ). a color: Color red. a openInWorld Now click on the morph, open halo, inspect it and the bounds are resized. Is that normal ? (I guess not) Thanks :) -- Best regards, Douaille Erwan <douaille.erwan(a)gmail.com>

Aug. 2, 2013