Hi! While working on a custom datatype test, I ran into a slight problem (that I fixed but would still like to report) with the metaprogramming commands and ring input names. For those who don't know what I'm talking about, here's some context:
In my test (built off of @pajamaclaws21's), there is a custom block that registers a new type with conversion processes and methods. In order for those inputs to actually apply themselves to values of the created type, any slot where the value is needed is filled with (#1)from the ring that holds the "formula." This works because the conversion (and method) reporters that are created from the type registration have inputs that are not named by the script. Sooooo, the reporter definitions have the format of (TYPENAME [#1] to TARGETTYPE) :: define+because the inputs have the same default names as the rings. For reference, here's a full example:
. . . conversions: (parent type [number v] via (((item (2 v) of (#1)) / (item (3 v) of (#1))) input names: ((#1)) @delInput@addInput ::ring)::operators) :: operators // creates a conversion reporter that reports the ringed script. . . . (fraction [#1] to number) :: define+ // this is the definition of the conversion reporter report ((item (2 v) of (#1)) / (item (3 v) of (#1)))
Considering the appearance of the script, it should work, right? NO, it does not! When you call the reporter, it says that there is no variable named #1 in the context of the definition, but that's not true. If you manually enter the block definition and click "Apply" (without editing anything), it works. I believe the issue is that the definition is reading the variables as different because of how they were declared.
Since the conversion reporters are supposed to work without any manual interference, I had to find another solution. What fixed the issue was changing the "define" command that created conversion to have a ringed definition with an input name of #1. In my case, I could not simply add an input name since the input was not a ring (it was a variable containing a ring). Thus, I had to split the ring by blocks and re-join it with a #1 text string.
I don't think this is intentional, so if it isn't, what is happening??
If you would like to see it for yourself, you can view @pajamaclaws21's test, which still has this problem. Just create a type with a conversion and try calling the conversion reporter.
