you know when you have a ring ({} @>) and you want to input something dynamic to it without it running, like for example, if you want something to do this:
({((a) + (b))} @>) and have (a) and (b) values outside of the ring
{return a plus ((a)) ((b)) :: reporter} :: hat define
report ({((a) + (b))} @>)
then i use it
call (return a plus (2) (3) :: reporter) @> //it would give an error saying a and b dont exist
how do i fix this
You can say any of
or just
i made a custom return value and a custom call, the return value is list ({(#1) + (#2)} input names: ((#1)) ((#2))@<>) (list [12] [34]@<>) @<>
how it interprets it is call (item (1 v) of (the return value)) input list: (item (2 v) of (the return value))
or if you want to do it, drag the script pic into your project
also how do script pics make a script into your project when dragged into the project
It would perhaps be easier if you explained what you're really trying to do.
So for one thing I think you meant
(without the extra LIST block)
When I make that change, what you are making is a syntax tree, which you have to turn into a block before you can call it:
(You have to unringify the JOIN after dragging it into the CALL block.)
Or you can put the JOIN inside your custom block definition:
But this is very roundabout; I don't see what it's buying you.
why doesnt it work
i expect
({\ go to x:(70.39058011260045) y: (-52.63802882651646) point in direction (210) } @>)
A. You don't need input variables just for that
B. The inputs are only applied to the first block, then to upvar names in the ring (No clue why, though.)
I meant no clue why inputs are only applied to the first block.
When you don't create a proper syntax tree, unexpected things can happen. I won't get into why your script behaves the way it does, only how to fix it.
To understand what to do, let's take a look at the syntax tree from split by blocks:
You need to replicate this syntax tree with your code using list blocks.
ok thanks but i also figured it out before, its just that i thought
join input list: (list ({\
go to x: (a) y: (b)
point in direction (c)
} input names: ((a)) ((b)) ((c))@<>) [0] [0] [90]@<>)
would be
({\
go to x: (0) y: (0)
point in direction (90)
}@>)
Ah, you want to know why. Joining a script with multiple blocks with some inputs will only plug those inputs into the first block, as you have seen. Any additional inputs become input names in the ring (this is actually the way to get input names in a ring). Sometimes the syntax tree is counterintuitive, but once you get the hang of it you'll find you can do far more than a simpler setup would allow.