REBOL3 tracker
  0.9.12 beta
Ticket #0001602 User: anonymous

Project:



rss
TypeBug Statustested Date5-May-2010 23:49
Versionalpha 97 CategoryDocumentation Submitted byBrianH
PlatformAll Severitytext Prioritynormal

Summary The value1 argument of =, !=, ==, !== and =? should have [any-type!] typespec
Description The value1 argument in the specs of =, !=, ==, !== and =? should have the [any-type!] typespec, to reflect their actual behavior. These ops already accept any-type! for their left argument, and this behavior is relied on in mezzanine code. But the typespecs of those ops should be changed to match their behavior, for documentation purposes.

Don't change the typespecs of the value2 arguments - they're fine as is.
Example code

			

Assigned ton/a Fixed inalpha 108 Last Update20-Oct-2010 03:43


Comments
(0002353)
Carl
7-May-2010 18:40

BrianH... could you clarify the description? It says: "value1... should have the [any-type!] typespec" but that "ops already accept any-type! for left argument" (which is value1). So, I'm not sure what you mean.
(0002354)
BrianH
7-May-2010 20:56

Those ops all have a value1 argument, which is specified with no typespec. Arguments that are specified with no typespec are in theory not supposed to accept unset! values. However, as a side effect of op! evaluation apparently ignoring the declared type restrictions of their first argument, these ops accept unset! values for their first argument anyways. This makes the typespecs of these ops confusing, their behavior undocumented.

We *want* these ops to accept unset! for their first argument, because otherwise you would have no way of comparing values to unset! other than UNSET?, which would mean that instead of:

(select obj 'field) = :value

we would need to write:

any [all [unset? select obj 'field unset? :value] :value = select obj 'field]

in a lot of low-level, otherwise efficient mezzanine code. Accepting unset! values for their first argument is an acceptable optimization.

So the problem is not the *becavior* of these ops, it is the *documentation* of the behavior of these ops. The typespec of the first argument of an op is just there for documentation purposes - it has no effect on the behavior. So I would like the spec of these ops to include [any-type!] after the first argument, strictly for documentation purposes, so that their HELP will reflect their real behavior.
(0002355)
BrianH
7-May-2010 21:21

Whether op evaluation *should* typecheck the first argument is a completely separate issue. Ops that redirect to actions seem to use action applicability to determine the acceptable types for their first arguments (I haven't tested ops that redirect to natives). So adding an additional typecheck to their evaluation would be redundant. If you think this is a problem, you or I can write up a ticket about it, and you can add the additional typecheck.
(0002356)
Carl
7-May-2010 21:21

Thanks for the detail. A few comments:

1. The specs for ops comes from their functions. So, for '= the spec comes from 'equal?.

2. Should we change the spec for equal? and the others?

3. If an op! is ignoring its typespec, that seems like a bug to me. (Remind me if we discussed this before.)
(0002357)
BrianH
7-May-2010 21:29

I wouldn't mind changing the spec for EQUAL? and the other direct comparison functions to match: The only reason that I use the (code) = value code pattern in the first place is because I can't use EQUAL? code value.

As for whether op! is ignoring its typespec, see my message above. It appears to be only for the first argument (only you can say for sure), but this is not necessarily a bad thing because the types are getting checked later. It would be a problem later on with user-defined ops; perhaps the spec of the redirected function could be used and checked in that case. But we might be able to get by with not adding extra type checking to ops that redirect to actions: There aren't that many actions that have ops, so we could just correct their specs.

I don't recall discussing this with you before. It may have come up when I optimized LOAD and DO with this trick.
(0002520)
Carl
21-Sep-2010 23:41

In A108, the changes to the natives have been made, and thus the ops allow the same.
(0002616)
BrianH
20-Oct-2010 03:40

Note: Both arguments of the equality operators and functions now accept any-type!. If your code depended on an error being triggered in this case, that error will not be triggered anymore.

Date User Field Action Change
20-Oct-2010 03:43 BrianH Status Modified built => tested
20-Oct-2010 03:40 BrianH Comment : 0002616 Added -
21-Sep-2010 23:41 carl Comment : 0002520 Added -
21-Sep-2010 23:41 carl Status Modified reviewed => built
21-Sep-2010 23:41 carl Fixedin Modified => alpha 108
8-May-2010 01:15 carl Comment : 0002356 Modified -
7-May-2010 21:33 BrianH Comment : 0002357 Modified -
7-May-2010 21:31 BrianH Comment : 0002357 Modified -
7-May-2010 21:29 BrianH Comment : 0002357 Added -
7-May-2010 21:21 carl Comment : 0002356 Added -
7-May-2010 21:21 BrianH Comment : 0002355 Added -
7-May-2010 20:56 BrianH Comment : 0002354 Added -
7-May-2010 18:40 carl Comment : 0002353 Added -
7-May-2010 06:52 carl Status Modified submitted => reviewed
6-May-2010 02:16 BrianH Description Modified -
6-May-2010 02:16 BrianH Summary Modified The value1 argument of =, == and =? should have [any-type!] typespec => The value1 argument of =, !=, ==, !== and =? should have [any-type!] typespec
5-May-2010 23:49 BrianH Ticket Added -