('a' == 'a') == true ?
Locked
12
12
 
|
On 27 September 2010 22:10, Levente Uzonyi <[hidden email]> wrote:
> On Mon, 27 Sep 2010, Johan Brichau wrote: > >> >> On 27 Sep 2010, at 14:37, Schwab,Wilhelm K wrote: >> >>> "Works fine" is a value judgment that can cut both ways: one could also >>> argue that VW lacks a useful optimization of literals. Non-literal strings >>> should do what you want. >> >> I wonder how useful the optimization is, actually. >> Probably not many (if any) methods will use the same literal multiple >> times and count on the compiler to optimize them into the same literal. > > I think this is from the 80's or 90's where this could save some memory. > According to my calculations in Squeak 4.2 with some extra packages loaded > it saves at least 36591 bytes (object size + 1 slot in the literal array), > which is only 0.79 bytes / method. > Well, you can save a bit more, if you scan a whole image literals and unify them. This could be userful for tidying up the image size. > > Levente > >> >> Inversely, I have never run into that issue myself either, until I was >> just testing those little snippets for the students. Or... at least, I think >> I never have :-) >> >> Johan >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Mon, 27 Sep 2010, Igor Stasenko wrote:
> On 27 September 2010 22:10, Levente Uzonyi <[hidden email]> wrote: > On Mon, 27 Sep 2010, Johan Brichau wrote: > >> >> On 27 Sep 2010, at 14:37, Schwab,Wilhelm K wrote: >> >>> "Works fine" is a value judgment that can cut both ways: one could also >>> argue that VW lacks a useful optimization of literals. Non-literal strings >>> should do what you want. >> >> I wonder how useful the optimization is, actually. >> Probably not many (if any) methods will use the same literal multiple >> times and count on the compiler to optimize them into the same literal. > > I think this is from the 80's or 90's where this could save some memory. > According to my calculations in Squeak 4.2 with some extra packages loaded > it saves at least 36591 bytes (object size + 1 slot in the literal array), > which is only 0.79 bytes / method. > unify them. This could be userful for tidying up the image size. Probably yes, but that's not the point I guess. I just wanted to show that the current method doesn't really save much. Unifying the literals in the image is dangerous, because literal strings are not immutable (and they shouldn't be IMHO). So that could lead to random errors if a method is modifying a shared string literal. Levente > > Levente > >> >> Inversely, I have never run into that issue myself either, until I was >> just testing those little snippets for the students. Or... at least, I think >> I never have :-) >> >> Johan >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ('a' == 'a') == true ?
|
|
On 27.09.2010 23:05, Levente Uzonyi wrote:
> On Mon, 27 Sep 2010, Igor Stasenko wrote: > >> On 27 September 2010 22:10, Levente Uzonyi <[hidden email]> wrote: >> On Mon, 27 Sep 2010, Johan Brichau wrote: >> >>> >>> On 27 Sep 2010, at 14:37, Schwab,Wilhelm K wrote: >>> >>>> "Works fine" is a value judgment that can cut both ways: one could >>>> also >>>> argue that VW lacks a useful optimization of literals. Non-literal >>>> strings >>>> should do what you want. >>> >>> I wonder how useful the optimization is, actually. >>> Probably not many (if any) methods will use the same literal multiple >>> times and count on the compiler to optimize them into the same literal. >> >> I think this is from the 80's or 90's where this could save some memory. >> According to my calculations in Squeak 4.2 with some extra packages >> loaded >> it saves at least 36591 bytes (object size + 1 slot in the literal >> array), >> which is only 0.79 bytes / method. >> > > Well, you can save a bit more, if you scan a whole image literals and > unify them. > This could be userful for tidying up the image size. > > > Probably yes, but that's not the point I guess. I just wanted to show > that the current method doesn't really save much. Unifying the > literals in the image is dangerous, because literal strings are not > immutable (and they shouldn't be IMHO). So that could lead to random > errors if a method is modifying a shared string literal. > > > Levente > Guess who the biggest waster in Core12147 is, at nearly 60KB duplicate strings for three top 5 finishes? :) Starting in VW post the immutable string literals change that was done there, I don't really mind it. Personally, I feel the gains are too low to even justify it for space efficiency reasons though, and the immutable string literal discussion, which would be needed, is a big one. I vaguely remember reading something like that in CompiledMethods, access is faster for literal slots 1-n, where n is a rather low number. Even if that would turn out to be true, I doubt it warrants the compiler optimizations for equivalent literal strings anymore though. Spacewise you've at least already debunked that it's needed :) Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 28 September 2010 00:29, Henrik Sperre Johansen
<[hidden email]> wrote: > On 27.09.2010 23:05, Levente Uzonyi wrote: >> >> On Mon, 27 Sep 2010, Igor Stasenko wrote: >> >>> On 27 September 2010 22:10, Levente Uzonyi <[hidden email]> wrote: >>> On Mon, 27 Sep 2010, Johan Brichau wrote: >>> >>>> >>>> On 27 Sep 2010, at 14:37, Schwab,Wilhelm K wrote: >>>> >>>>> "Works fine" is a value judgment that can cut both ways: one could also >>>>> argue that VW lacks a useful optimization of literals. Non-literal >>>>> strings >>>>> should do what you want. >>>> >>>> I wonder how useful the optimization is, actually. >>>> Probably not many (if any) methods will use the same literal multiple >>>> times and count on the compiler to optimize them into the same literal. >>> >>> I think this is from the 80's or 90's where this could save some memory. >>> According to my calculations in Squeak 4.2 with some extra packages >>> loaded >>> it saves at least 36591 bytes (object size + 1 slot in the literal >>> array), >>> which is only 0.79 bytes / method. >>> >> >> Well, you can save a bit more, if you scan a whole image literals and >> unify them. >> This could be userful for tidying up the image size. >> >> >> Probably yes, but that's not the point I guess. I just wanted to show that >> the current method doesn't really save much. Unifying the literals in the >> image is dangerous, because literal strings are not immutable (and they >> shouldn't be IMHO). So that could lead to random errors if a method is >> modifying a shared string literal. >> >> >> Levente >> > ByteString allInstances asBag sortedCounts > Guess who the biggest waster in Core12147 is, at nearly 60KB duplicate > strings for three top 5 finishes? :) > > Starting in VW post the immutable string literals change that was done > there, I don't really mind it. > Personally, I feel the gains are too low to even justify it for space > efficiency reasons though, and the immutable string literal discussion, > which would be needed, is a big one. > > I vaguely remember reading something like that in CompiledMethods, access is > faster for literal slots 1-n, where n is a rather low number. > Even if that would turn out to be true, I doubt it warrants the compiler > optimizations for equivalent literal strings anymore though. > Spacewise you've at least already debunked that it's needed :) > Well, unifying for space is one thing. Another is search for a literal in image. It could be much quicker if all literals are unified. Its not an invitation to do it, just to consider options which opening for us, if we do that :) > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Mon, Sep 27, 2010 at 3:31 PM, Igor Stasenko <[hidden email]> wrote: On 28 September 2010 00:29, Henrik Sperre Johansen Arguably, but much of the time would go in the search of methods for literals rather than the faster comparisons between literals. However, the notion that this would save space is suspect. To implement literal pooling you either slow-down compilation *a lot* by searching for literals amongst all methods (an implicit pool) or you maintain an explicit pool and likely end up _not saving any space_ since the space occupied by the pool is more-or-less equal to to the space saved by pooling since you'll likely find literals are shared approximately once. We've been-there-done-that with VisualWorks trying to pool the bytecodes in methods and abandoned the idea because there was no net space saving. So you need to quantify the degree of sharing you see in a typical dev image and see whether average sharing is significantly greater than 1.
Its not an invitation to do it, just to consider options which opening _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
+1
> Well, you can save a bit more, if you scan a whole image literals and > unify them. > This could be userful for tidying up the image size. > > > Probably yes, but that's not the point I guess. I just wanted to show that the current method doesn't really save much. Unifying the literals in the image is dangerous, because literal strings are not immutable (and they shouldn't be IMHO). + 10 I would love to have immutability bit. > So that could lead to random errors if a method is modifying a shared string literal. This can of aliasing is bad, it mixes semantics and implementation. I hope that we will be able to fix that with Opal. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Johan Brichau-2
Perhaps interestingly, in the original Self paper promoting mirrors,
it was argued that one of the lessons learned of using mirrors in self was that '==' is really a reflective property, that should be accessible only through mirrors. That is because, whether or not two pointers are equal is really a question on the VM level, and not on your business level. Niko On Mon, Sep 27, 2010 at 10:32 AM, Johan Brichau <[hidden email]> wrote: > I convinced the teacher who will be taking over my Smalltalk courses at UCLouvain (starting this week) to use Pharo :-) > One of the introductory exercises in these courses shows the difference between '==' and '='. However, in Pharo (&Squeak) the following goes wrong imho: > > 'a' == 'a' -> true > $a asString == $a asString -> false > > It seems that when you evaluate the expression, the (semantically identical) strings are represented as the same literal in the compiled block. > For example, try to evaluate the following code by evaluating each statement in a separate doit. Then do it again as a single block... > > |a b| > a := 'a'. > b := 'a'. > a == b inspect > > > Do I make it an issue? Is there already an issue? (did not find one) > Am I wrong? > > Johan > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Johan Brichau-2
But that's the point, there should be no business semantics to '=='.
Only reflective semantics. The reflective semantics are ok. Niko On Mon, Sep 27, 2010 at 11:51 AM, Johan Brichau <[hidden email]> wrote: > > On 27 Sep 2010, at 11:28, Igor Stasenko wrote: > >> On 27 September 2010 11:54, Johan Brichau <[hidden email]> wrote: >>> >>> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >>> >>>>> Am I wrong? >>>> >>>> Yes, almost always one should probably use #= instead of #==. >>> >>> I will add that to the exercise :-) >>> The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) >>> >> >> I think you can avoid using 'equal' word when describing a #== comparison. >> It can be explained as 'test whether comparands are same object or not' >> while #= is test whether two objects equal or not. > > Yes, this is exactly what the exercise is doing. > I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: > > a := #foobar. > b := #foobar. > a == b. > > a := 'foobar'. > b := 'foobar'. > a == b > > The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). > > Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. > > I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) > > cheers > Johan > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Johan Brichau-2
indeed.
> Perhaps interestingly, in the original Self paper promoting mirrors, > it was argued that one of the lessons learned of using mirrors in self > was that '==' is really a reflective property, that should be > accessible only through mirrors. That is because, whether or not two > pointers are equal is really a question on the VM level, and not on > your business level. > > Niko _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Johan Brichau-2
On Sep 28, 2010, at 10:03 AM, Niko Schwarz wrote: > Perhaps interestingly, in the original Self paper promoting mirrors, > it was argued that one of the lessons learned of using mirrors in self > was that '==' is really a reflective property, that should be > accessible only through mirrors. "Mirrors and copulation are obscene, for they increase the numbers of mankind." -- ( Jorge Luis Borges "Tlön, Uqbar, Orbis Tertius") Another point of view of course is that identity actually shows the one main weakness of mirrors. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by niko.schwarz
Perhaps the discussion I wanted to raise is not about the use of '==' but about the fact that equal string literals in the same method body are optimized to be the same object.
Without immutability, such optimization is just plain wrong. In addition, it does not even seem to be a particularly useful optimization. The use of '==' in the exercise is exactly about the reflective semantics, btw. Johan On 28 Sep 2010, at 10:05, Niko Schwarz wrote: > But that's the point, there should be no business semantics to '=='. > Only reflective semantics. The reflective semantics are ok. > > Niko > > On Mon, Sep 27, 2010 at 11:51 AM, Johan Brichau <[hidden email]> wrote: >> >> On 27 Sep 2010, at 11:28, Igor Stasenko wrote: >> >>> On 27 September 2010 11:54, Johan Brichau <[hidden email]> wrote: >>>> >>>> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >>>> >>>>>> Am I wrong? >>>>> >>>>> Yes, almost always one should probably use #= instead of #==. >>>> >>>> I will add that to the exercise :-) >>>> The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) >>>> >>> >>> I think you can avoid using 'equal' word when describing a #== comparison. >>> It can be explained as 'test whether comparands are same object or not' >>> while #= is test whether two objects equal or not. >> >> Yes, this is exactly what the exercise is doing. >> I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: >> >> a := #foobar. >> b := #foobar. >> a == b. >> >> a := 'foobar'. >> b := 'foobar'. >> a == b >> >> The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). >> >> Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. >> >> I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) >> >> cheers >> Johan >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Tue, Sep 28, 2010 at 7:39 AM, Johan Brichau <[hidden email]> wrote: Perhaps the discussion I wanted to raise is not about the use of '==' but about the fact that equal string literals in the same method body are optimized to be the same object. I think it's orthogonal to immutability. Non-immutable literals are "just plain wrong" (actually unsafe). The optimization is confusing and unexpected to the inexperienced. But I emphatically agree with the last part; it's not a particularly useful optimization.
cheers Eliot The use of '==' in the exercise is exactly about the reflective semantics, btw. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
More over, the optimisation seems quite short sighted :
| x | x := #( 'a' 'a'). ^x first == x last -> false For example, if I encode some "data" in an Array with strings, I can expect more frequent repetitions (I know, not very object oriented/ could also use Symbol/etc... but think of a simple 2D game), Nicolas 2010/9/28 Eliot Miranda <[hidden email]>: > > > On Tue, Sep 28, 2010 at 7:39 AM, Johan Brichau <[hidden email]> wrote: >> >> Perhaps the discussion I wanted to raise is not about the use of '==' but >> about the fact that equal string literals in the same method body are >> optimized to be the same object. >> Without immutability, such optimization is just plain wrong. In addition, >> it does not even seem to be a particularly useful optimization. > > I think it's orthogonal to immutability. Non-immutable literals are "just > plain wrong" (actually unsafe). The optimization is confusing and > unexpected to the inexperienced. But I emphatically agree with the last > part; it's not a particularly useful optimization. > cheers > Eliot >> >> The use of '==' in the exercise is exactly about the reflective semantics, >> btw. >> >> Johan >> >> On 28 Sep 2010, at 10:05, Niko Schwarz wrote: >> >> > But that's the point, there should be no business semantics to '=='. >> > Only reflective semantics. The reflective semantics are ok. >> > >> > Niko >> > >> > On Mon, Sep 27, 2010 at 11:51 AM, Johan Brichau <[hidden email]> >> > wrote: >> >> >> >> On 27 Sep 2010, at 11:28, Igor Stasenko wrote: >> >> >> >>> On 27 September 2010 11:54, Johan Brichau <[hidden email]> wrote: >> >>>> >> >>>> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >> >>>> >> >>>>>> Am I wrong? >> >>>>> >> >>>>> Yes, almost always one should probably use #= instead of #==. >> >>>> >> >>>> I will add that to the exercise :-) >> >>>> The exercise actually makes students aware of the difference between >> >>>> strings and symbols (which should be pointer-equal) >> >>>> >> >>> >> >>> I think you can avoid using 'equal' word when describing a #== >> >>> comparison. >> >>> It can be explained as 'test whether comparands are same object or >> >>> not' >> >>> while #= is test whether two objects equal or not. >> >> >> >> Yes, this is exactly what the exercise is doing. >> >> I want them to be aware that equal _symbols_ are the same objects, but >> >> that equal _strings_ are not, which is why I let them evaluate: >> >> >> >> a := #foobar. >> >> b := #foobar. >> >> a == b. >> >> >> >> a := 'foobar'. >> >> b := 'foobar'. >> >> a == b >> >> >> >> The problem is that evaluating the second snippet also yields true in >> >> Pharo/Squeak, so I cannot illustrate it using these snippets (which works >> >> fine in Visualworks, btw). >> >> >> >> Yes, this is a compiler optimization and, yes, people should use #= >> >> instead of #== normally. But imho the optimization yields a wrong semantics, >> >> which is why I posted the email. >> >> >> >> I have absolutely no clue if it can be changed (I am not familiar with >> >> the compiler implementation *at all*), but I would be happy to look over the >> >> shoulder of an experienced compiler hacker during the next sprint to learn >> >> ;-) >> >> >> >> cheers >> >> Johan >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> [hidden email] >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > >> > >> > >> > -- >> > http://scg.unibe.ch/staff/Schwarz >> > twitter.com/nes1983 >> > Tel: +41 076 235 8683 >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ('a' == 'a') == true ?
|
|
AFAIK, Java compiler also performs such optimisation.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eliot Miranda-2
On 28 Sep 2010, at 18:00, Eliot Miranda wrote: > I think it's orthogonal to immutability. Non-immutable literals are "just plain wrong" (actually unsafe). The optimization is confusing and unexpected to the inexperienced. But I emphatically agree with the last part; it's not a particularly useful optimization. Of course, you are right: non-immutable literals are unsafe. However, when you know what you are doing and you are 'mutating' a literal in your code, I think it's surprising that the mutation also happens to what seems to be another literal in the same code (because they are written in different locations in the same method body), just because they happen to be equal. Admittedly, it's not a common issue and mutating literals might sound like dirty code (it probably is in 99% of the cases) but the flexibility also enables powerful things. I have, for example, used that in the implementation of the compiled methods for proxy java classes in JavaConnect. Anyway, I appreciate the discussion! Johan _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by niko.schwarz
On Sep 28, 2010, at 4:39 PM, Johan Brichau wrote: > Perhaps the discussion I wanted to raise is not about the use of '==' but about the fact that equal string literals in the same method body are optimized to be the same object. > Without immutability, such optimization is just plain wrong. In addition, it does not even seem to be a particularly useful optimization. Yes this is true. :) We will fix it with Opal. Stef > > The use of '==' in the exercise is exactly about the reflective semantics, btw. > > Johan > > On 28 Sep 2010, at 10:05, Niko Schwarz wrote: > >> But that's the point, there should be no business semantics to '=='. >> Only reflective semantics. The reflective semantics are ok. >> >> Niko >> >> On Mon, Sep 27, 2010 at 11:51 AM, Johan Brichau <[hidden email]> wrote: >>> >>> On 27 Sep 2010, at 11:28, Igor Stasenko wrote: >>> >>>> On 27 September 2010 11:54, Johan Brichau <[hidden email]> wrote: >>>>> >>>>> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >>>>> >>>>>>> Am I wrong? >>>>>> >>>>>> Yes, almost always one should probably use #= instead of #==. >>>>> >>>>> I will add that to the exercise :-) >>>>> The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) >>>>> >>>> >>>> I think you can avoid using 'equal' word when describing a #== comparison. >>>> It can be explained as 'test whether comparands are same object or not' >>>> while #= is test whether two objects equal or not. >>> >>> Yes, this is exactly what the exercise is doing. >>> I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: >>> >>> a := #foobar. >>> b := #foobar. >>> a == b. >>> >>> a := 'foobar'. >>> b := 'foobar'. >>> a == b >>> >>> The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). >>> >>> Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. >>> >>> I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) >>> >>> cheers >>> Johan >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eliot Miranda-2
+1
discussions are important because they spread knowledge. Stef >> I think it's orthogonal to immutability. Non-immutable literals are "just plain wrong" (actually unsafe). The optimization is confusing and unexpected to the inexperienced. But I emphatically agree with the last part; it's not a particularly useful optimization. > > Of course, you are right: non-immutable literals are unsafe. > However, when you know what you are doing and you are 'mutating' a literal in your code, I think it's surprising that the mutation also happens to what seems to be another literal in the same code (because they are written in different locations in the same method body), just because they happen to be equal. > > Admittedly, it's not a common issue and mutating literals might sound like dirty code (it probably is in 99% of the cases) but the flexibility also enables powerful things. I have, for example, used that in the implementation of the compiled methods for proxy java classes in JavaConnect. > > Anyway, I appreciate the discussion! > > Johan > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |