Ticket #0001636

Type	Wish	Status	submitted	Date	22-Jul-2010 21:43
Version	alpha 102	Category	Mezzanine	Submitted by	maxim
Platform	All	Severity	minor	Priority	normal

Summary	add 'LAST? as a mezzanine
Description	I was looking for 'LAST? and it never occured to me that 'SINGLE? existed. I think 'LAST? fits in much better with the current series handling naming. 'SINGLE? and 'LAST? could an alias of each other or we could make one specifically none! tolerant. In the later case, I'd let 'LAST? be more tolerant.
Example code	last?: func [series [series! none!]][ all [series 1 = length? series] ] numbers: [1 2 3] last? find numbers 3 == true

Assigned to	n/a	Fixed in	-	Last Update	24-Jul-2010 00:58

Comments
(0002459) BrianH 24-Jul-2010 00:58	HEAD? and TAIL? don't accept none, and that's a good thing. This would be like those functions. We want the unexpected nones to be caught, and the errors triggered when none is passed to a function that doesn't conceptually apply to none (like LAST?) help the programmer track down where their erroneous code is. And the closer to the source of the none the error can be triggered, the better. Propagating or ignoring the none should only be done under extremely limited circumstances. Related to this ticket is #1626, where LENGTH? would return none when passed none. Returning none in that case is specifically what makes accepting none make any sense, but it is also reason why the ticket may be dismissed. As in this case, LENGTH?'s normal return values (integers) are not a correct answer if the function is passed none. However, it's not so bad because none is not a number, and so will definitely trigger an error if the none is not screened for later. If LAST? took none as an argument, neither true nor false would be a correct answer, since the LAST? concept doesn't apply to nothing. But if you return none then the result might be used in a conditional expression, where none is often treated the same as false. Since false is definitely the wrong answer, this means that this error would be much more difficult to track down. The policy for the built-in functions in R3 is to make sure that they trigger helpful errors whenever they are being asked to do something inappropriate. And we are supposed to try to trigger those errors as close to the source as possible, for the benefit of the developer who needs these errors to help them track down the bugs they need to fix. Every time we let that slip we lose a little of the benefit of those errors, so we are very wary and careful before we break that rule. In the case of functions that return true or false, returning none when the function is inapplicable doesn't really work because we don't have 3-valued logic like SQL - none is not UNKNOWN. Which is why we have only broken that rule once for a logical-condition function, and even then we only allowed it for EMPTY? because the concept could in theory apply to nothing, but not TAIL? which can't apply to nothing. Neither SINGLE? nor LAST? apply to nothing, so both of them should trigger an error. Aside from all that, renaming SINGLE? to LAST? would be a good idea, because LAST? fits in better with LAST, like HEAD? fits in with HEAD. There is probably no reason to have both names, though we may need to for a transitional period while code is converted. Note that since SINGLE? has been backported to R2 2.7.7, the rename would need to be backported as well. That existing-code problem would be the main reason why we would keep both names.

Comments

(0002459)
BrianH
24-Jul-2010 00:58

HEAD? and TAIL? don't accept none, and that's a good thing. This would be like those functions. We want the unexpected nones to be caught, and the errors triggered when none is passed to a function that doesn't conceptually apply to none (like LAST?) help the programmer track down where their erroneous code is. And the closer to the source of the none the error can be triggered, the better. Propagating or ignoring the none should only be done under extremely limited circumstances.

Related to this ticket is #1626, where LENGTH? would return none when passed none. Returning none in that case is specifically what makes accepting none make any sense, but it is also reason why the ticket may be dismissed. As in this case, LENGTH?'s normal return values (integers) are not a correct answer if the function is passed none. However, it's not so bad because none is *not* a number, and so will definitely trigger an error if the none is not screened for later.

If LAST? took none as an argument, neither true nor false would be a correct answer, since the LAST? concept doesn't apply to nothing. But if you return none then the result might be used in a conditional expression, where none is often treated the same as false. Since false is definitely the wrong answer, this means that this error would be much more difficult to track down.

The policy for the built-in functions in R3 is to make sure that they trigger helpful errors whenever they are being asked to do something inappropriate. And we are supposed to try to trigger those errors as close to the source as possible, for the benefit of the developer who needs these errors to help them track down the bugs they need to fix. Every time we let that slip we lose a little of the benefit of those errors, so we are very wary and careful before we break that rule.

In the case of functions that return true or false, returning none when the function is inapplicable doesn't really work because we don't have 3-valued logic like SQL - none is not UNKNOWN. Which is why we have only broken that rule once for a logical-condition function, and even then we only allowed it for EMPTY? because the concept could in theory apply to nothing, but not TAIL? which can't apply to nothing. Neither SINGLE? nor LAST? apply to nothing, so both of them should trigger an error.

Aside from all that, renaming SINGLE? to LAST? would be a good idea, because LAST? fits in better with LAST, like HEAD? fits in with HEAD. There is probably no reason to have both names, though we may need to for a transitional period while code is converted. Note that since SINGLE? has been backported to R2 2.7.7, the rename would need to be backported as well. That existing-code problem would be the main reason why we would keep both names.

Date	User	Field	Action	Change
24-Jul-2010 01:32	BrianH	Comment : 0002459	Modified	-
24-Jul-2010 01:27	BrianH	Comment : 0002459	Modified	-
24-Jul-2010 00:58	BrianH	Comment : 0002459	Added	-
22-Jul-2010 21:43	maxim	Ticket	Added	-