Fabio Niephaus uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-fn.825.mcz
==================== Summary ====================
Name: Collections-fn.825 Author: fn Time: 12 April 2019, 9:30:29.397159 am UUID: 3110d8f6-fa38-4d91-8358-aed2eadbd9a7 Ancestors: Collections-nice.824
Just like strings, characters should convert themselves to an integer when involved in arithmetic with a number.
Example: $c < 98.9 "false" 98.9 < $c "opened debugger, now returns true"
=============== Diff against Collections-nice.824 ===============
Item was added: + ----- Method: Character>>adaptToNumber:andSend: (in category 'converting') ----- + adaptToNumber: rcvr andSend: selector + "If I am involved in arithmetic with a number, convert me to an integer." + + ^ rcvr perform: selector with: self asInteger!
On 2019-04-12, at 12:30 AM, commits@source.squeak.org wrote:
Just like strings, characters should convert themselves to an integer when involved in arithmetic with a number.
Well, ok I guess. BUT why is the conversion simply to the internal bits of the character representation? Surely digit characters ought to convert to the number they directly represent? And wouldn't it be more correct to convert all the other chars via the encoding in use? Unless, I suppose we are actually using unicode already in which case one might make a decent argument that that is The Right One.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LA: Lockout Access
Hi
On 12.04.2019, at 19:14, tim Rowledge tim@rowledge.org wrote:
On 2019-04-12, at 12:30 AM, commits@source.squeak.org wrote:
Just like strings, characters should convert themselves to an integer when involved in arithmetic with a number.
Well, ok I guess. BUT why is the conversion simply to the internal bits of the character representation? Surely digit characters ought to convert to the number they directly represent? And wouldn't it be more correct to convert all the other chars via the encoding in use? Unless, I suppose we are actually using unicode already in which case one might make a decent argument that that is The Right One.
I think this is just for symmetry. and yes, asInteger on a character currently gives the unicode codepoint…
Best regards -Tobias
tim
On 12.04.2019, at 19:14, tim Rowledge tim@rowledge.org wrote:
On 2019-04-12, at 12:30 AM, commits@source.squeak.org wrote:
Just like strings, characters should convert themselves to an integer when involved in arithmetic with a number.
Well, ok I guess. BUT why is the conversion simply to the internal bits of the character representation? Surely digit characters ought to convert to the number they directly represent? And wouldn't it be more correct to convert all the other chars via the encoding in use? Unless, I suppose we are actually using unicode already in which case one might make a decent argument that that is The Right One.
I think this is just for symmetry. and yes, asInteger on a character currently gives the unicode codepoint…
We've still got a problem with symmetry.
{ 99 < 99.0. 99 > 99.0. 99 = 99.0 } #(false false true)
but,
{$c < 99. $c > 99. $c = 99. } #(false false false)
Symmetry can only be achieved by moving in the other direction, e.g., signal an error in both cases.
Is it good for the language to be this loose with Character comparisons? Honest question, I don't know the definitive answer, however, it seems like we should match strictness with comparisons as with our strictness over equivalence. I can understand in a lower-level language like C where there is a tighter coupling between the representation of the two. And in Squeak, yes, we do enjoy messaging to decouple us from dependence on types, but where do we define the boundaries of the looseness? :)
Also prudent to consider that we toy with a one-way street here. I didn't study the details, but I assume any application can add an these overrides to make this possible, leaving Squeak as a system capable of serving the needs of both relaxed and tight comparing. But if we commit to this in the core and start depending it, loose is all we'll have and no one will be able to have tight anymore.
Anyone know how other Smalltalk's handle this comparison? The ANSI standard?
Best, Chris
Am Fr., 12. Apr. 2019 um 23:56 Uhr schrieb Chris Muller <asqueaker@gmail.com
:
Anyone know how other Smalltalk's handle this comparison? The ANSI standard?
The ANSI standard, sparse as it is, does not even require that Character must be a Magnitude. So there is no ordering, thus no #<, for Characters. There is also no Character>>asInteger (only codePoint), and no Number/Integer>>asCharacter. Character comparison is indeed defined as character1 codePoint = character2 codePoint there.
I am not so fond of this change. It feels like a slope towards JavaScript, which has (not so) funny articles about the ridiculous implicit type conversions. There was a change last year that disallowed putting numbers (bytes) in ByteStrings and vice versa. This change goes kind of in the other direction.
The #< of Character seems to support comparisons with numbers. But this may never have been intended as it is a side effect of how the method is implemented (comparing the #asInteger values of the Characters)? If it were implemented in terms of #codePoint instead of #asInteger, it would not support comparison with numbers, but still work for Characters.
Yet I see the compatibility trouble and the long history of adaptToNumber:andSend:.
I would prefer if people wrote more asInteger/asNumber or asCharacter if they need to ensure the types (because they expect that sometimes numbers come in instead of characters, or the other way around), instead of relying on implicit type conversions. It also forces them to think about which kind of character to number conversion they want, referring to what Tim wrote: are digit characters their number counterparts or their unicode code points?
Am Fr., 12. Apr. 2019 um 19:14 Uhr schrieb tim Rowledge tim@rowledge.org:
On 2019-04-12, at 12:30 AM, commits@source.squeak.org wrote:
Just like strings, characters should convert themselves to an integer
when involved in arithmetic with a number.
Well, ok I guess. BUT why is the conversion simply to the internal bits of the character representation? Surely digit characters ought to convert to the number they directly represent? And wouldn't it be more correct to convert all the other chars via the encoding in use? Unless, I suppose we are actually using unicode already in which case one might make a decent argument that that is The Right One.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LA: Lockout Access
+1 Implicit conversion like this is hard to remember an makes code hard to understand. For example C is used in many different number system and is not the same in either. C in roman numerals is not equal to ASCII c or C or hexadecimal C.
Can of worms warning.
Best, Karl
On Sat, Apr 13, 2019 at 9:17 AM Jakob Reschke forums.jakob@resfarm.de wrote:
I am not so fond of this change. It feels like a slope towards JavaScript, which has (not so) funny articles about the ridiculous implicit type conversions. There was a change last year that disallowed putting numbers (bytes) in ByteStrings and vice versa. This change goes kind of in the other direction.
The #< of Character seems to support comparisons with numbers. But this may never have been intended as it is a side effect of how the method is implemented (comparing the #asInteger values of the Characters)? If it were implemented in terms of #codePoint instead of #asInteger, it would not support comparison with numbers, but still work for Characters.
Yet I see the compatibility trouble and the long history of adaptToNumber:andSend:.
I would prefer if people wrote more asInteger/asNumber or asCharacter if they need to ensure the types (because they expect that sometimes numbers come in instead of characters, or the other way around), instead of relying on implicit type conversions. It also forces them to think about which kind of character to number conversion they want, referring to what Tim wrote: are digit characters their number counterparts or their unicode code points?
Am Fr., 12. Apr. 2019 um 19:14 Uhr schrieb tim Rowledge <tim@rowledge.org
:
On 2019-04-12, at 12:30 AM, commits@source.squeak.org wrote:
Just like strings, characters should convert themselves to an integer
when involved in arithmetic with a number.
Well, ok I guess. BUT why is the conversion simply to the internal bits of the character representation? Surely digit characters ought to convert to the number they directly represent? And wouldn't it be more correct to convert all the other chars via the encoding in use? Unless, I suppose we are actually using unicode already in which case one might make a decent argument that that is The Right One.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LA: Lockout Access
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
commits＠source.squeak.org -
Jakob Reschke -
karl ramberg -
tim Rowledge -
Tobias Pape