[Pharo-project] On not unnecessarily closing down the language
Seaside depends on external packages, that we don't have control over. For example there the Swazoo package contains a class-instance variable that is uppercase. Unfortunately Pharo throws a notification (instance variables should begin with a lower case characters) when loading that code. This is awkward, because it makes it impossible to load code automatically and gives us additional work. In my opinion a programming language should be as open as possible, and if possible not restrict the user in any way, even if this is against best practices. Unfortunately many of those restrictions are built into our language that wouldn't be necessary: - class names and class-variable names are enforced to be uppercase - class instance-variable names are enforced to be lowercase - it is not possible to assign a new value to a method argument - variable names are enforced to be unique in all scopes In my opinion the language should be as open as possible. It is the purpose of Code Critics to point out smells, not the task of the compiler to reject code that doesn't follow best practices. I am slightly frustrated trying to work around these restrictions ... Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
+1 Jim -- Jim Menard, jimm@io.com, jim.menard@gmail.com http://www.io.com/~jimm/
On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote:
Seaside depends on external packages, that we don't have control over.
For example there the Swazoo package contains a class-instance variable that is uppercase.
Can you tell me which one so that I ask Janko to fix it?
Unfortunately Pharo throws a notification (instance variables should begin with a lower case characters) when loading that code.
May be we should have a way to trap that exception.
This is awkward, because it makes it impossible to load code automatically and gives us additional work.
In my opinion a programming language should be as open as possible, and if possible not restrict the user in any way, even if this is against best practices. Unfortunately many of those restrictions are built into our language that wouldn't be necessary:
- class names and class-variable names are enforced to be uppercase - class instance-variable names are enforced to be lowercase
I really think that this is good. Else what is the point to have a syntax?
- it is not possible to assign a new value to a method argument
This was always like that in Smalltalk. Arguments are ready only.
- variable names are enforced to be unique in all scopes
This is the limit of the current compiler and not having full block closure I imagine.
In my opinion the language should be as open as possible.
No it should follow well specified rules. 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.
It is the purpose of Code Critics to point out smells, not the task of the compiler to reject code that doesn't follow best practices.
I am slightly frustrated trying to work around these restrictions ...
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
lukas would a preference help? Stef On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote:
Seaside depends on external packages, that we don't have control over.
For example there the Swazoo package contains a class-instance variable that is uppercase. Unfortunately Pharo throws a notification (instance variables should begin with a lower case characters) when loading that code. This is awkward, because it makes it impossible to load code automatically and gives us additional work.
In my opinion a programming language should be as open as possible, and if possible not restrict the user in any way, even if this is against best practices. Unfortunately many of those restrictions are built into our language that wouldn't be necessary:
- class names and class-variable names are enforced to be uppercase - class instance-variable names are enforced to be lowercase - it is not possible to assign a new value to a method argument - variable names are enforced to be unique in all scopes
In my opinion the language should be as open as possible. It is the purpose of Code Critics to point out smells, not the task of the compiler to reject code that doesn't follow best practices.
I am slightly frustrated trying to work around these restrictions ...
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Can you tell me which one so that I ask Janko to fix it?
It is the class instance-variable Singleton in SwazooBenchmarks.
Unfortunately Pharo throws a notification (instance variables should begin with a lower case characters) when loading that code.
May be we should have a way to trap that exception.
I don't think this will be the only problem we encounter. I reported this issue, because I am afraid that Pharo makes porting unnecessary hard and unnecessarily restricts the language.
- class names and class-variable names are enforced to be uppercase - class instance-variable names are enforced to be lowercase
I really think that this is good. Else what is the point to have a syntax?
This is not part of the Smalltalk syntax. The syntax only says that a variable is a letter followed by zero or more letters or digits.
- it is not possible to assign a new value to a method argument
This was always like that in Smalltalk. Arguments are ready only.
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.
- variable names are enforced to be unique in all scopes
This is the limit of the current compiler and not having full block closure I imagine.
What I ment was more the fact that it is not possible to give a temp-var the same name as an inst-var of the owning class. Or an inst-var the same name as a global-var. Again, most todays programming languages allow that. This is an unnecessary restrictions.
In my opinion the language should be as open as possible.
No it should follow well specified rules. Else this is the mess. In Smalltalk uppercase are for global variables and lowercase for private.
Anyway, we don't have to agree on Smalltalk in general ;-) The only problem I have right now is that Seaside with Swazoo doesn't load into the latest Pharo, because the compiler disallows uppercase class instance-variables. It is not an unsolvable problem, but we have to figure out a nasty hack to make the load-script silently load the code. And the maintainers of Package Universe and Monticello Configurations will have to figure out similar patches to work around the Pharo Class builder. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
would a preference help?
Not really. You don't want to explain that to users and ask them to change their settings before loading Seaside code? <rant> What if we would integrate Code Critics in the ClassBuilder and throw an error whenever we try to compile a class that does not satisfy on of the included rules? For sure, that would lead to high quality code. It is easy to imagine though, that such an approach makes it nearly impossible to do anything useful anymore. </rant> Code Critics can be run independently of the compilation and is able to point out violations of common patterns, like the fact that instance variables should be lowercase. Personally I try to follow most Code Critics rules, even if it makes sense to do it different in some cases. I am in favour of naming instance variables in lowercase, however this is not something the compiler should enforce. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Dec 23, 2008, at 10:25 PM, Lukas Renggli wrote:
Can you tell me which one so that I ask Janko to fix it?
It is the class instance-variable Singleton in SwazooBenchmarks.
Unfortunately Pharo throws a notification (instance variables should begin with a lower case characters) when loading that code.
May be we should have a way to trap that exception.
I don't think this will be the only problem we encounter. I reported this issue, because I am afraid that Pharo makes porting unnecessary hard and unnecessarily restricts the language.
Sure please continue this is important to learn from that.
- class names and class-variable names are enforced to be uppercase - class instance-variable names are enforced to be lowercase
I really think that this is good. Else what is the point to have a syntax?
This is not part of the Smalltalk syntax. The syntax only says that a variable is a letter followed by zero or more letters or digits.
But the books I read were really mentioning that the uppercase indicated scope. lower private upper global. I thought it is rather cool to have such conventions that are ready standing out. And this can be part of the syntax of a language. Why Smalltalker wants always not to care. A bit of regularity does not hurt. Then in that case why Class name do not start with lowercase and instance variables with Uppercase if the compiler allows it then this is cool let us use it.
- it is not possible to assign a new value to a method argument
This was always like that in Smalltalk. Arguments are ready only.
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.
- variable names are enforced to be unique in all scopes
This is the limit of the current compiler and not having full block closure I imagine.
What I ment was more the fact that it is not possible to give a temp-var the same name as an inst-var of the owning class.
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.
Or an inst-var the same name as a global-var.
How this is possible since a global should be uppercased and a instance variable lowercase?
Again, most todays programming languages allow that. This is an unnecessary restrictions.
Can you show us a case where this is useful? in ambientalk I could be convinced but ambientalk as block srtucture (nested object). In languages with block structure it is convenient but in Smalltalk with its flat structure I do not see why this is so important? (C, C++, C#, Java, Ruby, JavaScript, ...) they do not have the same program structure than Smalltalk program. In VisualWorks you can have block argument having the same name as instance variable now it is really good? This means that you cannot access the instance variable from the block internal directly. Ok you can you use a self send. Now I think that using the same name for two lexically different variable is not really cool.
In my opinion the language should be as open as possible.
No it should follow well specified rules. Else this is the mess. In Smalltalk uppercase are for global variables and lowercase for private.
Anyway, we don't have to agree on Smalltalk in general ;-)
The only problem I have right now is that Seaside with Swazoo doesn't load into the latest Pharo, because the compiler disallows uppercase class instance-variables. It is not an unsolvable problem, but we have to figure out a nasty hack to make the load-script silently load the code. And the maintainers of Package Universe and Monticello Configurations will have to figure out similar patches to work around the Pharo Class builder.
I think that we should have a preference to deal with that.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Dec 23, 2008, at 10:41 PM, Lukas Renggli wrote:
would a preference help?
Not really. You don't want to explain that to users and ask them to change their settings before loading Seaside code?
<rant> What if we would integrate Code Critics in the ClassBuilder and throw an error whenever we try to compile a class that does not satisfy on of the included rules? For sure, that would lead to high quality code. It is easy to imagine though, that such an approach makes it nearly impossible to do anything useful anymore. </rant>
Why anything useful anymore? hijakcing Uppercase for private instance variable is not really good. This Singleton is NOT a globally accessible variable so why using Uppercase just because the compiler is weak.
Code Critics can be run independently of the compilation and is able to point out violations of common patterns, like the fact that instance variables should be lowercase. Personally I try to follow most Code Critics rules, even if it makes sense to do it different in some cases. I am in favour of naming instance variables in lowercase, however this is not something the compiler should enforce.
It is. This is the job of the compiler to reject code not following basic rules. Of course you can externalize the checks. But then what is a valid program? But indeed we should run code critics and build a good set of rules. I would love to do that.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
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. These kind of bending of the rules are particularly useful when using Smalltalk as a DSL. It is only a convention so I do not think that the compiler should enforce it. Keith
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In that case we could change that. But then we would produce incompatible code also. On Dec 23, 2008, at 11:26 PM, <bryce@kampjes.demon.co.uk> <bryce@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/12/23 Stéphane Ducasse <stephane.ducasse@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)
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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@kampjes.demon.co.uk> <bryce@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Dec 24, 2008 at 10:58 AM, <bryce@kampjes.demon.co.uk> wrote:
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?
What really is the convenience of modifying an argument? Having not to think up another name? I never understood this argument especially if you need to use the original value of the argument in several places. IMHO it is all about how much mental load reading code imposes (the readability Stephane mentioned). If we allow modification of arguments, then I can't just look at code and "know" that the argument has the value it was passed. Same with shadowed variables, a truly horrible idea. I look at code and see an inst var, but fail to notice it is also an argument or method var and I'm off being confused about what the code does. Same for upper/lowercase conventions, let alone uppercase method names. Breaking the kind of conventions makes you think harder about what code does and that distracts you from what you really trying to do. Or should be doing ;-) Michael
+1 even if I understand since from time to time I need to add a new local to modify an arg. Now I have the impression that when I have to do that it may be better to have an instance variable instead. Stef On Dec 24, 2008, at 11:11 AM, Michael Rueger wrote:
On Wed, Dec 24, 2008 at 10:58 AM, <bryce@kampjes.demon.co.uk> wrote:
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?
What really is the convenience of modifying an argument? Having not to think up another name? I never understood this argument especially if you need to use the original value of the argument in several places.
IMHO it is all about how much mental load reading code imposes (the readability Stephane mentioned).
If we allow modification of arguments, then I can't just look at code and "know" that the argument has the value it was passed.
Same with shadowed variables, a truly horrible idea. I look at code and see an inst var, but fail to notice it is also an argument or method var and I'm off being confused about what the code does.
Same for upper/lowercase conventions, let alone uppercase method names.
Breaking the kind of conventions makes you think harder about what code does and that distracts you from what you really trying to do. Or should be doing ;-)
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Michael Rueger wrote:
On Wed, Dec 24, 2008 at 10:58 AM, <bryce@kampjes.demon.co.uk> wrote:
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?
What really is the convenience of modifying an argument? Having not to
Breaking the kind of conventions makes you think harder about what code does and that distracts you from what you really trying to do. Or should be doing ;-)
But you are not getting it. The point is about context. In the context of smalltalk the conventions make sense. BUT the whole point being there are other contexts even within the same environment. Sake/Packages uses a smalllalk class as a database of package definitions, this is another context. My Mantis package uses a class to document fixes this is another context. Class returns #compilerClass, this means it is possible to put a different compiler in there. Therefore it is expected that there be different contexts within the one environment. I am not saying that the smalltalk conventions are bad, what I am saying is that the flexibility to break the conventions is useful in OTHER CONTEXTS, and in many ways makes it possible to have other use cases in the first place. Keith
On Wed, Dec 24, 2008 at 12:30 PM, Keith Hodges <keith_hodges@yahoo.co.uk> wrote:
I am not saying that the smalltalk conventions are bad, what I am saying is that the flexibility to break the conventions is useful in OTHER CONTEXTS, and in many ways makes it possible to have other use cases in the first place.
Then break them in the other contexts, but not for the whole system. If you allow abuse of the language, people will do it. Michael
Michael Rueger wrote:
On Wed, Dec 24, 2008 at 12:30 PM, Keith Hodges <keith_hodges@yahoo.co.uk> wrote:
I am not saying that the smalltalk conventions are bad, what I am saying is that the flexibility to break the conventions is useful in OTHER CONTEXTS, and in many ways makes it possible to have other use cases in the first place.
Then break them in the other contexts, but not for the whole system.
If you allow abuse of the language, people will do it.
But what is the Language? Smalltalk is objects and message sends thats all (at least thats the theory). Whenever this simplicity is compromised then there are problems down the road (e.g. inlining ifTrue:ifFalse: limits the ability to change its behavior and people find a need to diable this inlining) No conventions need to be hard wired. Its the same debate as static vs dynamic typing all over again. Keith
I do not think that a preference should relax some static language enforcements. Contrary to Java, the Smalltalk community does not appear to be big enough to have these problem unsolvable. I agree with Stephane, having a name that begins with a capitalized letter has a strong connotation of global visibility. And, on the contrary, an identifier beginning with a small letter has a restricted scope. Forbidding a new value to be assigned to a method variable is a simple increase the readability. Even if closure were supported, we should not allow a single identifier to appear as argument in different blocks in the same method. This does not help readability. As a follower to that line, something that would be great to have, is to forbid accesses to an undefined variable. I am aware that I am talking as someone who does not maintain cross- dialect applications, but we cannot trade readability for a local in time commodity. Alexandre On 23 Dec 2008, at 18:02, Stéphane Ducasse wrote:
lukas
would a preference help?
Stef
On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote:
Seaside depends on external packages, that we don't have control over.
For example there the Swazoo package contains a class-instance variable that is uppercase. Unfortunately Pharo throws a notification (instance variables should begin with a lower case characters) when loading that code. This is awkward, because it makes it impossible to load code automatically and gives us additional work.
In my opinion a programming language should be as open as possible, and if possible not restrict the user in any way, even if this is against best practices. Unfortunately many of those restrictions are built into our language that wouldn't be necessary:
- class names and class-variable names are enforced to be uppercase - class instance-variable names are enforced to be lowercase - it is not possible to assign a new value to a method argument - variable names are enforced to be unique in all scopes
In my opinion the language should be as open as possible. It is the purpose of Code Critics to point out smells, not the task of the compiler to reject code that doesn't follow best practices.
I am slightly frustrated trying to work around these restrictions ...
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
+ 1 Alexandre On 24 Dec 2008, at 07:11, Michael Rueger wrote:
On Wed, Dec 24, 2008 at 10:58 AM, <bryce@kampjes.demon.co.uk> wrote:
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?
What really is the convenience of modifying an argument? Having not to think up another name? I never understood this argument especially if you need to use the original value of the argument in several places.
IMHO it is all about how much mental load reading code imposes (the readability Stephane mentioned).
If we allow modification of arguments, then I can't just look at code and "know" that the argument has the value it was passed.
Same with shadowed variables, a truly horrible idea. I look at code and see an inst var, but fail to notice it is also an argument or method var and I'm off being confused about what the code does.
Same for upper/lowercase conventions, let alone uppercase method names.
Breaking the kind of conventions makes you think harder about what code does and that distracts you from what you really trying to do. Or should be doing ;-)
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I agree with you Keith. As you pointed out, redefining compilerClass should allow you to relax the rules we are talking about. Alexandre On 24 Dec 2008, at 08:30, Keith Hodges wrote:
Michael Rueger wrote:
On Wed, Dec 24, 2008 at 10:58 AM, <bryce@kampjes.demon.co.uk> wrote:
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?
What really is the convenience of modifying an argument? Having not to
Breaking the kind of conventions makes you think harder about what code does and that distracts you from what you really trying to do. Or should be doing ;-)
But you are not getting it. The point is about context. In the context of smalltalk the conventions make sense. BUT the whole point being there are other contexts even within the same environment.
Sake/Packages uses a smalllalk class as a database of package definitions, this is another context. My Mantis package uses a class to document fixes this is another context.
Class returns #compilerClass, this means it is possible to put a different compiler in there. Therefore it is expected that there be different contexts within the one environment.
I am not saying that the smalltalk conventions are bad, what I am saying is that the flexibility to break the conventions is useful in OTHER CONTEXTS, and in many ways makes it possible to have other use cases in the first place.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Dec 24, 2008, at 3:13 PM, Alexandre Bergel wrote:
I do not think that a preference should relax some static language enforcements. Contrary to Java, the Smalltalk community does not appear to be big enough to have these problem unsolvable.
I agree with Stephane, having a name that begins with a capitalized letter has a strong connotation of global visibility. And, on the contrary, an identifier beginning with a small letter has a restricted scope.
Forbidding a new value to be assigned to a method variable is a simple increase the readability. Even if closure were supported, we should not allow a single identifier to appear as argument in different blocks in the same method. This does not help readability.
As a follower to that line, something that would be great to have, is to forbid accesses to an undefined variable.
or we should have a tool that point us to the shadowing. :)
I am aware that I am talking as someone who does not maintain cross- dialect applications, but we cannot trade readability for a local in time commodity.
Alexandre
On 23 Dec 2008, at 18:02, Stéphane Ducasse wrote:
lukas
would a preference help?
Stef
On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote:
Seaside depends on external packages, that we don't have control over.
For example there the Swazoo package contains a class-instance variable that is uppercase. Unfortunately Pharo throws a notification (instance variables should begin with a lower case characters) when loading that code. This is awkward, because it makes it impossible to load code automatically and gives us additional work.
In my opinion a programming language should be as open as possible, and if possible not restrict the user in any way, even if this is against best practices. Unfortunately many of those restrictions are built into our language that wouldn't be necessary:
- class names and class-variable names are enforced to be uppercase - class instance-variable names are enforced to be lowercase - it is not possible to assign a new value to a method argument - variable names are enforced to be unique in all scopes
In my opinion the language should be as open as possible. It is the purpose of Code Critics to point out smells, not the task of the compiler to reject code that doesn't follow best practices.
I am slightly frustrated trying to work around these restrictions ...
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Same with shadowed variables, a truly horrible idea. I look at code and see an inst var, but fail to notice it is also an argument or method var and I'm off being confused about what the code does.
I never heard of a JavaScript, Java, C, C++, Ruby, Python, or Scheme programmer complain about shadowed variables. It makes sense to refer to a variable closest in scope shadowing those with the same name farther away.
or we should have a tool that point us to the shadowing. :)
Code Critics already does that today.
If you allow abuse of the language, people will do it.
Of course. That's why we have thisContext, #perform:, #become:, #nextInstance, #isKindOf:, #instVarAt:, etc. That's why we have Code Critics that reminds people to be careful about these things. That's also the reason why there is Seaside. And that's why there is no Seaside for Java.
Same for upper/lowercase conventions, let alone uppercase method names.
Breaking the kind of conventions makes you think harder about what code does and that distracts you from what you really trying to do. Or should be doing ;-)
I like the metaphor of global being uppercase and local being lowercase. I don't see a point enforcing that though: The meaning of global and local is rather arbitrary. In the context of the subclasses of a class all instance variables are global. In the context of a method the method arguments are global as well. There is a big difference between syntax and coding conventions: 1. Syntax: This is what the compiler can compile unambiguous. This is the syntax as found in the back of the Smalltalk-80 book. This is the grammar that deterministically decides if a program can be compiled or not. For portability it should follow the ANSI standard as close as possible. Note that the ANSI standard does not restrict names of globals, classes, inst-vars, class inst-vars, class-vars, pools, methods, temps, ... in any way: they are all identifiers, starting with an upper or lowercase letter, followed by zero or more letters or digits. If it is decided to restrict these names, Pharo won't be ANSI compatible anymore. 2. Coding Conventions: This is what the community decides to follow and what every serious open source project should publish somewhere on the web. This includes rules like "temps and instance variables are lowercase" or "code is formatted with tabs and there are no empty lines". For Seaside we have such rules and we rigorously reject/rewrite code that does not follow these guidelines, see <http://www.seaside.st/community/conventions>. We use Code Critics to detect violations against these rules or to automatically fix poroblems. This ensures a high quality of the core code, but still enables other parties to write and use code that does not follow these conventions. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Wed, Dec 24, 2008 at 15:13, Alexandre Bergel <alexandre@bergel.eu> wrote:
I do not think that a preference should relax some static language enforcements.
Rule of thumb: if you just thought "maybe a preference would fix thatâ¦" then you're avoiding the real problem :) I think the initial concern of Lukas is that it's a practical burden to him if Pharo becomes too restrictive to load Seaside. So either there is Swazoo and a couple other easy problems, and they should be fixed quickly, or it's too much work to do the fixes and the compiler should stay a bit permissive for the moment. Or Seaside doesn't work on Pharo for some time. So I agree the conventions should be documented and breaking them discouraged, but in practice it's probably more valuable to have Seaside loading nicely than to have nice code NOW, and handle the problem with a transition period like with deprecated methods.
I agree with Stephane, having a name that begins with a capitalized letter has a strong connotation of global visibility. And, on the contrary, an identifier beginning with a small letter has a restricted scope.
Also in Ruby: $global @instVar @@classInstVar â¦and in Java: int anInteger; Yes, enforcing is like static typing, and Code Critics is like pluggable type systems :)
Forbidding a new value to be assigned to a method variable is a simple increase the readability.
Why ? they are defined once at the beginning of the method, just not between the | |; I think of them as locals that just get initialized to something else than nil⦠Now maybe I don't see the problem because I'm not used to C so it wouldn't even occur to me that assigning to parameters could have an effect on the caller.
Even if closure were supported, we should not allow a single identifier to appear as argument in different blocks in the same method. This does not help readability.
Huh, do you really want to use :each1 :each2 :each3 if you have three loops in the method ?
As a follower to that line, something that would be great to have, is to forbid accesses to an undefined variable.
What if you remove the variable definition from the class ? Do you want the compiler to force you to remove all uses immediately ?
I am aware that I am talking as someone who does not maintain cross- dialect applications, but we cannot trade readability for a local in time commodity.
Sure, but we could try to make the transition easier (e.g., complain to Janko for the moment and wait until Pharo stable to enforce conventions)
Alexandre
On 23 Dec 2008, at 18:02, Stéphane Ducasse wrote:
lukas
would a preference help?
Stef
On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote:
Seaside depends on external packages, that we don't have control over.
For example there the Swazoo package contains a class-instance variable that is uppercase. Unfortunately Pharo throws a notification (instance variables should begin with a lower case characters) when loading that code. This is awkward, because it makes it impossible to load code automatically and gives us additional work.
In my opinion a programming language should be as open as possible, and if possible not restrict the user in any way, even if this is against best practices. Unfortunately many of those restrictions are built into our language that wouldn't be necessary:
- class names and class-variable names are enforced to be uppercase - class instance-variable names are enforced to be lowercase - it is not possible to assign a new value to a method argument - variable names are enforced to be unique in all scopes
In my opinion the language should be as open as possible. It is the purpose of Code Critics to point out smells, not the task of the compiler to reject code that doesn't follow best practices.
I am slightly frustrated trying to work around these restrictions ...
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
Yes I contacted Janko if he can fix that On Dec 24, 2008, at 5:25 PM, Damien Pollet wrote:
On Wed, Dec 24, 2008 at 15:13, Alexandre Bergel <alexandre@bergel.eu> wrote:
I do not think that a preference should relax some static language enforcements.
Rule of thumb: if you just thought "maybe a preference would fix thatâ¦" then you're avoiding the real problem :)
I think the initial concern of Lukas is that it's a practical burden to him if Pharo becomes too restrictive to load Seaside. So either there is Swazoo and a couple other easy problems, and they should be fixed quickly, or it's too much work to do the fixes and the compiler should stay a bit permissive for the moment. Or Seaside doesn't work on Pharo for some time.
So I agree the conventions should be documented and breaking them discouraged, but in practice it's probably more valuable to have Seaside loading nicely than to have nice code NOW, and handle the problem with a transition period like with deprecated methods.
I agree with Stephane, having a name that begins with a capitalized letter has a strong connotation of global visibility. And, on the contrary, an identifier beginning with a small letter has a restricted scope.
Also in Ruby: $global @instVar @@classInstVar â¦and in Java: int anInteger;
Yes, enforcing is like static typing, and Code Critics is like pluggable type systems :)
Forbidding a new value to be assigned to a method variable is a simple increase the readability.
Why ? they are defined once at the beginning of the method, just not between the | |; I think of them as locals that just get initialized to something else than nil⦠Now maybe I don't see the problem because I'm not used to C so it wouldn't even occur to me that assigning to parameters could have an effect on the caller.
Even if closure were supported, we should not allow a single identifier to appear as argument in different blocks in the same method. This does not help readability.
Huh, do you really want to use :each1 :each2 :each3 if you have three loops in the method ?
As a follower to that line, something that would be great to have, is to forbid accesses to an undefined variable.
What if you remove the variable definition from the class ? Do you want the compiler to force you to remove all uses immediately ?
I do not think so but what would be good is to be aware of shadowed or used and not there variables because when you integrate code like we did and mike too. Shadowing is a plague because you do not know the code this is not yours and silently the compiler compiles and you have broken code but you do not do it. Dynamically typed does not weak.
I am aware that I am talking as someone who does not maintain cross- dialect applications, but we cannot trade readability for a local in time commodity.
Sure, but we could try to make the transition easier (e.g., complain to Janko for the moment and wait until Pharo stable to enforce conventions)
Yes I think that this is the way to go Something like deprecated.
At Wed, 24 Dec 2008 11:11:16 +0100, Michael Rueger wrote:
What really is the convenience of modifying an argument? Having not to think up another name? I never understood this argument especially if you need to use the original value of the argument in several places.
If you can think of an argument as a "temp initialized by the caller" (like C), that kind of unifies the args and temps and would reduce the implementation complexity. In *some cases* it would reduce the lines of code in the user land.
Same for upper/lowercase conventions, let alone uppercase method names.
For this, I would strongly advocate to remove the restriction, as only a small subset of letters (defined in Unicode) have the upper or lower classification. -- Yoshiki
On Thu, Dec 25, 2008 at 7:32 PM, Yoshiki Ohshima <yoshiki@vpri.org> wrote:
At Wed, 24 Dec 2008 11:11:16 +0100, Michael Rueger wrote:
What really is the convenience of modifying an argument? Having not to think up another name? I never understood this argument especially if you need to use the original value of the argument in several places.
If you can think of an argument as a "temp initialized by the caller" (like C), that kind of unifies the args and temps and would reduce the implementation complexity. In *some cases* it would reduce the lines of code in the user land.
Or alternatively one can think of a temp as an argument of an invisible block, | foo | foo := 3. ... being a form of [:foo | ...] value: 3. --Vassili
Just for the record, Java compiler enforces code conventions like uppercases and so... but is configurable, usually you get a warning. You can change compiler configuration so it can throw an exception and you can tell him to ignore it (wich is what I do allways before starting a project, not because I break the rules, just because I hate to see the compiler telling me about other packages who break them... all the time) IMHO, Lukas is right, it is not a problem of the compiler, but Lint... but if others prefer the compiler to do such tasks, I think java approach is not so bad: having three states configuration and defaulting them to warning (no error). Cheers, Esteban On 2008-12-24 12:13:56 -0200, Alexandre Bergel <alexandre@bergel.eu> said:
I do not think that a preference should relax some static language
enforcements. Contrary to Java, the Smalltalk community does not appear to be big
enough to have these problem unsolvable.
I agree with Stephane, having a name that begins with a capitalized
letter has a strong connotation of global visibility. And, on the
contrary, an identifier beginning with a small letter has a restricted
scope.
Forbidding a new value to be assigned to a method variable is a simple
increase the readability. Even if closure were supported, we should
not allow a single identifier to appear as argument in different
blocks in the same method. This does not help readability.
As a follower to that line, something that would be great to have, is
to forbid accesses to an undefined variable.
I am aware that I am talking as someone who does not maintain cross-
dialect applications, but we cannot trade readability for a local in
time commodity.
Alexandre
On 23 Dec 2008, at 18:02, Stéphane Ducasse wrote:
lukas
would a preference help?
Stef
On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote:
Seaside depends on external packages, that we don't have control
over.
For example there the Swazoo package contains a class-instance variable that is uppercase. Unfortunately Pharo throws a notification (instance variables should begin with a lower case characters) when loading that code. This is awkward, because it makes it impossible to load code automatically and gives us additional work.
In my opinion a programming language should be as open as possible, and if possible not restrict the user in any way, even if this is against best practices. Unfortunately many of those restrictions are built into our language that wouldn't be necessary:
- class names and class-variable names are enforced to be uppercase - class instance-variable names are enforced to be lowercase - it is not possible to assign a new value to a method argument - variable names are enforced to be unique in all scopes
In my opinion the language should be as open as possible. It is the purpose of Code Critics to point out smells, not the task of the compiler to reject code that doesn't follow best practices.
I am slightly frustrated trying to work around these restrictions ...
Cheers, Lukas
--
Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
At Sat, 27 Dec 2008 00:24:02 -0800, Vassili Bykov wrote:
On Thu, Dec 25, 2008 at 7:32 PM, Yoshiki Ohshima <yoshiki@vpri.org> wrote:
At Wed, 24 Dec 2008 11:11:16 +0100, Michael Rueger wrote:
What really is the convenience of modifying an argument? Having not to think up another name? I never understood this argument especially if you need to use the original value of the argument in several places.
If you can think of an argument as a "temp initialized by the caller" (like C), that kind of unifies the args and temps and would reduce the implementation complexity. In *some cases* it would reduce the lines of code in the user land.
Or alternatively one can think of a temp as an argument of an invisible block,
| foo | foo := 3. ...
being a form of
[:foo | ...] value: 3.
If args are assignable, and yes you can unify methods and blocks. But I'm pretty much convinced that debugged context being restartable (by making args readonly) is important in practice. -- Yoshiki
Its handy to at least have the option of making args writable in order to support implementing languages like Javascript on top of the bytecode set. -david On Sat, Dec 27, 2008 at 8:43 AM, Yoshiki Ohshima <yoshiki@vpri.org> wrote:
At Sat, 27 Dec 2008 00:24:02 -0800, Vassili Bykov wrote:
On Thu, Dec 25, 2008 at 7:32 PM, Yoshiki Ohshima <yoshiki@vpri.org>
wrote:
At Wed, 24 Dec 2008 11:11:16 +0100, Michael Rueger wrote:
What really is the convenience of modifying an argument? Having not to think up another name? I never understood this argument especially if you need to use the original value of the argument in several places.
If you can think of an argument as a "temp initialized by the caller" (like C), that kind of unifies the args and temps and would reduce the implementation complexity. In *some cases* it would reduce the lines of code in the user land.
Or alternatively one can think of a temp as an argument of an invisible block,
| foo | foo := 3. ...
being a form of
[:foo | ...] value: 3.
If args are assignable, and yes you can unify methods and blocks.
But I'm pretty much convinced that debugged context being restartable (by making args readonly) is important in practice.
-- Yoshiki
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Its handy to at least have the option of making args writable in order to support implementing languages like Javascript on top of the bytecode set.
Assigning to an argument is already possible on a bytecode level, this is the compiler that prevents you from doing so. The check is in TempVariableNode>>#assignmentCheck:at: and can safely be replaced with the following method: assignmentCheck: encoder at: location ^ -1 The other issues I mentioned in the original post are similarly hardcoded. They can all be implemented by removing unnecessary checks in the compiler or class-builder. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Sat, Dec 27, 2008 at 6:43 AM, Yoshiki Ohshima <yoshiki@vpri.org> wrote:
But I'm pretty much convinced that debugged context being restartable (by making args readonly) is important in practice.
Yes, that's perhaps the most concrete argument (no pun intended). However, in the classic ST80-like architecture read-only arguments are not required for restarting, since the original argument values are also available on the sender context's stack. Cheers, --Vassili
Frankly speaking, I am left unconvinced that allowing argument to be writable will increase the quality of Pharo. Alexandre On 27 Dec 2008, at 13:31, David Pennell wrote:
Its handy to at least have the option of making args writable in order to support implementing languages like Javascript on top of the bytecode set.
-david
On Sat, Dec 27, 2008 at 8:43 AM, Yoshiki Ohshima <yoshiki@vpri.org> wrote: At Sat, 27 Dec 2008 00:24:02 -0800, Vassili Bykov wrote:
On Thu, Dec 25, 2008 at 7:32 PM, Yoshiki Ohshima
<yoshiki@vpri.org> wrote:
At Wed, 24 Dec 2008 11:11:16 +0100, Michael Rueger wrote:
What really is the convenience of modifying an argument? Having
not to
think up another name? I never understood this argument especially if you need to use the original value of the argument in several places.
If you can think of an argument as a "temp initialized by the caller" (like C), that kind of unifies the args and temps and would reduce the implementation complexity. In *some cases* it would reduce the lines of code in the user land.
Or alternatively one can think of a temp as an argument of an invisible block,
| foo | foo := 3. ...
being a form of
[:foo | ...] value: 3.
If args are assignable, and yes you can unify methods and blocks.
But I'm pretty much convinced that debugged context being restartable (by making args readonly) is important in practice.
-- Yoshiki
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2008/12/29 Alexandre Bergel <Alexandre.Bergel@inria.fr>:
Frankly speaking, I am left unconvinced that allowing argument to be writable will increase the quality of Pharo.
me too. It would be better to keep distinction between arguments and temps and do not rely on implementation. I think that in stack-based VM , an assignable arguments could be problematic, because if you want to restart a method, you will be unable to recover original values because they are not copied in context but lying on stack.
Alexandre
On 27 Dec 2008, at 13:31, David Pennell wrote:
Its handy to at least have the option of making args writable in order to support implementing languages like Javascript on top of the bytecode set.
-david
On Sat, Dec 27, 2008 at 8:43 AM, Yoshiki Ohshima <yoshiki@vpri.org> wrote: At Sat, 27 Dec 2008 00:24:02 -0800, Vassili Bykov wrote:
On Thu, Dec 25, 2008 at 7:32 PM, Yoshiki Ohshima
<yoshiki@vpri.org> wrote:
At Wed, 24 Dec 2008 11:11:16 +0100, Michael Rueger wrote:
What really is the convenience of modifying an argument? Having
not to
think up another name? I never understood this argument especially if you need to use the original value of the argument in several places.
If you can think of an argument as a "temp initialized by the caller" (like C), that kind of unifies the args and temps and would reduce the implementation complexity. In *some cases* it would reduce the lines of code in the user land.
Or alternatively one can think of a temp as an argument of an invisible block,
| foo | foo := 3. ...
being a form of
[:foo | ...] value: 3.
If args are assignable, and yes you can unify methods and blocks.
But I'm pretty much convinced that debugged context being restartable (by making args readonly) is important in practice.
-- Yoshiki
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Alexandre Bergel wrote:
Frankly speaking, I am left unconvinced that allowing argument to be writable will increase the quality of Pharo.
Alexandre
Readability readability readability. If I have to assign a temporary just to put some gating conditions to an argument, say I need a url without a trailing slash. I end up with two similarly named variables, with similar values, but completely different behaviour, one being mutable the other immutable. I would love arguments to be mutable. Once more I make the point that these facilities should be developed and packaged as a contribution to all squeakers not just pharo. Keith
Once more I make the point that these facilities should be developed and packaged as a contribution to all squeakers not just pharo.
Sure! Pharo should allow this to happen. Nobody said the contrary. Overriding compilerClass should enable this, and, ideally, the compiler should allow you to switch a 'false' into a 'true' for obtain the effect you desire... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I agree and to me looks like a change for a change. There are so much things I would like to see better in Pharo... On Dec 29, 2008, at 2:51 AM, Igor Stasenko wrote:
2008/12/29 Alexandre Bergel <Alexandre.Bergel@inria.fr>:
Frankly speaking, I am left unconvinced that allowing argument to be writable will increase the quality of Pharo.
me too. It would be better to keep distinction between arguments and temps and do not rely on implementation. I think that in stack-based VM , an assignable arguments could be problematic, because if you want to restart a method, you will be unable to recover original values because they are not copied in context but lying on stack.
Alexandre
On 27 Dec 2008, at 13:31, David Pennell wrote:
Its handy to at least have the option of making args writable in order to support implementing languages like Javascript on top of the bytecode set.
-david
On Sat, Dec 27, 2008 at 8:43 AM, Yoshiki Ohshima <yoshiki@vpri.org> wrote: At Sat, 27 Dec 2008 00:24:02 -0800, Vassili Bykov wrote:
On Thu, Dec 25, 2008 at 7:32 PM, Yoshiki Ohshima
<yoshiki@vpri.org> wrote:
At Wed, 24 Dec 2008 11:11:16 +0100, Michael Rueger wrote:
What really is the convenience of modifying an argument? Having
not to
think up another name? I never understood this argument especially if you need to use the original value of the argument in several places.
If you can think of an argument as a "temp initialized by the caller" (like C), that kind of unifies the args and temps and would reduce the implementation complexity. In *some cases* it would reduce the lines of code in the user land.
Or alternatively one can think of a temp as an argument of an invisible block,
| foo | foo := 3. ...
being a form of
[:foo | ...] value: 3.
If args are assignable, and yes you can unify methods and blocks.
But I'm pretty much convinced that debugged context being restartable (by making args readonly) is important in practice.
-- Yoshiki
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Please don't forget that "writable arguments" was just a side note of the original issue I reported. The real issue is that the Pharo compiler is **not ANSI compatible** anymore and that it refuses to compile valid Smalltalk code, because it wants to enforce some coding conventions. This makes it unnecessarily hard to port code from other Smalltalk dialects and prevents already today some external Seaside dependencies to load cleanly. I hope this is going to be fixed, because this is clearly broken. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Hi guys, Damien, Alexandre:
I am aware that I am talking as someone who does not maintain cross- dialect applications, but we cannot trade readability for a local in time commodity.
Sure, but we could try to make the transition easier (e.g., complain to Janko for the moment and wait until Pharo stable to enforce conventions)
Stéphane Ducasse wrote:
Yes I contacted Janko if he can fix that
I can fix of course but I'm a bit surprised that in Squeak the class variables are supposed to be lower case. I have in mind back from 1996 that they must be uppercase. I just managed to open an old VisualWorks 2.5.2 image back from 1996 and exactly, class vars should be uppercase, see this class construction template: NameOfSuperclass subclass: #NameOfClass instanceVariableNames: 'instVarName1 instVarName2' classVariableNames: 'ClassVarName1 ClassVarName2' poolDictionaries: '' category: 'Collections-Unordered' But naming them lowercase is not enforced, you just got a warning: Static variable names should be capitalized. So, it seems that Squeak changed this convention or is this just a consequence of some later developed habit? From this I suggest that Lucas's proposal is considered, but only for this case regarding the class variables. Otherwise we will have the porting problems all the time. Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
Yes I contacted Janko if he can fix that
I can fix of course but I'm a bit surprised that in Squeak the class variables are supposed to be lower case. I have in mind back from 1996 that they must be uppercase.
Janko, I'm pretty sure Lukas was talking about a class instance variable, not a class variable. Class instance variables should be lowercase while class vars are uppercase. Swazoo apparently contains a class-instance variable that is uppercased, which regardless of the outcome of this discussion, should probably be fixed. Ramon Leon http://onsmalltalk.com
Exact! And lukas is just reporting a problem with pharo since we put a check to make sure that class instance variables are lowercase and class variable are uppecased. So Janko can you check a class instance variable named Singleton that should be named singleton. Stef On Dec 29, 2008, at 4:55 PM, Ramon Leon wrote:
Yes I contacted Janko if he can fix that
I can fix of course but I'm a bit surprised that in Squeak the class variables are supposed to be lower case. I have in mind back from 1996 that they must be uppercase.
Janko, I'm pretty sure Lukas was talking about a class instance variable, not a class variable. Class instance variables should be lowercase while class vars are uppercase. Swazoo apparently contains a class-instance variable that is uppercased, which regardless of the outcome of this discussion, should probably be fixed.
Ramon Leon http://onsmalltalk.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Ramon, Ramon Leon wrote:
Yes I contacted Janko if he can fix that
I can fix of course but I'm a bit surprised that in Squeak the class variables are supposed to be lower case. I have in mind back from 1996 that they must be uppercase.
Janko, I'm pretty sure Lukas was talking about a class instance variable, not a class variable. Class instance variables should be lowercase while class vars are uppercase. Swazoo apparently contains a class-instance variable that is uppercased, which regardless of the outcome of this discussion, should probably be fixed.
Here is the exact definition of a Swazoo class in question: Object subclass: #SwazooServer instanceVariableNames: 'sites servers watchdog' classVariableNames: 'Singleton' poolDictionaries: '' category: 'Swazoo-Core' And here the same definition of Swazoo SiteRegistry in VW 3.0 back from 2000: Object subclass: #SiteRegistry instanceVariableNames: 'sites servers ' classVariableNames: 'Singleton ' poolDictionaries: '' category: 'Swazoo' So, this is obviously a class variable definition and not an instance one. Where is the problem then? I don't find any class instance variables in other classes and in any way the Singleton should be only class variable in use in Swazoo. Best regards Janko -- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
Strange if this is really that then it is correct and the check in wrong in pharo. I will check and fix Stef On Dec 29, 2008, at 5:16 PM, Janko Mivšek wrote:
Hi Ramon,
Ramon Leon wrote:
Yes I contacted Janko if he can fix that
I can fix of course but I'm a bit surprised that in Squeak the class variables are supposed to be lower case. I have in mind back from 1996 that they must be uppercase.
Janko, I'm pretty sure Lukas was talking about a class instance variable, not a class variable. Class instance variables should be lowercase while class vars are uppercase. Swazoo apparently contains a class- instance variable that is uppercased, which regardless of the outcome of this discussion, should probably be fixed.
Here is the exact definition of a Swazoo class in question:
Object subclass: #SwazooServer instanceVariableNames: 'sites servers watchdog' classVariableNames: 'Singleton' poolDictionaries: '' category: 'Swazoo-Core'
And here the same definition of Swazoo SiteRegistry in VW 3.0 back from 2000:
Object subclass: #SiteRegistry instanceVariableNames: 'sites servers ' classVariableNames: 'Singleton ' poolDictionaries: '' category: 'Swazoo'
So, this is obviously a class variable definition and not an instance one. Where is the problem then? I don't find any class instance variables in other classes and in any way the Singleton should be only class variable in use in Swazoo.
Best regards Janko
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi janko I checked and - pharo does not complain for what seems good. So no bugs from our side. - SwazooBenchmarks seems to have an instance class variable with uppercase Singleton can you check and confirm. I tried to load beta2.2 Thanks Stef On Dec 29, 2008, at 5:16 PM, Janko Mivšek wrote:
Hi Ramon,
Ramon Leon wrote:
Yes I contacted Janko if he can fix that
I can fix of course but I'm a bit surprised that in Squeak the class variables are supposed to be lower case. I have in mind back from 1996 that they must be uppercase.
Janko, I'm pretty sure Lukas was talking about a class instance variable, not a class variable. Class instance variables should be lowercase while class vars are uppercase. Swazoo apparently contains a class- instance variable that is uppercased, which regardless of the outcome of this discussion, should probably be fixed.
Here is the exact definition of a Swazoo class in question:
Object subclass: #SwazooServer instanceVariableNames: 'sites servers watchdog' classVariableNames: 'Singleton' poolDictionaries: '' category: 'Swazoo-Core'
And here the same definition of Swazoo SiteRegistry in VW 3.0 back from 2000:
Object subclass: #SiteRegistry instanceVariableNames: 'sites servers ' classVariableNames: 'Singleton ' poolDictionaries: '' category: 'Swazoo'
So, this is obviously a class variable definition and not an instance one. Where is the problem then? I don't find any class instance variables in other classes and in any way the Singleton should be only class variable in use in Swazoo.
Best regards Janko
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Strange if this is really that then it is correct and the check in wrong in pharo. I will check and fix
Stef
I just did, I get no errors, this class Object subclass: #SwazooServer instanceVariableNames: 'sites servers watchdog' classVariableNames: 'Singleton' poolDictionaries: '' category: 'Swazoo-Core' Compiles just fine in Pharo, I see nothing wrong with it. Ramon Leon http://onsmalltalk.com
Hi Stef, Stéphane Ducasse wrote:
I checked and - pharo does not complain for what seems good. So no bugs from our side.
- SwazooBenchmarks seems to have an instance class variable with uppercase Singleton
can you check and confirm. I tried to load beta2.2 Thanks
Yep, that's it! And it seems it comes from VW definition, where since 7.x you don't have class variables anymore but just shared ones. It seems I wrongly put this Singleton as the class instance variable and porting to Squeak ported that mistake too. Sorry for that and the error will be corrected in the next release. In the meantime you can safely just ignore it. Best regards Janko
On Dec 29, 2008, at 5:16 PM, Janko Mivšek wrote:
Hi Ramon,
Ramon Leon wrote:
Yes I contacted Janko if he can fix that I can fix of course but I'm a bit surprised that in Squeak the class variables are supposed to be lower case. I have in mind back from 1996 that they must be uppercase. Janko, I'm pretty sure Lukas was talking about a class instance variable, not a class variable. Class instance variables should be lowercase while class vars are uppercase. Swazoo apparently contains a class- instance variable that is uppercased, which regardless of the outcome of this discussion, should probably be fixed. Here is the exact definition of a Swazoo class in question:
Object subclass: #SwazooServer instanceVariableNames: 'sites servers watchdog' classVariableNames: 'Singleton' poolDictionaries: '' category: 'Swazoo-Core'
And here the same definition of Swazoo SiteRegistry in VW 3.0 back from 2000:
Object subclass: #SiteRegistry instanceVariableNames: 'sites servers ' classVariableNames: 'Singleton ' poolDictionaries: '' category: 'Swazoo'
So, this is obviously a class variable definition and not an instance one. Where is the problem then? I don't find any class instance variables in other classes and in any way the Singleton should be only class variable in use in Swazoo.
Best regards Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
I don't think you guys see that what Lukas is proposing is not necessarily a change of the language, but a better stratification of the system. Arguments don't have to be writable in a Smalltalk program if tradition dictates they shouldn't be. But a good language platform would still support that under the hood. Janko already pointed out that VisualWorks suggests but does not enforce variable capitalization rules. VisualWorks also supports assigning to method arguments. It's a compiler flag, and it's off by default when compiling Smalltalk methods, but you can implement a different language with different rules and still use the same code generator simply by flipping that switch. The VM supports that too, despite being much more advanced. And let me once again explain that this has nothing to do with the ability to restart a context. As long as a message is sent by computing argument values and pushing them on the stack in the sender context, and as long as there is a context reflection facility (and I can't imagine a decent implementation without one regardless of how the contexts are really managed), the debugger can always restore the original values from the sender context. --Vassili On Mon, Dec 29, 2008 at 2:20 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I agree and to me looks like a change for a change. There are so much things I would like to see better in Pharo...
On Dec 29, 2008, at 2:51 AM, Igor Stasenko wrote:
2008/12/29 Alexandre Bergel <Alexandre.Bergel@inria.fr>:
Frankly speaking, I am left unconvinced that allowing argument to be writable will increase the quality of Pharo.
me too. It would be better to keep distinction between arguments and temps and do not rely on implementation. I think that in stack-based VM , an assignable arguments could be problematic, because if you want to restart a method, you will be unable to recover original values because they are not copied in context but lying on stack.
Thanks janko Stef On Dec 29, 2008, at 6:00 PM, Janko Mivšek wrote:
Hi Stef,
Stéphane Ducasse wrote:
I checked and - pharo does not complain for what seems good. So no bugs from our side.
- SwazooBenchmarks seems to have an instance class variable with uppercase Singleton
can you check and confirm. I tried to load beta2.2 Thanks
Yep, that's it! And it seems it comes from VW definition, where since 7.x you don't have class variables anymore but just shared ones. It seems I wrongly put this Singleton as the class instance variable and porting to Squeak ported that mistake too.
Sorry for that and the error will be corrected in the next release. In the meantime you can safely just ignore it.
Best regards Janko
On Dec 29, 2008, at 5:16 PM, Janko Mivšek wrote:
Hi Ramon,
Ramon Leon wrote:
Yes I contacted Janko if he can fix that I can fix of course but I'm a bit surprised that in Squeak the class variables are supposed to be lower case. I have in mind back from 1996 that they must be uppercase. Janko, I'm pretty sure Lukas was talking about a class instance variable, not a class variable. Class instance variables should be lowercase while class vars are uppercase. Swazoo apparently contains a class- instance variable that is uppercased, which regardless of the outcome of this discussion, should probably be fixed. Here is the exact definition of a Swazoo class in question:
Object subclass: #SwazooServer instanceVariableNames: 'sites servers watchdog' classVariableNames: 'Singleton' poolDictionaries: '' category: 'Swazoo-Core'
And here the same definition of Swazoo SiteRegistry in VW 3.0 back from 2000:
Object subclass: #SiteRegistry instanceVariableNames: 'sites servers ' classVariableNames: 'Singleton ' poolDictionaries: '' category: 'Swazoo'
So, this is obviously a class variable definition and not an instance one. Where is the problem then? I don't find any class instance variables in other classes and in any way the Singleton should be only class variable in use in Swazoo.
Best regards Janko
-- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (17)
-
Alexandre Bergel -
Alexandre Bergel -
bryce＠kampjes.demon.co.uk -
Damien Pollet -
David Pennell -
Esteban Lorenzano -
Hilaire Fernandes -
Igor Stasenko -
Janko Mivšek -
Jim Menard -
Keith Hodges -
Lukas Renggli -
Michael Rueger -
Ramon Leon -
Stéphane Ducasse -
Vassili Bykov -
Yoshiki Ohshima