To make a function with default argument, I tried this:
f: function [a b] [either unset? :b [a + 1] [a + b]]
f 5
f 3 5
then I receive this message *** Script Error: f is missing its b argument.
So, what shall I do?
There's a trick to implement variable-arity functions that some of the built-ins use, most notably help:
>> ? help
...
ARGUMENTS:
'word [any-type!]
Specify your argument as quoted and belonging to any-type! typeset. Or, alternatively, list the allowed types and include unset! in it.
>> foo: func [a 'b [unset! integer!]][a + do pick [1 b] unset? :b]
== func [a 'b [unset! integer!]][a + do pick [1 b] unset? :b]
>> foo 5
== 6
>> foo 3 5
== 8
This, however, comes at a certain price:
Optional arguments must come in succession after the mandatory ones.
All such function calls within a script now need to be wrapped in parentheses, because otherwise there's no way for the interpreter to guess where your variadic expression ends.
You lose the benefits of type-checking, since any-type! accepts any argument; ' in front of the argument also enforces specific semantics, which makes such variadic functions even more cumbersome.
Your code becomes unidiomatic: the conventional way to address the need for optional arguments is via refinements. Variadic functions are usually implemented with a single block! argument, which might even be dialected.
Such an approach is justified only for user-facing polymorphic functions, intended to be used from command-line prompt (such as help) or any other kind of interface that provides clear-cut boundaries for typed expressions (e.g. end of the line, special terminating symbol), and even then the number of optional arguments is kept at minimum.
You can use a refinement. See: http://helpin.red/Functions.html
For example:
>> increase: function [a /add b] [either none? b [a + 1] [a + b]]
== func [a /add b][either none? b [a + 1] [a + b]]
>> increase 3
== 4
>> increase/add 3 5
== 8
Related
How can I pass a function as an argument in red?
Or would I not need that in red?
Using does I can define a function "with no arguments or local variables"
f: does [print 1] do f
>> 1
How can I make this work with (multiple) args? does is no the way, what is?
I want something like: (the following does NOT work):
; does NOT work
f: does-with-args [x][print x] do f 23
>> 1
In the last paragraph of this article http://blog.revolucent.net/2009/05/javascript-rebol.html the author says "allow functions to be passed as arguments" so I got excited, but it's also just using does :). But I learned it's possible.
How can I pass a function as an argument in red?
It doesn't seem this is the essence of your question, but you can pass a function as an argument in a couple of ways:
my-func: func [their-func [any-function!]][their-func "Stuff"]
my-func :print
my-func func [thing][probe uppercase thing]
How can I make this work with (multiple) args?
There are two possibilities here. One is APPLY:
my-func: func [thing][print uppercase thing]
apply :my-func ["Foo"]
Another is to build up a block and DO it:
do collect [keep 'my-func keep "Bar"]
do collect [keep :my-func keep "Baz"] ; keeps the function itself
NB: APPLY can be quirky and I don't think is in Red as yet, worth experimenting.
Correct me wherever I am wrong.
When we use the variables inside braces, the value won't be replaced during evaluation and simply passed on as an argument to the procedure/command. (Yes, some exception are there like expr {$x+$y}).
Consider the following scenarios,
Scenario 1
% set a 10
10
% if {$a==10} {puts "value is $a"}
value is 10
% if "$a==10" "puts \"value is $a\""
value is 10
Scenario 2
% proc x {} {
set c 10
uplevel {set val $c}
}
%
% proc y {} {
set c 10
uplevel "set val $c"
}
% x
can't read "c": no such variable
% y
10
% set val
10
%
In both of the scenarios, we can see that the variable substitution is performed on the body of the if loop (i.e. {puts "value is $a"}), whereas in the uplevel, it is not (i.e. {set val $c}), based on the current context.
I can see it as if like they might have access it via upvar kind of stuffs may be. But, why it has to be different among places ? Behind the scene, why it has to be designed in such this way ? Or is it just a conventional way how Tcl works?
Tcl always works exactly the same way with exactly one level of interpretation, though there are some cases where there is a second level because a command specifically requests it. The way it works is that stuff inside braces is never interpolated or checked for word boundaries (provided those braces start at the start of a “word”), stuff in double quotes is interpolated but not parsed for word boundaries (provided they start a word), and otherwise both interpolation and word boundary scanning are done (with the results of interpolation not scanned).
But some commands send the resulting word through again. For example:
eval {
puts "this is an example with your path: $env(PATH)"
}
The rule applies to the outer eval, but that concatenates its arguments and then sends the results into Tcl again. if does something similar with its body script except there's no concatenation, and instead there's conditional execution. proc also does the same, except it delays running the code until you call the procedure. The expr command is like eval, except that sends the script into the expression evaluation engine, which is really a separate little language. The if command also uses the expression engine (as do while and for). The expression language understands $var (and […]) as well.
So what happens if you do this?
set x [expr $x + $y]
Well, first we parse the first word out, set, then x, then with the third word we start a command substitution, which recursively enters the parser until the matching ] is found. With the inner expr, we first parse expr, then $x (reading the x variable), then +, then $y. Now the expr command is invoked with three arguments; it concatenates the values with spaces between them and sends the result of the concatenation into the expression engine. If you had x previously containing $ab and y containing [kaboom], the expression to evaluate will be actually:
$ab + [kaboom]
which will probably give you an error about a non-existing variable or command. On the other hand, if you did expr {$x + $y} with the braces, you'll get an addition applied to the contents of the two variables (still an error in this case, because neither looks like a number).
You're recommended to brace your expressions because then the expression that you write is the expression that will be evaluated. Otherwise, you can get all sorts of “unexpected” behaviours. Here's a mild example:
set x {12 + 34}
puts [expr $x]
set y {56 + 78}
puts [expr $y]
puts [expr $x * $y]
Remember, Tcl always works the same way. No special cases. Anything that looks like a special cases is just a command that implements a little language (often by calling recursively back into Tcl or the expression engine).
In addition to Donal Fellows's answer:
In scenario 2, in x the command uplevel {set val $c} is invoked, and fails because there is no such variable at the caller's level.
In y, the equivalent of uplevel {set val 10} is invoked (because the value of c is substituted when the command is interpreted). This script can be evaluated at the caller's level since it doesn't depend on any variables there. Instead, it creates the variable val at that level.
It has been designed this way because it gives the programmer more choices. If we want to avoid evaluation when a command is prepared for execution (knowing that the command we invoke may still evaluate our variables as it executes), we brace our arguments. If we want evaluation to happend during command preparation, we use double quotes (or no form of quoting).
Now try this:
% set c 30
30
% x
30
% y
10
If there is such a variable at the caller's level, x is a useful command for setting the variable val to the value of c, while y is a useful command for setting the variable val to the value encapsulated inside y.
I was reading Bindology and tried this:
>> type? first ['x]
== lit-word!
>> type? 'x
== word!
I expected type? 'x to return lit-word! too. Appreciate any insights.
A LIT-WORD! if seen in a "live" context by the evaluator resolves to the word itself. It can be used to suppress evaluation simply with a single token when you want to pass a WORD! value to a function. (Of course, in your own dialects when you are playing the role of "evaluator", it's a Tinker-Toy and you can make it mean whatever you want.)
Had you wanted to get an actual LIT-WORD! you would have to somehow suppress the evaluator from turning it into a WORD!. You noticed that can be achieved by picking it out of an unevaluated block, such as with first ['x]. But the more "correct" way is to use quote 'x:
>> type? quote 'x
== lit-word!
Beware an odd bug known as "lit-word decay":
>> x-lit: quote 'x
>> type? x-lit
== word!
That has been corrected in Red and is pending correction in Rebol. Until then you have to use a GET-WORD! to extract a lit-word value from the variable holding it:
>> x-lit: quote 'x
>> type? :x-lit
== lit-word!
(You may have already encountered this practice as the way of fetching the value of a word vs. "running" it through the evaluator...as when you want to deal with a function's value vs. invoking it. It should not be necessary on values holding lit-word!. Accident of history, it would seem.)
I have attempted to pass a function as a parameter in the REBOL programming language, but I haven't figured out the correct syntax yet:
doSomething: func [a b] [
a b
a b
]
doSomething print "hello" {This should pass print as the first argument and "hello" as the second argument.}
This produces an error, since the print function is being called instead of being passed:
hello
*** ERROR
** Script error: doSomething does not allow unset! for its a argument
** Where: try do either either either -apply-
** Near: try load/all join %/users/try-REBOL/data/ system/script/args...
Is it possible to pass the print function as a parameter instead of calling the print function?
I've found the solution: I only need to add : before the name of the function that is being passed as a parameter.
Here, the :print function is being passed as a parameter instead of being invoked with "hello" as its argument:
doSomething: func [a b] [
a b
a b
]
doSomething :print "hello" {This should pass print as the first argument and "hello" as the second argument.}
You have discovered that by the nature of the system, when the interpreter comes across a WORD! symbol type which has been bound to a function, it will invoke the function by default. The default interpreter seeing a GET-WORD! symbol type, on the other hand, suppresses invocation and just returns the value the word is bound to.
The evaluator logic is actually rather straightforward for how it reacts when it sees a certain symbol type. Another way of suppressing invocation is the single quote, which will give you a LIT-WORD! symbol... but these become evaluated as the corresponding WORD! when it sees them:
>> some-word: 'print
>> type? some-word
== word!
In fact, the behavior of a GET-WORD! when the evaluator sees it is equivalent to using the GET function with a WORD!
doSomething: func [a b] [
a b
a b
]
doSomething get 'print "hello" {Message}
The interpreter sees the LIT-WORD! 'print and evaluates that into the WORD! for print, which is then passed to GET, which gives you a FUNCTION! back.
Simplicity of the interpreter logic is why you get things like:
>> a: b: c: 10 print [a b c]
10 10 10
Due to the nature of how it handles a SET-WORD! symbol followed by complete expressions. That yields also the following code printing out 20:
if 10 < a: 20 [
print a
]
Other languages achieve such features with specialized constructs (like multiple initialization, etc.) But Rebol's logic is simpler.
Just wanted to elaborate a bit to help explain what you were looking at. My answer to this other question might provide some more insight into the edge cases, historical and future: "When I use error? and try, err need a value"
Let's say I have
o: context [
f: func[message /refine message2][
print [message]
if refine [print message 2]
]
]
I can call it like this
do get in o 'f "hello"
But how can I do for the refinement ? something like this that would work
>> do get in o 'f/refine "hello" "world"
** Script Error: in expected word argument of type: any-word
** Near: do get in o 'f/refine
>>
I don't know if there's a way to directly tell the interpreter to use a refinement in invoking a function value. That would require some parameterization of do when its argument is a function! Nothing like that seems to exist...but maybe it's hidden somewhere else.
The only way I know to use a refinement is with a path. To make it clear, I'll first use a temporary word:
>> fword: get in o 'f
>> do compose [(to-path [fword refine]) "hello" "world"]
hello
world
What that second statement evaluates to after the compose is:
do [fword/refine "hello" "world"]
You can actually put function values into paths too. It gets rid of the need for the intermediary:
>> do compose [(to-path compose [(get in o 'f) refine]) "hello" "world"]
hello
world
P.S. you have an extra space between message and 2 above, where it should just be message2
Do this:
o/('f)/refine "hello" "world"
Parens in a path expression are evaluated if they correspond to object field or series pick/poke index references. That makes the above code equivalent to this:
apply get in o 'f ["hello" true "world"]
Note that apply arguments are positional, so you need to know the order the arguments were declared in. You can't do that trick with the function refinements themselves, so you have to use apply or create path expressions to evaluate if you want to parameterize the refinements of the function call.
Use the simple path o/f/refine