@GiuseppeChillemi
Vladimir can answer in any way he wants to me.
Great :smile:
@9214
Well, I have tried the SET words-block values-block
solution with no success.
test: function
[
action
passed-args-block [block!]
]
[
args-def: [
add
[
the-path [string!]
key [word!]
value [any-type!]
]
del
[
the-path [string!]
key [string!]
]
]
function-words: extract select args-def action 2
set function-words passed-args-block
]
test 'add ["a-path" "a-key" "a-value"]
probe the-path
probe key
probe value
"a-path"
"a-key"
"a-value"
>>>
Words set into function
seems to exists after function exit:
function
only collect set words (+ some exception) and [the-path key value] are words.function
, after first ]
. Your code might compile but it won't run correctly in the repl.
-c
option to compile as you work. It’s much faster than -r
(release mode).@nedzadarek
ps. if you want post simple code snippets that people would run in the repl then avoid unnecessary new lines (e.g. after
function
, after first]
. Your code might compile but it won't run correctly in the repl.
Those "unnecessary" new lines avoid me being confused. Words are isolated and clear and there are not so many symbols that my mind have to decode.
Bind 'word self
with no success. Now I am wondering if SET
could have a /current context refinement, to express the context that RED automatically adds to words. Another way would be to have a SET/BIND
where you can express one in some way as argument of SET
.
function
is auto-localising only set-words and using set
with a lit-word explicitly bypasses that mechanism, adding should-be-local
to the global context. Even if should-be-local
would've been declared in the function's context, bind 'should-be-local 'test
would rebind it to the context thetest
word is bound to. With the context of the test
word being the global context rather than the function's context (as you seem to assume).
@gurzgri Having a lot of functions operating on the the same kind of dataset, usually you have identical or simular arguments block.
I am experimenting a "simpler" approach which let me express in a way like:
db 'add-table [arguments]
db 'delete-table [arguments]
db 'add-row [arguments]
This because, as I have written: [arguments] is the same for 2 or more functions. Selecting them from a table let me:
1) Change the argument interface once and for all
2) Save a lot of typing
About this point I have still not show the block of code which maps an arguments to multiple methods.
mapping: [
arguments-block-name-a [method1 method2 method3]
arguments-block-name-b [method4 method5]
]
or another one (have to choose)
mapping: [
method1 arguments-block-name-a
method2 arguments-block-name-a
method3 arguments-block-name-a
method4 arguments-block-name-b
method5 arguments-block-name-b
]
(In my mind I see also function composing built from tables of code but If I won't solve this problem I can't further experiment)