-
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
Braces revisited #78
Comments
I am now writing a submission for the Spash - Onward conference. |
All these sophisticated brace variations may look distracting, and that is not necessarily a bad thing. |
BTW |
Technically, the result of {dataStore ? req} is Future[Any]. So we'll need some wrapper around the script result values logic, so that this wrapper converts the Future into a Script node (or any other node) "on the fly". |
I think the wrapper would be an implicit script, just like the ones for buttons and characters in the LookupFrame example. The braces just enclose a value item, rather than an atomic action; this would require a minor change in the parser. |
Some more thinking. In the current situation, when parsing script expressions: In Scala code We need also some way to denote value expressions in Scripts.
The parser should see the first part as a tuple, to which an implicit conversion would apply, but the parser should anyway also expect a parenthesized behaviour expression. So the parentheses symbols are too heavy overloaded. Let's stop that. As soon as we will reach a stable state we could change this in the new compiler. |
I don't think we should replace Parser can differentiate between |
Smalltalk and Objective-C use |
Do they use them for scoping? We can experiment, of course, but this would be yet another bit of knowledge for the users to learn. Many will find themselves frustrated when things won't work the intuitive way. |
Use case: the example Twitter search controller.
New version:
Changes:
|
Another use case: several lines from LookupFrame2. Old version:
New version:
Atomic actions are now marked with exclamation marks, as in |
At LambdaConf in Boulder I presented this example:
The problem is that this does not work; e.g. So IMO it seems more logical to reserve
|
And there is the example that I posted in this thread a few weeks ago:
Specifying a tuple there would require this new proposed use of the parentheses. |
From the file downloader example:
This code has been modified a little from the version in the repository; IMO this should be parseable.
Here two |
From LifeFrame:
New:
Intermezzo: in the latter line there is a nice conversion of the computed integer to a character; only possibly by the new meaning of the parentheses. Another pecularity: nested calls with ":" parameters.
Intermezzo 2: It would be possible to write this without the brackets, using the prefix notation for the plus:
This assumes mouseSingleClick, singleClick etc have a java.awt.Point as result.
Note that mouse_Move etc return a MouseEvent. It seems that section 2.9 of the ArXiv'd paper "Some New Directions for ACP Research" is flawed. A better informal meaning of |
In my enthusiasm I forgot that the form
was created this way because of its efficiency: it installs a mouse listener one time only, which repeatedly invokes the call back function. The efficiency is about the same as plain Scala code. Let's make a dataflow based alternative that is more efficient than the one above. Suppose
The left hand side of the data flow arrow is more efficient than the right hand side, since it does not need to be reactivated each time any more. Could we do the same for the RHS? In fact we only want to map the result value of type
However, something similar to the current dataflow operators would be preferable. E.g.,
would map the result value of termp as
or simply some code using the
All this may be implemented efficiently using a wapper for the term:
The RHS would be a Script that overrides $result to mapFunction(r.$result) I am not happy with the syntax yet. OTOH such a map capability would give much of the power of Parboiled2. |
The last few lines of the previous post are incorrect. ScriptWrapper should be a class that extends Script; internally it holds another script (i.e. a script expression; not necessary a script call). Now whenever that wrapped script attempts to set a result value at a higher level, this passes through the mapFunction. |
The new syntax has been implemented and works correctly, except the stream dataflow operator. There are many ways to organize the lhs and rhs lifecycle: each can be activated only once or can be reactivated for every piece of data being sent. While for the lhs it makes sense to activate it only once, rhs must be activated for every new piece of data if we want to support arbitrary script expressions as an rhs. If we assume rhs to always be a scala code expression, it can also be activated only once and then reused. There are also several ways to organize the execution procedure for the stream dataflow either.
Since there are so many strategies for implementing the stream dataflow, I'll wait until you can express your opinion on which one is optimal. Meanwhile, I'll look at the task of the new website and SubScript JS. |
It is indeed wise to proceed now with the web site and the JS version. FTTB I do not want to follow any of your 3 implementation strategies for this operator. In the paper “Some new directions for ACP research” I have described in a few words how the stream dataflow operator would work. The definition would require a "mandatory interruptions” operator: x %/%/ y Some rules: Upon activation this activates x It is a bit more complicated than this, because the operator is n-ary. This operator, like a few others that start with ‘%’, require a suspend-resume mechanism. I think I can work on this when I am back home. |
Currently there are several types of brace pairs that separate the process part in scripts from Scala code. Normal braces for normal atomic actions, and braces with immediately next to them one of these symbols:
* ? ! . ...
.I wanted to make it more difficult to specify normal atomic actions, for these are rather CPU expensive, so I thought these should be specified using
{! ... !}
. These are now in use for tiny code fragments, and I thought those could use the plain braces instead.Anyway, braces for tiny code fragments should also become less needed: method calls as tiny code may also use the plain script call syntax, and assignments could use the
let
construct (work in progress).BTW currently a method-with-script-call-syntax yields a normal atomic action; this should become a tiny code fragment.
But now I think tiny code fragments should be within
{: ... :}
; every kind of code fragment would then have - no kind would be the default. The main reason for this proposal is that braces would have a use to mark Scala statements (resulting in a value) that would get an implicit conversion.A use case is the data store proxy sample application. Its
live
script would be:{dataStore ? req}
etc. yield futures, which require implicit conversions to scripts.BTW I had in mind to write a different kind of brace pair:
{=dataStore ? req=}
but this does not really appeal to me.The text was updated successfully, but these errors were encountered: