- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Smalltalk = strongly typed

by kilon

btc wrote > btc@ > wrote: > > Kilon, I agree with most of you writeup, except that I think Smalltalk > has types - except the types are not associated with variables, rather > they are associated with objects. This aligns with Igor's comment "in > smalltalk, assignment is not copying value, but changing the reference". Actually I also mostly agree with Igor point. If I am not mistake we agree on the fact that smalltalk has no types. The only thing I would not agree, if my assumption is correct here, is that Igor appears here implying that smalltalk somehow is special to assign values by reference. If this assumption of mine is correct then I do disagree strongly , its actually a very common practice. Python also implement this, Lisp does, ruby and an array of dynamic type languages. I am not so sure about C and C++ but since they use pointers its a moot point anyway. I explain this concept in my book about python that I have published in blenderwiki , section "Reference" which can be found here -> http://wiki.blender.org/index.php/User:Kilon/Python_book_of_magic/05.Dictio… However this concept is implementation specific and not language specific. Its obviously a massive diffirence because a coder rarely worries about the implementation itself the same way a user of an OS does not worry how and why an OS does the things it does, he only care about what it does. Also I am not sure how that prove the existence of types, for me it does not, it only describes how values are assigned. What prevents you from assigning by reference typeless data ? Unless once again we talk about how pharo itself implement this and somehow uses its own internal type system. The question that remain why I the coder should care about this , if at language level Smalltalk is typeless. Maybe Igor can clarify this more to make a more clear picture what happens at implementation level. But at language level yes I have seen nothing that proves the existence of types inside Smalltalk unless we treat types in a very vague kind way which for me it just defeats their purpose. I also agree on the remark of Duck Typing , it definitely smells like smalltalk , but once again the terminology is failed because it implies a type system. Once more I have to stress the importance of dichotomy between language specification and language implementation. Types obviously touch both areas but not necessarily for same reasons. -- View this message in context: http://forum.world.st/Smalltalk-strongly-typed-tp4701894p4702028.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 3, 2013

SimpleMIDIPort midiIsSupported returns the first time false and after all the time true :)

by StÃ©phane Ducasse

Strange May be the logic in the primitive is strange. midiIsSupported "Answer true if this platform supports MIDI." ^ self primPortCount > 0 primPortCount "Answer the number of MIDI ports supported by this platform, or zero if this primitive is not implemented." <primitive: 'primitiveMIDIGetPortCount' module: 'MIDIPlugin'> ^ 0 Stef

Aug. 3, 2013

Re: [Pharo-dev] is the apply in the merge tool working?

by StÃ©phane Ducasse

I checked the code and it does not apply immediately the changes so it looks like it i redundant with keep current or keep incoming. Stef On Aug 3, 2013, at 7:09 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Because when I merge and I click on apply the change is not applied in the image (when I do not accept the button in the merge tool)? > > Stef

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by btc＠openinworld.com

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 > > Thank you all for you responses. I am integrating it all into a section of my report, which I'll paste in a bit for you to pick holes in. I few quick responses.... I agree with Igor and Camille, statically-typed & strongly-typed should not be synonyms - but as Esteban says, it is common usage - but I think that doesn't make it right. I think this is due to statically-typed languages tightly associating types with variables, whereas types exist independently from variables. Milan, To clarify, it doesn't prevent the *error*. What it does is prevent the *operation*. Since a MNU is produced the specified operation did not execute. Igor gives a good example of why C is weakl typed. Camille, I take your point about defining "Strongly Typed" , which I will do in my report. Kilon, I agree with most of you writeup, except that I think Smalltalk has types - except the types are not associated with variables, rather they are associated with objects. This aligns with Igor's comment "in smalltalk, assignment is not copying value, but changing the reference". Enrico, I will cover Duck Typing, thanks. The implication is, if Duck Typing applies to Smalltalk, then types *are* part of Smalltalk. Alain, Thanks for the link. To much to respond to here. Bits should end up in my report. I found this compelling, as it clarify my own thinking along the same lines "Statically typed languages assign types to variables, while dynamically typed languages assign types to values" Hernan, I disagree that Smalltalk has no types. But they apply to objects rather than variables, which is where it breaks down for the explicitly/statically typed crowd. Carla, I am thinking along those lines. A type groups data and valid operations. In non-OO languages, the data and operations are separated, so the type is associated with a variable, which defines what operations are valid on the variable, and hence on the data within the variable. In OO/Smalltalk, the data and operations a combined, so type is associated with the object, which defines what operations are valid on the object, and hence the data within the object. Juan, I agree with your first post that Smalltalk is strongly typed. Discussing of multi-typed is beyond what I need to consider for my report. German, That paper states "Smalltalk, although an untype language" but the goes on to indicate many times that Smalltalk has types eg "subtype polymorphism of Smalltalk" I think it is common to say "Smalltalk is untyped" but actually the correct statement should be "In Smalltalk, the *variables* are untyped" I'll paste something in more detail soon. Thanks again. All good points to round out my discussion. cheers -ben

Aug. 3, 2013

Still broken Date comparaison in 2.0?

by hilaire

Instances value from stacking GrowlMorphs: TimeStamp now -> 4 August 2013 1:18:30 am vanishTime -> 4 August 2013 12:51:51.62 am TimeStamp now < vanishTime ->true Inspectors: <http://forum.world.st/file/n4702023/TimesStampInspectors.png> Hilaire -- View this message in context: http://forum.world.st/Still-broken-Date-comparaison-in-2-0-tp4702023.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 3, 2013

is the apply in the merge tool working?

by StÃ©phane Ducasse

Because when I merge and I click on apply the change is not applied in the image (when I do not accept the button in the merge tool)? Stef

Aug. 3, 2013

cleaning AppRegistry and Sound/SoundService...

by StÃ©phane Ducasse

Hi guys I wonder what we can do about AppRegistry I imagine that we can remove MailSender. I'm going over the code on the image as well as http://code.google.com/p/pharo/issues/detail?id=6996 and pavel changes. Any feedback is welcome. Stef

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by GermÃ¡n Leiva

The term "strongly typed" is ambiguos and this thread is the living proof of that. In the introduction of http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf Luca Cardelli talks about untyped universes and later about Smalltalk. For me Smalltalk is a dynamically typed language with implicit type definitions and dynamic type checking. As Esteban said in the industry is really common to hear strongly typed = static type checking, in the academia the term it's used for more than one thing (http://en.m.wikipedia.org/wiki/Strong_and_weak_typing) so in order to avoid miscommunications I prefer the concepts "type declaration" (implicit vs explicit) and "type-checking" (dynamic, static or no type checking at all). Cheers, On Saturday, August 3, 2013, Juan Vuletich (mail lists) wrote: > BTW, I especially like the idea that Smalltalk is Multityped, as an object > can respond to several protocols/interfaces/type specs. So true! > > Quoting "Carla F. Griggio" <carla.griggio(a)gmail.com <javascript:_e({}, > 'cvml', 'carla.griggio(a)gmail.com');>>: > > 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 <javascript:_e({}, 'cvml', > '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. >>> >>> >> >> > Cheers, > Juan Vuletich > -- GermÃ¡n Leiva LeivaGerman(a)gmail.com

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Juan Vuletich (mail lists)

BTW, I especially like the idea that Smalltalk is Multityped, as an object can respond to several protocols/interfaces/type specs. So true! Quoting "Carla F. Griggio" <carla.griggio(a)gmail.com>: > 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. Cheers, Juan Vuletich

Aug. 3, 2013

Re: [Pharo-dev] Smalltalk = strongly typed

by Juan Vuletich (mail lists)

I fully agree with you. Just a detail. "strongly typed" or "weakly typed" is not ambiguous. Weakly typed means that the system can not guarantee that the types are known and behavior is consistent with them. The main example is C, where a pointer can point to anything, and often there is no type checking. Smalltalk is as strongly typed as Pascal: the type system is always as advertised. Quoting "Carla F. Griggio" <carla.griggio(a)gmail.com>: > 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. Cheers, Juan Vuletich

Aug. 3, 2013