December 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

Yes this is the question and the effort to be different. I always thought this constraint was because of an optimization in early days such as been able to depop without taking care. Stef On Dec 24, 2008, at 10:58 AM, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > StÃ©phane Ducasse writes: >> In that case we could change that. But then we would produce >> incompatible code >> also. > > Compatibility is less of an issue for this change as Pharo will accept > more code rather than less. It will not stop us importing any code > that currently runs on Squeak unlike enforcing lower case letters for > instance variable names. > > It may be necessary to copy modified arguments with some optimised > closure implementations but that shouldn't add much complexity. The > current BlockContext implementation copies all it's arguments into the > surrounding MethodContext. > > I think Eliot's closure implementation treats modified variables > different to read only variables. However, to do this it needs > to do the analysis to find which variables are read only in a block > and which can be written to so even in this case writable arguments > will add little implementation complexity and nothing in the VM/JIT. > > This is a language design point. Is the convenience of knowing that > an argument is never modified worth more than the convenience of being > able to modify the argument? > > Bryce > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by bryce＠kampjes.demon.co.uk

StÃ©phane Ducasse writes: > In that case we could change that. But then we would produce > incompatible code > also. Compatibility is less of an issue for this change as Pharo will accept more code rather than less. It will not stop us importing any code that currently runs on Squeak unlike enforcing lower case letters for instance variable names. It may be necessary to copy modified arguments with some optimised closure implementations but that shouldn't add much complexity. The current BlockContext implementation copies all it's arguments into the surrounding MethodContext. I think Eliot's closure implementation treats modified variables different to read only variables. However, to do this it needs to do the analysis to find which variables are read only in a block and which can be written to so even in this case writable arguments will add little implementation complexity and nothing in the VM/JIT. This is a language design point. Is the convenience of knowing that an argument is never modified worth more than the convenience of being able to modify the argument? Bryce

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

then use rebol and not Smalltalk. But do not imagine that Smalltalk will be rebol. >>> StÃ©phane Ducasse wrote: >>> >>>> No it should follow well specified rules. >>>> >>> Ultimately the compiler is not really compiling smalltalk, it is >>> compiling some primitive concepts that Behaviour and friends turn in >>> to >>> smalltalk by virtue of their implementation. There is nothing >>> stopping >>> anyone one defining another language with entirely different >>> conventions. So the compiler should not enforce smalltalk rules. If >>> Behaviour/ClassDescription wants to enforce some rules then that is >>> Behaviour's business and it should be overrideable. >>> >> >> sorry I do not buy that. Do you know why Smalltalk 76 did not work >> because classes could change their syntax. >> > That sounds like a great idea to me. Ian's work on fonc also allows > that > kind of thing. > > Smalltalk is the simplest language with the least number of rules, and > least number of exceptions to the rules. This is what makes Smalltalk > stand out and what makes it powerful. So why do you think it is > virtuous > to add rules and add exceptions to rules. I always thought these > arbitrary conventions were a pain, and never saw the point in them > at all. > > For example if I implement a class with a class variable, Foo, and I > refactor it because I realise that I need it per subclass, I move it > into a class instance var, I end up having to change all the code from > Foo to foo. With these kinds of behavior why don't you also code with Uppercase everywhere. I think that this is totally insane. > The rule about globals being uppercase is another one I have broken > for > what I think is a good reason: defining null := Null default. This is because you need another pseudo variables nil true and false are exceptions to the lowercase rules. Now > > > I always find a reason to break conventions. For example in > Sake/Packages we break the convention of method names begining with a > lowercase letter, simply for readability. So I simply know in advance > that any such hard restriction is going to become a problem at some > point. Excellent like that I know that we will have to reinvent our wheel. And after you will complain that people do not look at your code... You see while browsing squeak code I'm annoyed by the empty line that people used because they used the formatted so we have empty lines everywhere for nothing. When I read you code I hate the code starting without a tab... And why because it slows me down when reading. > If it can be enshrouded as a social convention then that is good > enough, there is no need for the compiler to roll over and die. > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Keith Hodges

StÃ©phane Ducasse wrote: > On Dec 23, 2008, at 11:19 PM, Keith Hodges wrote: > > >> StÃ©phane Ducasse wrote: >> >>> No it should follow well specified rules. >>> >> Ultimately the compiler is not really compiling smalltalk, it is >> compiling some primitive concepts that Behaviour and friends turn in >> to >> smalltalk by virtue of their implementation. There is nothing stopping >> anyone one defining another language with entirely different >> conventions. So the compiler should not enforce smalltalk rules. If >> Behaviour/ClassDescription wants to enforce some rules then that is >> Behaviour's business and it should be overrideable. >> > > sorry I do not buy that. Do you know why Smalltalk 76 did not work > because classes could change their syntax. > That sounds like a great idea to me. Ian's work on fonc also allows that kind of thing. Smalltalk is the simplest language with the least number of rules, and least number of exceptions to the rules. This is what makes Smalltalk stand out and what makes it powerful. So why do you think it is virtuous to add rules and add exceptions to rules. I always thought these arbitrary conventions were a pain, and never saw the point in them at all. For example if I implement a class with a class variable, Foo, and I refactor it because I realise that I need it per subclass, I move it into a class instance var, I end up having to change all the code from Foo to foo. The rule about globals being uppercase is another one I have broken for what I think is a good reason: defining null := Null default. I always find a reason to break conventions. For example in Sake/Packages we break the convention of method names begining with a lowercase letter, simply for readability. So I simply know in advance that any such hard restriction is going to become a problem at some point. If it can be enshrouded as a social convention then that is good enough, there is no need for the compiler to roll over and die. Keith

Dec. 23, 2008

[Pharo-project] [ANN] 10201

by StÃ©phane Ducasse

removed Object>>sixxInstVarAt removed FlapTabViewer improving cleaning ThumbnailMorph First pass finished on Object for etoy cleaning Left â¢ Object (to fix later so far) â¢ presenter â¢ knownName â¢ currentVocabulary â¢ defaultNameStemForInstances â¢ externalName â¢ nameForViewer â¢ objectRepresented â¢ updateThresholdForGraphicInViewerTab â¢ uniqueNameForReferenceOrNil â¢ uniqueNameForReference started to clean ScriptingSystem

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Hilaire Fernandes

2008/12/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I think that this kind of shadowing is really not a good idea. > In VisualWorks you can do it and I really would hate code written that > way > because I would always have to keep in mind that only on certain methods > the variable I see is not the instance variable of the object but a > local > You could argue that since you redefine the variable you know it > and this could work because we have small methods but with code longer > than > a page it can be leading to bug. I agree shadowing makes code you don' t know a little harder to understand (one more item to keep in mind when reading the code)

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

In that case we could change that. But then we would produce incompatible code also. On Dec 23, 2008, at 11:26 PM, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > StÃ©phane Ducasse writes: > >>> I am just giving examples, this was discussed before. >>> >>> Since arguments are exactly the same as temps, this is just >>> something >>> the compiler is enforcing on us. Being able to assign to arguments >>> is >>> extremely useful and makes code much easier to read. Almost all >>> todays >>> programming languages (C, C++, C#, Java, Ruby, JavaScript, ...) >>> allow >>> that. >> >> I may be wrong but I imagine that this has some impact on the >> produced >> byte code and probably Jitted code too. > > The bytecode doesn't know what's an argument or what's a temp. It's > purely a Smalltalk to bytecode compiler convention. It'll have no > impact on interpreted performance, and should have none when running > JITed. > > Bryce > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

Thanks > StÃ©phane Ducasse writes: > >>> I am just giving examples, this was discussed before. >>> >>> Since arguments are exactly the same as temps, this is just >>> something >>> the compiler is enforcing on us. Being able to assign to arguments >>> is >>> extremely useful and makes code much easier to read. Almost all >>> todays >>> programming languages (C, C++, C#, Java, Ruby, JavaScript, ...) >>> allow >>> that. >> >> I may be wrong but I imagine that this has some impact on the >> produced >> byte code and probably Jitted code too. > > The bytecode doesn't know what's an argument or what's a temp. It's > purely a Smalltalk to bytecode compiler convention. It'll have no > impact on interpreted performance, and should have none when running > JITed. > > Bryce > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

On Dec 23, 2008, at 11:19 PM, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> >> No it should follow well specified rules. > Ultimately the compiler is not really compiling smalltalk, it is > compiling some primitive concepts that Behaviour and friends turn in > to > smalltalk by virtue of their implementation. There is nothing stopping > anyone one defining another language with entirely different > conventions. So the compiler should not enforce smalltalk rules. If > Behaviour/ClassDescription wants to enforce some rules then that is > Behaviour's business and it should be overrideable. sorry I do not buy that. Do you know why Smalltalk 76 did not work because classes could change their syntax. >> Else this is the mess. >> In Smalltalk uppercase are for global variables and lowercase for >> private. >> Class instance variables are only accessible from the metaclass >> methods so they should be >> lowercase. >> >> Now if a lousy compiler allows them this is the problem. >> >> > Not at all, there are times when you might want an instance variable > to > have an uppercase name. When show it to me for real. Tell me that this is because you want to connect to a C library or something like that but not for Singleton. > These kind of bending of the rules are > particularly useful when using Smalltalk as a DSL. Show me an example. We are talking about **variable** and in Smalltalk you cannot access them there is no access operator so for the DSL story it does not work. You see for the method selectors, I think that we should allow _ so that we can interoperate more easily. But for private method only accessible in side a method I do not see the point. > It is only a convention so I do not think that the compiler should > enforce it. > > > Keith > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 23, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by bryce＠kampjes.demon.co.uk

StÃ©phane Ducasse writes: > > I am just giving examples, this was discussed before. > > > > Since arguments are exactly the same as temps, this is just something > > the compiler is enforcing on us. Being able to assign to arguments is > > extremely useful and makes code much easier to read. Almost all todays > > programming languages (C, C++, C#, Java, Ruby, JavaScript, ...) allow > > that. > > I may be wrong but I imagine that this has some impact on the produced > byte code and probably Jitted code too. The bytecode doesn't know what's an argument or what's a temp. It's purely a Smalltalk to bytecode compiler convention. It'll have no impact on interpreted performance, and should have none when running JITed. Bryce

Dec. 23, 2008