Smalltalk › Squeak › Squeak - Dev

The Trunk: Collections-fn.825.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

commits-2

The Trunk: Collections-fn.825.mcz

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!

timrowledge

Re: The Trunk: Collections-fn.825.mcz

> On 2019-04-12, at 12:30 AM, [hidden email] 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LA: Lockout Access

Tobias Pape

Re: The Trunk: Collections-fn.825.mcz

> On 12.04.2019, at 19:14, tim Rowledge <[hidden email]> wrote:
>
>
>
>> On 2019-04-12, at 12:30 AM, [hidden email] 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

Chris Muller-3

Re: The Trunk: Collections-fn.825.mcz

> > On 12.04.2019, at 19:14, tim Rowledge <[hidden email]> wrote:
> >
> >
> >
> >> On 2019-04-12, at 12:30 AM, [hidden email] 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

Jakob Reschke

Re: The Trunk: Collections-fn.825.mcz

In reply to this post by timrowledge

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 <[hidden email]>:

> On 2019-04-12, at 12:30 AM, [hidden email] 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LA: Lockout Access

Jakob Reschke

Re: The Trunk: Collections-fn.825.mcz

In reply to this post by Chris Muller-3

Am Fr., 12. Apr. 2019 um 23:56 Uhr schrieb Chris Muller <[hidden email]>:

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.

Karl Ramberg

Re: The Trunk: Collections-fn.825.mcz

In reply to this post by Jakob Reschke

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 <[hidden email]> 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 <[hidden email]>:

> On 2019-04-12, at 12:30 AM, [hidden email] 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LA: Lockout Access