- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Smalltalk = strongly typed

by kilon

" Smalltalk has types: a set of objects and the messages they understand" Nope thats not what a type is. A type is a category of data. Its that simple. Your set of objects and the messages they understand can do thousands of things. Emulating types is one of those things. Also what happens in implementation is not related to language. Implementation is one thing language is another. Also even if you see it philosophical still is very clear. Types in the end is a set of restrictions which tells "I am the language and I wont allow you to shoot yourself on the foot. I know better." Smalltalk on the other hand begs you "Hack me dude, hack me!". Smalltalk does not enforce such restrictions. But then it does not prevent you from implementing such restrictions. Afterall a static typed language does not prevents from implementing dynamic types. If it did it would be impossible to use C to create python or smalltalk. With any language there are a billion ways to skin a cat. What it differs is the things they offer out of the box .Nothing is set in stone. Carla F. Griggio wrote > Well, I've always defined a type as the a set of values and the operations > you can do with them. For example, the set of values { 1, 2, 3, 4, ... } > and the operations { + , - , * , ... } would be the type Integer. With > that > in mind, *Smalltalk has types: a set of objects and the messages they > understand*. And thanks to polymorphism a type *is not* a synonym of a > class, as instances of different objects can understand messages in > common. > So yes, "everything is an object" beacuse all objects are instances of a > class that inherits from Object, but from my point of view it's not true > that all objects are of one same type. > > Everytime an object doesn't understand a message is telling you that > you're > doing an operation on the wrong type of object. > > As some others have already said, I don't like the terms "strongly typed" > or "weakly typed" because sometimes is ambiguous, and I rather say > this: *Smalltalk > has dynamic type-checking in runtime* (instead of compilation time), > because it checks if an object can perform the operation you want (the > message) in the moment of executing that operation (when you send the > message). > > Now, talking not-so-siriously, and maybe I'm getting a little > code-philosofical here... If we take into account what I've just defined > as > a type, and knowing that all objects are instances of a class that > inherits > from Object, I think the term "unityped" should actually be replaced for > "multityped", as the same object could respond to many different types > depending on the interface its client wants it to understand. But that > happens maybe in any object-oriented program, the thing is that in > Smalltalk it's very natural and you don't even have to think about it (in > Java you would have to explicitly use 'interfaces'). > > > > > > On Sat, Aug 3, 2013 at 4:02 AM, HernÃ¡n Morales Durand < > hernan.morales@ >> wrote: > >> That is correct, there are no types in Smalltalk. >> Cheers, >> >> HernÃ¡n >> >> El 02/08/2013 15:55, Igor Stasenko escribiÃ³: >> >> I wonder if 'types' can be applied to smalltalk at all. >>> Saying it is 'unityped' language (since everything is an object) is >>> same as saying it has no types. >>> >>> Because where you need types? When you want to manipulate with data, >>> but in smalltalk all >>> data manipulation semantics is provided and implemented at primitive >>> level, but not by the language itself. >>> At language level the only semantics which is defined is message >>> passing, closures, >>> return and assignment. >>> >>> There is no any rule(s), in smalltalk at language level, saying that >>> result of expression: >>> >>> 1 + 2 >>> >>> should be of integer type. Because this is provided by implementation >>> but not defined by language itself e.g.: >>> it is just a method in corresponding class, which implemented in such >>> a way that result of expression will be instance of Integer (or >>> SmallInteger to be precise). >>> Now, if you change implementation so result will be float (or anything >>> else), will such change allow you to say, that it is no longer >>> smalltalk, or that now it is weakly typed or "anything-else typed"? >>> >>> Because smalltalk code do not operates directly with data, but only >>> with references to it (which is objects). >>> >>> Take an assignment, for example. >>> In staticly-typed language assignment copies the value of expression >>> to variable, e.g.: >>> >>> a = 10 >>> >>> "now variable a has value = 10" >>> >>> in smalltalk, assignment is not copying value, but changing the >>> reference: >>> >>> a := 10 >>> >>> "now variable a points (or refers) to object '10'" >>> >>> and thus, whatever 'type' used to represent the integer value 10 is >>> completely irrelevant >>> for assignment operation. >>> >>> >> >> -- View this message in context: http://forum.world.st/Smalltalk-strongly-typed-tp4701894p4702012.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 3, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by StÃ©phane Ducasse

On Aug 3, 2013, at 2:13 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Marcus, > > On Thu, Aug 1, 2013 at 12:33 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Aug 1, 2013, at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> since years marcus is telling that MC storing ancestor information is doomed but we do not have something to really replace it. >>> >> >> This is yet another thing. >> >> Monticello keep all history data of all package in image, this is not a cache. When you delete it, your package loses >> it's history and you can not merge anymore. >> >> MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. > > When I looked at this I noticed that there was lots of duplicate > entries in the ancestry list. I *think* this happens on merge. I > think one ends up with each of the ancestries of the merged packages > after a merge, i.e. when merging near the head one effectively doubles > the ancestry. I think Monticello should unique the ancestry, either > after a merge, or better still, before saving. This I think will > shrink the space taken by ancestry significantly. > > I have some code handy if you'd like, but its not a hard thing to do. Can you send it so that we have a look? Tx > >> >> We did that on Pharo2 release and it saved 8MB (nearly a third of the image). >> >> Marcus > > > > -- > best, > Eliot >

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Carla F. Griggio

Well, I've always defined a type as the a set of values and the operations you can do with them. For example, the set of values { 1, 2, 3, 4, ... } and the operations { + , - , * , ... } would be the type Integer. With that in mind, *Smalltalk has types: a set of objects and the messages they understand*. And thanks to polymorphism a type *is not* a synonym of a class, as instances of different objects can understand messages in common. So yes, "everything is an object" beacuse all objects are instances of a class that inherits from Object, but from my point of view it's not true that all objects are of one same type. Everytime an object doesn't understand a message is telling you that you're doing an operation on the wrong type of object. As some others have already said, I don't like the terms "strongly typed" or "weakly typed" because sometimes is ambiguous, and I rather say this: *Smalltalk has dynamic type-checking in runtime* (instead of compilation time), because it checks if an object can perform the operation you want (the message) in the moment of executing that operation (when you send the message). Now, talking not-so-siriously, and maybe I'm getting a little code-philosofical here... If we take into account what I've just defined as a type, and knowing that all objects are instances of a class that inherits from Object, I think the term "unityped" should actually be replaced for "multityped", as the same object could respond to many different types depending on the interface its client wants it to understand. But that happens maybe in any object-oriented program, the thing is that in Smalltalk it's very natural and you don't even have to think about it (in Java you would have to explicitly use 'interfaces'). On Sat, Aug 3, 2013 at 4:02 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > That is correct, there are no types in Smalltalk. > Cheers, > > HernÃ¡n > > El 02/08/2013 15:55, Igor Stasenko escribiÃ³: > > I wonder if 'types' can be applied to smalltalk at all. >> Saying it is 'unityped' language (since everything is an object) is >> same as saying it has no types. >> >> Because where you need types? When you want to manipulate with data, >> but in smalltalk all >> data manipulation semantics is provided and implemented at primitive >> level, but not by the language itself. >> At language level the only semantics which is defined is message >> passing, closures, >> return and assignment. >> >> There is no any rule(s), in smalltalk at language level, saying that >> result of expression: >> >> 1 + 2 >> >> should be of integer type. Because this is provided by implementation >> but not defined by language itself e.g.: >> it is just a method in corresponding class, which implemented in such >> a way that result of expression will be instance of Integer (or >> SmallInteger to be precise). >> Now, if you change implementation so result will be float (or anything >> else), will such change allow you to say, that it is no longer >> smalltalk, or that now it is weakly typed or "anything-else typed"? >> >> Because smalltalk code do not operates directly with data, but only >> with references to it (which is objects). >> >> Take an assignment, for example. >> In staticly-typed language assignment copies the value of expression >> to variable, e.g.: >> >> a = 10 >> >> "now variable a has value = 10" >> >> in smalltalk, assignment is not copying value, but changing the reference: >> >> a := 10 >> >> "now variable a points (or refers) to object '10'" >> >> and thus, whatever 'type' used to represent the integer value 10 is >> completely irrelevant >> for assignment operation. >> >> > >

Aug. 3, 2013

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

by StÃ©phane Ducasse

In fact we say that closure capture variables but they capture "location" or access to variables. I will reread what I wrote I gave some examples in the forth coming book Deep into Pharo :) http://rmod.lille.inria.fr/pbe2/ On Aug 2, 2013, at 3:35 PM, 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). > > >> 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. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by HernÃ¡n Morales Durand

That is correct, there are no types in Smalltalk. Cheers, HernÃ¡n El 02/08/2013 15:55, Igor Stasenko escribiÃ³: > I wonder if 'types' can be applied to smalltalk at all. > Saying it is 'unityped' language (since everything is an object) is > same as saying it has no types. > > Because where you need types? When you want to manipulate with data, > but in smalltalk all > data manipulation semantics is provided and implemented at primitive > level, but not by the language itself. > At language level the only semantics which is defined is message > passing, closures, > return and assignment. > > There is no any rule(s), in smalltalk at language level, saying that > result of expression: > > 1 + 2 > > should be of integer type. Because this is provided by implementation > but not defined by language itself e.g.: > it is just a method in corresponding class, which implemented in such > a way that result of expression will be instance of Integer (or > SmallInteger to be precise). > Now, if you change implementation so result will be float (or anything > else), will such change allow you to say, that it is no longer > smalltalk, or that now it is weakly typed or "anything-else typed"? > > Because smalltalk code do not operates directly with data, but only > with references to it (which is objects). > > Take an assignment, for example. > In staticly-typed language assignment copies the value of expression > to variable, e.g.: > > a = 10 > > "now variable a has value = 10" > > in smalltalk, assignment is not copying value, but changing the reference: > > a := 10 > > "now variable a points (or refers) to object '10'" > > and thus, whatever 'type' used to represent the integer value 10 is > completely irrelevant > for assignment operation. >

Aug. 3, 2013

Re: [Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

by Eliot Miranda

Hi Marcus, On Thu, Aug 1, 2013 at 12:33 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Aug 1, 2013, at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> since years marcus is telling that MC storing ancestor information is doomed but we do not have something to really replace it. >> > > This is yet another thing. > > Monticello keep all history data of all package in image, this is not a cache. When you delete it, your package loses > it's history and you can not merge anymore. > > MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. When I looked at this I noticed that there was lots of duplicate entries in the ancestry list. I *think* this happens on merge. I think one ends up with each of the ancestries of the merged packages after a merge, i.e. when merging near the head one effectively doubles the ancestry. I think Monticello should unique the ancestry, either after a merge, or better still, before saving. This I think will shrink the space taken by ancestry significantly. I have some code handy if you'd like, but its not a hard thing to do. > > We did that on Pharo2 release and it saved 8MB (nearly a third of the image). > > Marcus -- best, Eliot

Aug. 3, 2013

flash: does not work in Pharo 3.0

by StÃ©phane Ducasse

Display flash: (0@0 corner: 200@200) does not work on Pharo 30 while it was working on 2.0. It looks that this is VM related because on the linux of laurent it is working. I'm too tired to get how to extract the VM versionâ¦. I tried --version and others but it did not work. pharo -version bin unknown option: -version Usage: [<option>...] [<imageName> [<argument>...]] [<option>...] -- [<argument>...] Common <option>s: -help print this help message, then exit -memory <size>[mk] use fixed heap size (added to image size) -headless run in headless (no window) mode (default: false) Notes: <imageName> defaults to `Squeak.image'. If `-memory' is not specified then the heap will grow dynamically. <argument>s are ignored, but are processed by the Squeak image. The first <argument> normally names a Squeak `script' to execute. Precede <arguments> by `--' to use default image. bin pharo -version 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 ' Stef too tired and exhausted to think

Aug. 2, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Alain Plantec

Hi Ben, Thanks for the references, I've also found this post interesting: http://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-… Cheers Alain 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

drawReverseFrame: is strange because it does not use self

by StÃ©phane Ducasse

Rectangle>>drawReverseFrame: rect Display border: rect width: 2 rule: Form reverse fillColor: Color gray and force user to create a dummy rectangle to invoke it. Stef

Aug. 2, 2013

Why we should run SmallLint

by StÃ©phane Ducasse

convertFromCompoundText | readStream converter | readStream := self readStream. ^ self class new: self size streamContents: [ :writeStream| converter := CompoundTextConverter new. converter ifNil: [^ self]. [readStream atEnd] whileFalse: [ writeStream nextPut: (converter nextFromStream: readStream)]]. CompoundTextConverter new -> DNU convertFromSystemString | readStream converter | readStream := self readStream. ^ self class new: self size streamContents: [ :writeStream| converter := LanguageEnvironment defaultSystemConverter. converter ifNil: [^ self]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [readStream atEnd] whileFalse: [ writeStream nextPut: (converter nextFromStream: readStream)]]. systemConverterClass self subclassResponsibility. ^ Latin1TextConverter. What!!!! Stef

Aug. 2, 2013