Comments on: Is UNSET allowed normally as an argument?

Carl Sassenrath, CTO
REBOL Technologies
29-Aug-2007 14:25 GMT

Article #0100
Main page || Index || Prior Article [0099] || Next Article [0101] || 6 Comments || Send feedback

Currently in R3, you can type:

>> form ()
== "!unset?!"

This means FORM accepts UNSET as an argument. But, should it?

The definition of UNSET is the value of an variable or expression when it has no value.

For example, the unset variable below returns false when tested for a value:

>> value? 'a-variable
== false

In general, UNSET is intended to throw errors to avoid proceeding too far in evaluation without detecting the missing value.

Currently, in R3 UNSET is allowed as a value for any function argument. It can be seen here:

>> f: func [a] [print :a]
>> f ()
== "unset!"

So, UNSET is being passed as an argument to the function.

But, in R2, to pass UNSET, you had to explicitly specify it in the function's arguments:

f: func [a [integer! unset!]] ...


f: func [a [any-value!]] ...

This allows UNSET to be passed; otherwise, it will generate an error (and it is a useful error at the function interface level, because we can tell the user what is missing, as in "argument a has no value").

That seems like the correct behavior (R2)... but what are your thoughts on it?



29-Aug-2007 11:37
I think the R2 behaviour is correct. What you are describing is the road to void pointers (or at least a road that feels that way).

And the beauty of Rebol is that it doesn't need such a road.

Brian Tiffin
30-Aug-2007 2:32:47
Ditto on maarten's comment. :typo not tripping an error (in the general case) seems like a slippery slope.

Handling unset! should be explicit and not implied.

30-Aug-2007 7:31
The question relates only to the behaviour of func [a] ... In R2 it behaves like a type specifier using an implicit pseudotype called Any!. The main difference between R3 and R2 (R3 being more strict) I see in the fact, that even #[unset!] has to be passed explicitely, i.e. (type?) is OK in R2, but causes error in R3. Regarding the implicit Any! pseudotype: I don't mind which option is picked, if the users prefer the R2 behaviour, then I am OK with it, since I am able to use a different spec if I wish so. Maybe the Any! typeset could be defined explicitely then?
30-Aug-2007 7:43:34
Regarding the spec of some functions, if the R2 behaviour is picked: I would prefer Mold to accept Any-type! in that case, ditto for the Form function. Even for the comparison functions I would prefer to be able to compare Any-type! with Any-type! On the :typo issue Brian mentions above: don't use get-word if you want to have the variable checked. The get-word usage is special and should not be used too often, so I guess the R3 behaviour is better - you have got the protection when using the standard word approach and at the same time you have got another alternative when using get-word.
maxim olivier-adlhoch
7-Sep-2007 12:15:46
Although ladislav's details daunt me a little, I'll second the general opinion that implicit (default) of unset being unsuported in general useage is much more usefull.

how many times would I have had to debug for ages trying to figure out why something goes awry and then where I forgot to return a value after putting a print at the tail of a function! hehe.

7-Sep-2007 16:13:19
Max: "I forgot to return a value after putting a print at the tail of a function! hehe." - but this is unrelated to the subject. Even in R2 you can do that without the interpreter noticing your fault, since the datatype of the function return value cannot be specified yet. The only exception in R2 being error! datatype, but only if you don't use Return.

Post a Comment:

You can post a comment here. Keep it on-topic.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font span div a p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 30-Mar-2017 - Edit - Copyright REBOL Technologies -