-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
^ Result Catchers #36
Comments
so
Exception: if the name |
Some form of the result catchers is working now. A better word is: result propagator. The "^" suffix is an explicit marker. Note; children of the arrow operators ~~> etc are lambda's, and therefore regarded as scripts in this context. This was not too hard to implement. Parboiled has transforming markers such as "captureAll"; that one creates a sequence of captured elements. Maybe we can do something similar. The marker symbol may be followed immediately by such a transformer. This will require experimentation. |
^
Result CatchersScript calls and code fragments may be followed by result catchers: a caret(
^
) optionally followed by a simple variable designatorThere is no spacing allowed, to prevent ambiguity of the optional designator with a script call.
If such a variable is not specified explicitly after the caret, the script result value
$result
is assumed.An alternative would be to catch the result-exception value in a
Try[]
; FTTB we stick to the result.A variable name that starts with
$
(except for$
,$result
and$failure
) is implicitly declared as local variable in the script, with an appropriate type:the most specific common supertype of all the result types of the calls and code fragments that the variable appears next to as result catcher.
If a script body consists of just a code fragment or a script call without a result catcher, an implicit one is assumed for the script result value. (Maybe widen this condition to activation code containing a code fragment or calls)
If the calling script has no explicit result type declared, then the result type becomes the most specific common supertype of its script calls and code fragments that have result catchers for $result.
In this respect the script calls and code fragments body of a script lambda are normally supposed to belong to that lambda, rather than to the enclosing script.
Note that the operands of the data flow operator are lambdas. It makes sense that in
a ~~> b
the result value from a goes to b. However, the entire dataflow construct should be seen as a lambda in itself; its result value will be fed by the RHS (b). This is something still to be worked out.Probably
a ~~> b^
should be interpreted as(a ~~> (b^))^
,and
a ~~> b ~/~> c ^
as(a ~~> (b^) ~/~> (c^))^
.a ~~> b^ ~/~> c
would not be illegal, but it would make no sense.The caret may be implemented in two ways: as a separate node or as a optional parameter to the DSL methods _call, _normal etc.
This parameter would then have type
Given an actual result catcher
^$
of type R the parameter would be something like:The symbol part is for debugging: the node from which the result value is grabbed gets in the graphical debugger an extra label with actual value information, such as
^$=10
.The text was updated successfully, but these errors were encountered: