Display of an identifier's binding should be inverse of read operation
When an engine environment is queried (with an identifier), the engine returns information about the binding (if any) to that identifier.
One of the attributes returned is the value to which the identifier is bound. The value, an RPL pattern, is given in human readable form using the parse.reveal
functions.
First, there are some bugs in parse.reveal
, which reconstructs the RPL by walking the parse tree that generated the pattern. Since this output was meant for humans only, and is not validated in any way, errors like this can occur: (note the parens where there should be braces {})
Rosie> foo = [:digit:]+
Rosie> foo
assignment foo = ([[:digit:]])+
Rosie>
Second, it is very valuable to have a function that is the inverse of read
. The read
operation accepts RPL input and generates an AST. This is currently an internal operation -- it is part of the load
capability of an engine, which reads RPL input and parses it, then compiles it.
The (new in v1-tranche-1) lookup
function of engines produces the output shown in the repl snippet above by calling parse.reveal
. As shown, not only is the output is sometimes incorrect, but it's not even valid RPL. (E.g. the word "assignment" in the output shown above.)
The parse.reveal
functions should return valid RPL which, if parsed, should generate an equivalent AST. (It may not be an identical AST because the original AST contains meta-data about the original RPL that generated it, and this meta-data is going to be different in the reconstruction.)
To sum up: The "binding" output of lookup
(which also returns the assigned color, etc.) should be valid RPL that could be loaded into another Rosie to produce an equivalent pattern (assuming dependencies are loaded into that other Rosie, of course).