Fun with Number readFrom: What should we do ?

> Hello all,
>
> i noticed that Number readFrom: silently answers 0 when it does not encounter
> some digits:
>
>     Number readFrom: '' readStream.
>     Number readFrom: 'foo-bar' readStream.
>     Number readFrom: '.' readStream.
>
> will all answer 0. Well, i believe there must have been discussions whether or
> not raising an exception in this case, at least recently in vw list.
> But let us say that answering 0 is a feature.
>
>
> Then try:
>
>     Number readFrom: 'rules are made for the others' readStream.
>
> fail with an error: 'Invalid radix'.
> Well, well, don't tell me it is a feature.
>
>
> And just for fun, this one:
>
>     Number readFrom: '.e' readStream.
>
> ah, another feature UndefinedObject doesNotUnderstand: #digitValue.
>
>
> Still want to play ? Try this one:
>
>     Number readFrom: '--1' readStream.
>
> Amazing what we can do with just one readFrom:...
>
>
> Funny, it also accept some un-Smalltalk-ish syntax:
>
>     Number readFrom: '.1e2'.
>     Number readFrom: '1.e1'.
>
> will answer a Float (10.0 like FORTRAN).
> I suppose this one is intentionnaly a feature.
>
>
> I will not analyze here the cases when the stream advance, and the cases when
> it does not... That would be boring...
>
>
> Now i am trying to implement Float readFrom without accumulating rounding
> errors, and this can be the right time for deciding about these cases.
>
> What do you vote for ? exception, answering 0, any other idea ?
> What to do with the stream in case of error ? rewind, keep in place ?
> I'am waiting for your comments.
>
> Nicolas
>
>
>

> I fully agree, but since it is a long living bug, present in other  
> dialects,
> maybe someone have used it as a feature, so it's better asking.
>
> What about the FORTRANISH 1.e1 and .1e2 ? Anyone use it ?
> I like it because i had apps reading this kind of format, but maybe  
> my opinion
> is biased... Another specific selector able to read +.1e+2 might be  
> better...
> One point of view is to enforce Smalltalk syntax only in readFrom:
> On the other hand we have already the nan and infinity exceptions...
>
> Nicolas
>
> Le Mercredi 26 Avril 2006 23:45, Andreas Raab a écrit :
>> Clearly, that's a bug not a feature. And it should raise an  
>> exception -
>> the empty string is *not* a valid zero value (but if anyone needs  
>> that
>> behavior they can handle the exception). About stream rewinding:  
>> Doesn't
>> matter - I don't think anyone should rely on stream positioning in  
>> the
>> case of an error.
>>
>> Cheers,
>>    - Andreas
>
>
>

> nicolas cellier wrote:
> ...
>
> > What do you vote for ? exception, answering 0, any other idea ?
> > What to do with the stream in case of error ? rewind, keep in place ?
> > I'am waiting for your comments.
>
> Answering nil of course. To answer 0 is outright wrong and raising an
> exception is at least to cumbersome. One could rate it being wrong too,
> because unknown text that has to be converted is a valid input, and thus
> finding no correct float is a valid result - nil.
>
> Regards,
> Martin

> nicolas cellier wrote:
> ...
>
> > What do you vote for ? exception, answering 0, any other idea ?
> > What to do with the stream in case of error ? rewind, keep in place ?
> > I'am waiting for your comments.
>
> Answering nil of course. To answer 0 is outright wrong and raising an
> exception is at least to cumbersome. One could rate it being wrong too,
> because unknown text that has to be converted is a valid input, and thus
> finding no correct float is a valid result - nil.
>
> Regards,
> Martin

> But with mine, you can also have a global exception handling:
>   [value1 := Number readfrom: aStream.
>     value2 := Number readFrom: aStream]
>       ifError: [global handler block]
>
> Maybe a new exception class is better than Error, but i do not take this
> responsability alone.
>   [value1 := Number readfrom: aStream.
>     value2 := Number readFrom: aStream]
>       on: NumberReadError do: [:exc | global handler block]
>
> Hope i convinced someone.
>
> Nicolas

> Le Jeudi 27 Avril 2006 12:14, vous avez écrit :
>
>>nicolas cellier wrote:
>>...
>>
>>
>>>What do you vote for ? exception, answering 0, any other idea ?
>>>What to do with the stream in case of error ? rewind, keep in place ?
>>>I'am waiting for your comments.
>>
>>Answering nil of course. To answer 0 is outright wrong and raising an
>>exception is at least to cumbersome. One could rate it being wrong too,
>>because unknown text that has to be converted is a valid input, and thus
>>finding no correct float is a valid result - nil.
>>
>>Regards,
>>Martin
>
>
> Hi Martin
> Of course, answering nil is an obvious possibility better than answering 0.
> I longly used this construction before i discovered exceptions, and i will try
> to explain why i have switched to this second preferable style.
>
> Answering nil is exactly the policy adopted in C programs.
> It means that when you write a line of code, you will have 3 lines following
> for handling problems.
> If you omit this post-checking, your C programs can have weird behaviours like
> dumping a core later when uninitialzed values will be used...
>
> The FORTRAN way was better (i think of the READ() instruction):
> - default was to abort the program with an error message (brutal but clean)
> - it was possible to pass a label to branch on in case of error (an early
> exception handling mechanism).
>
> In Smalltalk, we have those nice soft aborption with debugger, better than a
> core dumped, but that does not solve everything, and in fact we face the same
> choice that C-FORTRAN explained above:
>
> Suppose we adopt the nil answer.
> We will have to check for nil after each readFrom: instruction.
> If we lazily omit those nil-checking lines, the problem can appear well later
> in the code when we will try and use the value, and the debugger will not be
> of much use, because it won't point directly at the place where the problem
> come from (the C core dumped case)...
>
> If i have a method with 10 readFrom: , i will have 10 ifNil: blocks for
> handling the exception.
> Maybe the handling can consist simply in answering nil in our turn and reject
> the problem to the sender method, wich will have to check ifNil: in its turn
> und so weiter...
> What i dislike in this C-style is that it makes code less readable because
> main algorithm is scattered among exception handling code.
>
> Suppose now we adopt an exception mechanism.
> I am lazy and do not put an exception handling block (working on a prototype).
> Then the debugger will open exactly where the problem occured.
> I am smarter with the users of my programs and provide an exception handling
> block: then i can factor several exceptions in a single block (the case when
> i do 10 readFrom:), and i can handle the problem several senders above
> without adding noisy ifNil: at each level.
>
> The problem with exception is that if i trap Error, i will trap too many
> errors, not only the readFrom: error. This is not selective enough. This has
> already been discussed on the list, when to create a new exception class ?
> but i do not have the feeling we got a clear answer...
> Untill we address this problem, your ^nil proposition is a candidate though
> not my favourite style. Maybe readFrom: can also call readFrom:ifFail: the
> way Dictionary at: call at:ifAbsent:.
>
> Nicolas
>
>
>

> My proposition is:
>
> Number>>readFrom: aStringOrStream
>     ^self readFrom: aStringOrStream ifFail: [^self error: 'cannot read a
> number']
>
> If nil is what you want, you will have to write:
>     value := Number readFrom: aStream ifFail: [nil].
> A little longer than your proposition:
>     value := Number readfrom: aStream.

> Nicolas,
>
> you are arguing form the premise that some string that is not
> convertible to a float is a problem, an error or an exception. Consider
> a csv file. You would read it with upTo: $;. If you get an empty string
> it does not mean that an error occurred, it means that a piece of
> information is not applicable or available. That is valid information
> and not an error! There are csv files with more than 99% of such empty
> fields.
>
> The same holds true for an unformatted text from which information has
> to be extracted. It is expected that at many places a piece of
> information may or may not appear. And because it is expected it can't
> be an exception ;)
>
> I think if a string can't be converted to a float almost never an error
> should be raised. And if so, some very specific reason has to exist,
> some reason that makes this scenario a real - unforeseeable - error.
>
> For me the bottom line of the 'exception thread' was exactly this: an
> error or an exception is something which is unforeseeable. If you can
> predict that it may happen or if it regularly happens it should get
> handled directly.
>
> Perhaps even more straight: If *possible* it should be handled directly.
> Error handlers are reserved for cases where you don't know when or where
> exactly what may go wrong.
>
> Regards,
> Martin
>
>
> nicolas cellier wrote:
>> Le Jeudi 27 Avril 2006 12:14, vous avez écrit :
>>
>>> nicolas cellier wrote:
>>> ...
>>>
>>>
>>>> What do you vote for ? exception, answering 0, any other idea ?
>>>> What to do with the stream in case of error ? rewind, keep in place ?
>>>> I'am waiting for your comments.
>>>
>>> Answering nil of course. To answer 0 is outright wrong and raising an
>>> exception is at least to cumbersome. One could rate it being wrong too,
>>> because unknown text that has to be converted is a valid input, and thus
>>> finding no correct float is a valid result - nil.
>>>
>>> Regards,
>>> Martin
>>
>>
>> Hi Martin
>> Of course, answering nil is an obvious possibility better than
>> answering 0.
>> I longly used this construction before i discovered exceptions, and i
>> will try to explain why i have switched to this second preferable style.
>>
>> Answering nil is exactly the policy adopted in C programs.
>> It means that when you write a line of code, you will have 3 lines
>> following for handling problems.
>> If you omit this post-checking, your C programs can have weird
>> behaviours like dumping a core later when uninitialzed values will be
>> used...
>>
>> The FORTRAN way was better (i think of the READ() instruction):
>> - default was to abort the program with an error message (brutal but
>> clean)
>> - it was possible to pass a label to branch on in case of error (an
>> early exception handling mechanism).
>>
>> In Smalltalk, we have those nice soft aborption with debugger, better
>> than a core dumped, but that does not solve everything, and in fact we
>> face the same choice that C-FORTRAN explained above:
>>
>> Suppose we adopt the nil answer.
>> We will have to check for nil after each readFrom: instruction.
>> If we lazily omit those nil-checking lines, the problem can appear
>> well later in the code when we will try and use the value, and the
>> debugger will not be of much use, because it won't point directly at
>> the place where the problem come from (the C core dumped case)...
>>
>> If i have a method with 10 readFrom: , i will have 10 ifNil: blocks
>> for handling the exception.
>> Maybe the handling can consist simply in answering nil in our turn and
>> reject the problem to the sender method, wich will have to check
>> ifNil: in its turn und so weiter...
>> What i dislike in this C-style is that it makes code less readable
>> because main algorithm is scattered among exception handling code.
>>
>> Suppose now we adopt an exception mechanism.
>> I am lazy and do not put an exception handling block (working on a
>> prototype). Then the debugger will open exactly where the problem
>> occured.
>> I am smarter with the users of my programs and provide an exception
>> handling block: then i can factor several exceptions in a single block
>> (the case when i do 10 readFrom:), and i can handle the problem
>> several senders above without adding noisy ifNil: at each level.
>>
>> The problem with exception is that if i trap Error, i will trap too
>> many errors, not only the readFrom: error. This is not selective
>> enough. This has already been discussed on the list, when to create a
>> new exception class ? but i do not have the feeling we got a clear
>> answer...
>> Untill we address this problem, your ^nil proposition is a candidate
>> though not my favourite style. Maybe readFrom: can also call
>> readFrom:ifFail: the way Dictionary at: call at:ifAbsent:.
>>
>> Nicolas
>>
>>
>>
>
>
>

> The example of the csv file is very badly chosen IMO. CSV files  
> contain many different things and applying the same logic you are  
> using for numbers here would dictate that String>>readFrom: also  
> answer nil when trying to read from an empty string. Moreover, it  
> would dictate that Strings use double quotes (if I remember my .csv  
> corretly). This has nothing to do with the discussion here - .csv  
> files do NOT contain "Smalltalk numbers" so to speak, therefore  
> they need to be separately parsed and analyzed and arguing that an  
> empty string should parse as nil because .csv files have empty  
> fields is really besides the point of this discussion.
>
> Number>>readFrom: has the specific intent to read a literal number  
> from a stream. I have yet to find a caller that could even deal  
> with the fact that this method may answer nil. This goes mostly to  
> show at what a low level number parsing is typically used (e.g.,  
> all the error checking happens mostly at a higher level) which  
> speaks very clearly for having an exception raised to signal the  
> problem.
>
> @Nicolas: I find your proposal of readFrom:ifFail: to be somewhat  
> overkill. An exception/error seems simpler and more direct to me.
>
> Cheers,
>   - Andreas
>
>
> Martin Wirblat wrote:
>> Nicolas,
>> you are arguing form the premise that some string that is not  
>> convertible to a float is a problem, an error or an exception.  
>> Consider a csv file. You would read it with upTo: $;. If you get  
>> an empty string it does not mean that an error occurred, it means  
>> that a piece of information is not applicable or available. That  
>> is valid information and not an error! There are csv files with  
>> more than 99% of such empty fields.
>> The same holds true for an unformatted text from which information  
>> has to be extracted. It is expected that at many places a piece of  
>> information may or may not appear. And because it is expected it  
>> can't be an exception ;)
>> I think if a string can't be converted to a float almost never an  
>> error should be raised. And if so, some very specific reason has  
>> to exist, some reason that makes this scenario a real -  
>> unforeseeable - error.
>> For me the bottom line of the 'exception thread' was exactly this:  
>> an error or an exception is something which is unforeseeable. If  
>> you can predict that it may happen or if it regularly happens it  
>> should get handled directly.
>> Perhaps even more straight: If *possible* it should be handled  
>> directly. Error handlers are reserved for cases where you don't  
>> know when or where exactly what may go wrong.
>> Regards,
>> Martin
>> nicolas cellier wrote:
>>> Le Jeudi 27 Avril 2006 12:14, vous avez écrit :
>>>
>>>> nicolas cellier wrote:
>>>> ...
>>>>
>>>>
>>>>> What do you vote for ? exception, answering 0, any other idea ?
>>>>> What to do with the stream in case of error ? rewind, keep in  
>>>>> place ?
>>>>> I'am waiting for your comments.
>>>>
>>>> Answering nil of course. To answer 0 is outright wrong and  
>>>> raising an
>>>> exception is at least to cumbersome. One could rate it being  
>>>> wrong too,
>>>> because unknown text that has to be converted is a valid input,  
>>>> and thus
>>>> finding no correct float is a valid result - nil.
>>>>
>>>> Regards,
>>>> Martin
>>>
>>>
>>> Hi Martin
>>> Of course, answering nil is an obvious possibility better than  
>>> answering 0.
>>> I longly used this construction before i discovered exceptions,  
>>> and i will try to explain why i have switched to this second  
>>> preferable style.
>>>
>>> Answering nil is exactly the policy adopted in C programs.
>>> It means that when you write a line of code, you will have 3  
>>> lines following for handling problems.
>>> If you omit this post-checking, your C programs can have weird  
>>> behaviours like dumping a core later when uninitialzed values  
>>> will be used...
>>>
>>> The FORTRAN way was better (i think of the READ() instruction):
>>> - default was to abort the program with an error message (brutal  
>>> but clean)
>>> - it was possible to pass a label to branch on in case of error  
>>> (an early exception handling mechanism).
>>>
>>> In Smalltalk, we have those nice soft aborption with debugger,  
>>> better than a core dumped, but that does not solve everything,  
>>> and in fact we face the same choice that C-FORTRAN explained above:
>>>
>>> Suppose we adopt the nil answer.
>>> We will have to check for nil after each readFrom: instruction.
>>> If we lazily omit those nil-checking lines, the problem can  
>>> appear well later in the code when we will try and use the value,  
>>> and the debugger will not be of much use, because it won't point  
>>> directly at the place where the problem come from (the C core  
>>> dumped case)...
>>>
>>> If i have a method with 10 readFrom: , i will have 10 ifNil:  
>>> blocks for handling the exception.
>>> Maybe the handling can consist simply in answering nil in our  
>>> turn and reject the problem to the sender method, wich will have  
>>> to check ifNil: in its turn und so weiter...
>>> What i dislike in this C-style is that it makes code less  
>>> readable because main algorithm is scattered among exception  
>>> handling code.
>>>
>>> Suppose now we adopt an exception mechanism.
>>> I am lazy and do not put an exception handling block (working on  
>>> a prototype). Then the debugger will open exactly where the  
>>> problem occured.
>>> I am smarter with the users of my programs and provide an  
>>> exception handling block: then i can factor several exceptions in  
>>> a single block (the case when i do 10 readFrom:), and i can  
>>> handle the problem several senders above without adding noisy  
>>> ifNil: at each level.
>>>
>>> The problem with exception is that if i trap Error, i will trap  
>>> too many errors, not only the readFrom: error. This is not  
>>> selective enough. This has already been discussed on the list,  
>>> when to create a new exception class ? but i do not have the  
>>> feeling we got a clear answer...
>>> Untill we address this problem, your ^nil proposition is a  
>>> candidate though not my favourite style. Maybe readFrom: can also  
>>> call readFrom:ifFail: the way Dictionary at: call at:ifAbsent:.
>>>
>>> Nicolas
>>>
>>>
>>>
>
>

>
> Just to say that squeak learners (we all, and that includes
> newbies) can learn a lot from this kind of discussions.
>
> Nicolas
>
> Le Jeudi 27 Avril 2006 21:41, stéphane ducasse a écrit :
> > Just to say that I really enjoy reading this discussion.
> > Please continue and conclude with some enh, fix and tests.
> Excellent!
> >

> My proposition is:
>
> Number>>readFrom: aStringOrStream
>     ^self readFrom: aStringOrStream ifFail: [^self error: 'cannot read a
> number']
>
> If nil is what you want, you will have to write:
>     value := Number readFrom: aStream ifFail: [nil].
> A little longer than your proposition:
>     value := Number readfrom: aStream.