RiSE has released the paper on TouchStudio
it contains many interesting design decisions and fact about TouchStudio, it seems like TouchStudio is a quite futuristic environment:
Cloud behind the scene
In our vision, the state of the program is automatically distributed between mobile clients and the cloud, with automatic synchronization of data and execution between clients and cloud, liberating the programmer from worrying (or even having to know about) the
Dynamic-typing is not touch-friendly ?
TouchStudio uses a simple, imperative, statically typed programming language. We decided against using an existing, well-known programming language for three reasons. First, languages with similar scope tend to be dynamically typed which greatly complicates autocompletion features. Second, the lack of a precise explicit keyboard with around one hundred separate keys dramatically changes the trade-off s to be made when designing the concrete syntax. ...... we will base design decisions in TouchStudio on the ability to accurately select relevant program elements with an imprecise fi nger tapping gesture on a touchscreen. Third, we wanted to approach the question how program state should be managed by the runtime system with a fresh mind which addresses the challenges of the mobile execution environment of a cloud-connected device.
We decided on a statically typed language, since type information is necessary to provide highly useful context-sensitive code completion options to the user.
Async/Await implicitly ?
TouchStudio uses cooperative multi-threading. Normally, actions are executed single-threaded, however calls that block (e.g., fetching data from the web or waiting for user input) allow other actions to run. The blocking calls are marked visually in the TouchStudio editor, to make the user aware that global data can change at this point. Moreover, there are some properties the user might want to invoke which require the application to suspend, and later resume, e.g. when the user wants to take a picture via the camera application. These are also marked visually.
distributed Concurrent Revisions built-in
In the future, TouchStudio will support global state, where conceptually all global variables live in the cloud. An application can run on multiple devices in a common application domain; in this case, all application instances operate on the same global variables, and they can observe each other's state changes. The state evaluation is realized via Concurrent Revisions : a mobile device forks from the global state when its connection to the cloud is interrupted, and its updates are merged back into the global state when the connection is restored. To save battery power, these events can be further postponed and bundled.
According to the semantics of Concurrent Revisions, merging of data is per-formed by a resolution strategy for competing updates from di erent devices; the basic resolution strategy is "the last update wins", but this can be re fined by further annotations from the user, e.g. the user can indicate that an integer global variable is a "counter", in which case changes are additive.
An application domain in the cloud is associated with its creator; if the creator permits, then direct friends of the creator in a social network are allowed
We introduce a sequence type, a special expression to refer to the current element, and an apply statement, which takes a sequence and a number of transformers. The editor treats the transformers in the query like statements, using a similar user interface.
Operations like average, sum, median, minimum, maximum, count, all, and any are available as properties on the sequence type. We might allow their usage as the last transformer.
Type Providers? http://strangelights.com/blog/archive/2010/11/15/the-future-of-f-type-providers.aspx
while there is no language-intrinsic mechanism to de fine custom types, externally realized and possibly user-configurable data sources and state can extend the universe of available types.
At the statement level, the language editor is structured. At the expression level, the editor is unstructured. However, at the token level, the editor is structured again. In other words: You cannot make syntax errors at the statement level, but you can at the expression level; however, individual identi er names are treated as atoms, and they cannot be misspelled.
unique Touch UI design
We currently use the two-tap-selection model: the fi rst tap zooms the view, the second tap selects. We have experimented with a few other models and decided against them:
These models were unsatisfactory, mostly because taps are much faster and easier to execute than pinch or drag gestures, or waiting through long hold periods. Selecting statements is the core part of TouchStudio experience and therefore needs to be very fast and precise.
auto-tombstoning, potentially resuming acrossing devices ?
An important feature of the interpreter is that its state (and thus by extension the state of the user's program) is serializable in between any two byte-code instructions, and during those built-in instructions which require tombstoning.
By making its state serializable, the TouchStudio interpreter can continue execution seamlessly after tombstoning. In our experience, properly handling tombstoning is a tedious and error-prone duty when developing Windows Phone applications in the traditional way. Within the capabilities of TouchStudio scripts, all of this is handled automatically by the interpreter.