RFC: Function :arg behavior

Carl Sassenrath, CTO
REBOL Technologies
23-Mar-2007 20:06 GMT

Article #0072
Main page || Index || Prior Article [0071] || Next Article [0073] || 14 Comments || Send feedback


RFC: Request for comments. And, I mean request for comments, not "it is already a standard" like most RFCs you find on the net. Now is when you should comment.

In R2 and currently in R3, a get-word function can be used to define a formal argument:

f: func [:arg] [print type? :arg]

This notation means: get the next value, and if it is a word, lookup its value, but do not evaluate it.

>> f 10
>> f f

This is of marginal use, because it is standard to use 'arg then get the value:

f: func ['arg] [... get arg]

If no one uses :arg, what if we modified it to mean: get the function argument block at the current location. For example:

f: func [:arg] [probe arg]
>> f 1 a "test"
[1 a "test"]

That can be useful as a way to implement optional arguments, such as those used for console shell-style commands (e.g. list-dir). This is more important because this type of specification:

f: func [arg [file! unset!]] [probe arg]

is ambiguous to the end-of-block case, and in R3 will produce an error if the block ends before the arg is found.

Of course, on the downside, the :arg allows a function to potentially modify its code stream. I can only imagine the endless hacks that would inspire, good and bad.

This is somewhat similar to read-macro handling in various functional languages. However, it's not yet apparent how to advance the input stream by a specific amount on function return.


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