On 2018-06-19 10:03, Raphaël Ilias wrote:
Hello !
I'll try to ask this in a few words :
is it possible to dynamically save a $n-symbol as an argument in an abstraction, like you can do with [iemguts/canvasargs] but without "resolving" the $n index declaration ?
The idea would be to reproduce a properties panel as with iem GUIs, and be able to put in symbol boxes, a $0-receiverSymbolicName or $1-$2-senderSymbolicName and save it as argument ?
I am trying various tricks, but unsuccessfully, see both attached patch...
if someone has a idea or even a solution ! or thinks it's stupid
hmm, indeed i don't think that this is possible. the only way to create $args with [canvasargs] i've found until now, is to reuse-those retrieved via [canvasargs] itself.
that is, if you have an abstraction [foo $1] you can use something like the following to add a second argument "bar", while keeping the first one a $arg.
[bang( | [canvasargs] | [list $1 bar( | [canvasargs]
however, anything more complicated doesn't work.
now [canvasargs] behaves a little bit weird with $args anyhow. if the args are queried, and $arg is output as an unexpanded dollararg (A_DOLLAR, A_DOLLSYM), that's why it's printed as "$0-foo" rather than the usual "$0-foo", or an expanded "1046-foo". this weird types are what makes the above observation actually work (being able to set $args when taken from the output of [canvasargs]), but apart from that they lead to weirdo behaviour (e.g. [list fromsymbol] simply crashes).
so eventually, i could be talked into implementing support for setting (unescaped and escaped) and getting (unexpanded and expanded) $args for [canvasargs]. mainly i'll have to find a nice API to expose that functionality on the patch level.