dockimbel on master
FEAT: minor code readibility im… (compare)
Composite syntax :point_up:
On the chance that we want to support
@"..." syntax for
ref! someday, let's not do that.
Double sigils, head+tail are unattractive to me, and those with spaces required are problematic from a general "whitespace separates values" standpoint.
If it's a macro, I don't mind it looking like one, with a leading
# sigil. The editorial "change/insert" mark is
^, which is a problem in Red.
~ is close to "transpose", but that meaning isn't a great match for "substitute".
I still like aspects of the backtick, but #` is pretty subtle. #`` less so.
The number of bracketed string types in Red makes the other options quite ugly. As a more traditional macro it could also work for composing blocks at compile time. More thought required.
@greggirwin Let's see, I am currently working on Rebol on a way to send remotely the current command and start it there from inside the called function:
get-command-line: func [ "Returns a block ready to be transmitted that replicates the current function start parameters" fname [word!] "The name of the functions" args [block!] "The argument words inside a block" refinements-block [block!] "The refinement block in the form [/refname [arg1 arg2] /refname [arg3 arg4]]" bound-word [word!] "A word of the caller function context" /specs the-specs /local out-data remote-command refs argument-refs arguments argg command-line in-block; block with refinements ] [ args: copy args refinements-block: copy refinements-block remote-command: to-path fname ;--- Here we neutralize functions in words on reduce ; forall args [ if word? first args [change args to-get-word pick args 1] ] ;--- Here we neutralize functions in words on reduce ; forall refinements-block [ if block? in-block: first refinements-block [ forall in-block [ if word? first in-block [change in-block to-get-word pick in-block 1] ] ] ] refs: copy  arguments-ref: copy  arguments: reduce append copy  args parse refinements-block [ any [ set ref refinement! set argg block! ( if true = first reduce [get in bound? bound-word ref] [ append remote-command to-word ref append arguments :argg ] ) | set ref refinement! ( if true = first reduce [get in bound? 'server ref] [ append remote-command to-word ref] ) | skip ] ] command-line: mold/all reduce compose [remote-command (arguments)] ] afunction: func [a b /c d e] [ probe get-command-line 'afunction [a b] [/c [d e]] 'a ] >> afunction/c 1 2 3 does  "[afunction/c 1 2 3 #[function! ]]"
Many things are still not there in Red to redo this but it is maturing from day to day.
third bound? 'ato get the needed argument for
get-command-linebut there is a terrible bug: if you ask the context of a local word of a function, it is returned without the first word of the context.
>> a: func [ c: 2 ]][ ] >> a 1 2 make object! [
bound?behavior. I've posted my
refineexperiments in the past, which may be applicable. It looks like you're trying to bind parts of a remote call to different contexts, but I don't know why you'd do that. If you're making remote calls, you shouldn't know anything about the server side.
Bound?on Rebol is Buggy, as you can see: :point_up: 27 giugno 2021 00:52
I am experimenting into creating commands that can be run either locally or remotely:
A command could be run as
command/ref arg1 arg2 refarg1
but if you write
server: HTTP://192.168.0.22 command/ref/remote arg1 arg2 refarg1 server
command creates a block with its name and parameter, and executes it remotely. Then it receives the result from the remote server.
Using a refinement to make it remote seems to be the complicating factor. As far as you're concerned, a call is complete (
command/ref arg1 arg2 refarg1), correct? So you can store that internally as a block, and make the remote part separate if it's used.
my-call: [command/ref arg1 arg2 refarg1] do my-call ; local RPC reduce [my-call 'on server] ; remote, semi-dialected block for fun.
RPC does all the magic and the func is none the wiser.
RPCsends the block to the server who
does it, and returns the result.
I don't know about
RPC function but I remember having seen it in Cheyenne.
Yes, refinement is the complication factor but I have chosen to have it on purpose. I have already made experiments with:
Mostly I have experimented creating functions whose arguments is a block or an object containing the arg/value pairs and build the internal function context bypassing the function interface, doing everything by hand. It worked well but the experiment goals is to pass regular Redbol commands and bind them to a remote object with contains the "allowed" commands and I want to take into the picture passing refinements too.
This It is the most difficult thing as I have no way to get a
make specs with refinents as set words.
RUN-REMOTE. You simply provide a block of code and it Is executed remotely and you receive the return value.
/remoterefinement set and passing the server address, so they recreate the command needed to run themselves. This to not change the current usual coding, otherwise everything would become
run-remote compose [command/arg (arg1 arg2 arg3 refarg)]
applysyntax. I will try.
/remote serverthe command just dispatches the request to an execution server`
@greggirwin Another option to transfer the current function context words and refinements and the values, is to use the
set syntax. It is perfect for keeping trace of refinements:
ctx: [[a b c /red ref-arg] [a b c false false]]
You have just to convert
/red to word before executing
values-of will be implemented for function it will be easy to write
ctx: reduce [words-of context? 'ref values-of context? 'ref]
set words argument could accept refinements, so you can simply write:
set ctx/1 ctx/2
By far my most common case for filenames is date-naming them, which isn't a good match for
compositeand handled better by
It's good until you want to customize it a lot.
[[keys][values]]split form with refinement you have to make a last management of the keys block to extrapolate the refinements, change to words and build a separate refinements block in case you would need this information.
It's good until you want to customize it a lot.
I guess I've always customized them a lot, because it's so helpful IMO. e.g. zero padding counts and ISO8601 formatting dates, so lexical sorting works.
`"..."`is so utterly bad for you, let's consider just an empty issue
# "...", because
#`is completely ugly and using only opening quote makes no sense to me, if it's quotes they should be on both ends.
# "..."is somewhat similar to char syntax though. But then any other symbol allowed in issues will be better than backquote.
Which way to you guys use
try most of the time?
if error? try [...] [..after-error recovery..]
set/any 'err try [...] (... later err is processed...)
Please post your answers into thread if possible. Thanks.