Have you considered controlling stacks, program counters and iterators from the same basic metaphor? We used recorder buttons. Forward, Reverse, Stop, Fast Forward, and Fast Reverse. Then undo (delete previous operation) and delete next operation. On Aug 28, 2013 5:36 PM, "David Barbour" <[email protected]> wrote:
> I understand 'user modeling' [1] to broadly address long-term details > (e.g. user preferences and settings), mid-term details (goals, tasks, > workflow), and short-term details (focus, attention, clipboards and > cursors, conversational context, history). The unifying principle is that > we have more context to make smart decisions, to make systems behave in > ways their users expect. This is a form of context sensitivity, where the > user is explicitly part of the context. > > Programming can be understood as a form of user interface. But, > historically, user modeling (in this case 'programmer modeling') has been > kept carefully separate from the program itself; instead, it is instead > part of an Integrated Development Environment (IDE) > > *Hypothesis:* the separation of user-model from program has hindered both > programmers and the art of programming. There are several reasons for this: > > 1) Our IDEs are not sufficiently smart. The context IDEs keep is > heuristic, fragile, and can be trusted with only the simplest of tasks. > 2) Poor integration with the IDE and visual environments: it is difficult > to assign formal meaning to gestures and programmer actions. > 3) Programmer-layer goals, tasks, and workflows are generally opaque to > the IDE, the programs and the type system. > 4) Our code must be explicit and verbose about many interactions that > could be implicit if we tracked user context. > 5) Programmers cannot easily adjust their environment or language to know > what they mean, and act as they expect. > > I believe we can do much better. I'll next provide a little background > about how this belief came to be, then what I'm envisioning. > > *Background* > > Recently, I started developing a tacit representation for an arrowized > reactive programming model. Arrows provide a relatively rigid 'structure' > to the program. In the tacit representation, this structure was represented > as a stack consisting of a mix of compile-time values (text, numbers, > blocks) and runtime signals (e.g. mouse position). Essentially, I can give > the stack a 'static type', but I still used FORTH-like idioms to "roll" and > "pick" items from the stack as though it were a dynamic structure. With > just a little static introspection, I could even model `7 pick` as copying > the seventh element of the stack to the top of the stack. > > But I didn't like this single stack environment. It felt cramped. > > Often, I desire to decompose a problem into multiple concurrent tasks or > workflows. And when I do so, I must occasionally integrate intermediate > results, which can involve some complex scattering and gathering > operations. On a single stack, this integration is terribly painful: it > involves rolling or copying intermediate signals and values upwards or > downwards, with relative positions that are difficult to remember. > Conclusion: a single stack is good only for a single, sequential task - a > single pipeline, in a dataflow model. > > But then I realized: I'm not limited to modeling a stack. A stack is just > one possible way of organizing and conceptualizing the 'type' of the arrow. > I can model any environment I please! (I'm being serious. With the same > level of introspection needed for `7 pick`, I could model a MUD, MOO, or > interactive fiction in the type system.) After experimenting with tree > zippers [2] or a list of anonymous stacks [3], I'm kind of (hopefully) > settling on an easy-to-use environment [4] that consists of: > > * current stack > * hand > * current stack name > * list of named stacks > > The current stack serves the traditional role. The 'hand' enables > developers to 'take' and 'put' objects (and juggle a few of them, like > 'roll' except for the hand) - it's really convenient even for operating on > a single stack, and also helps carry items between stacks (implicit data > plumbing). The list of named stacks is achieved using compile-time > introspection (~type matching for different stack names) and is very > flexible: > > * different stacks for different tasks; ability to navigate to a different > stack (goto) > * programmers can 'load' and 'store' from a stack remotely (treat it like > a variable or register) > * programmers can use named stacks to record preferences and configuration > options > * programmers can use named stacks to store dynamic libraries of code (as > blocks) > > As I developed this rich environment, it occurred to me that I had > essentially integrated a user-model with the program itself. Actually, my > first thought was closer to "hey, I'm modeling a character in a game! Go go > Data Plumber!" The programmer is manipulating an avatar, navigating from > task to task and stack to stack. The programmer has items in hand, plus a > potential inventory (e.g. an "inventory" stack). To push metaphors a bit: I > can model keyrings full of sealer/unsealer pairs, locked rooms with sealed > values, unique 'artifacts' and 'puzzles' in the form of affine and relevant > types [5], quests goals in the form of fractional types (representing > futures/promises) [6], and 'spellbooks' in the form of static capabilities > [7]. But in retrospect, the relationship to user modeling seems obvious, > and I can put all this more boring terms of modeling goals, tasks, > requirements, workflows, user extensions and preferences, etc.. > > All the normal abstraction principles apply, and developers will quickly > build higher-level procedures for higher-level thinking, and build > libraries of reusable abstractions. An arrowized model also supports > 'partial application' (the `first` primitive) so we can precisely control > how much of this context is made available to a subprogram. > > In the type system, the current stack, hand, stack name, and list of named > stacks is represented as a simple anonymous product type: > > (cs * (h * (csn * lns))) > > Every non-trivial action the programmer performs will manipulate the > deeper 'type' of this environment. I.e. it's extremely heterogeneous, and > very mutable (albeit in a "pure functional" way, from an outside > perspective). The environment type is complicated and mutable; short term > I'll be okay, but long term I expect I'll need something to aide my memory. > Fortunately, the IDE can help. > > *Vision* > * > * > An IDE can *render* the types in the environment, dedicating more space > and detail to the types near me. Usefully, I can even animate progressions, > easily show the environment reaches a particular state - or basically a > replay of the programmer actions. With a few idioms (e.g. a "how-to-render" > stack, or integration primitives), developers could provide a great deal of > control over how things are rendered. > > IDE integration can also cover interaction. > > When users focus on a stack in the IDE, it corresponds to navigation code > being added to the program. When a user selects an object, the appropriate > code is injected to copy or take it. When a user opens a menu, the > available options correspond to macros that will be literally added to the > program. (Also, a menu might be extensible from within the program based on > the contents of an "ext-menu" stack.) Undo would be trivially integrated > and would have real meaning. > > It isn't a big step from here, to programming with a gamepad, or in an > AR/VR environment. (Nor are we a big step from building an interactive > fiction in the type system. :) > > An IDE could still help developers in the traditional ways: provide > context-sensitive suggestions based on the current 'type' of the > environment, provide 'cleaning' operations that reorganize the contents of > a stack and eliminate unnecessary copies, provide 'refactoring' support > that analyze block-constructor code for similarities, etc.. In addition, an > IDE could be rewriting the history, optimizing it - e.g. eliminating > unnecessary navigation or sequential `take put` operations. (This isn't > strictly necessary; pure data plumbing can be trivially optimized away at > compile-time. However a faster compile-time is also nice.) Rewrites could > also be the basis for building gesture macros. Of course, the model I > developed was meant primarily for signal manipulation - e.g. a signal might > be "mouse position". I think I'd mostly be operating at another layer of > indirection, for an IDE - where the 'signals' contain static building > blocks of code that will manipulate signals on my behalf. > > Use of a programmer model within the program is a powerful, uniform basis > for rich, extensible development environments that can eventually subsume > other UI models. Essentially, all user-interaction is subsumed as > programming, all GUIs are modeled as types, and with a decent type system > this can be powerful indeed. > > (Note: I suspect that multi-programmer environments are also feasible, > i.e. with multiple programmer models. However, I would tend to model > multiple programmers as each having their own environment within a larger > system, through which they can share some capabilities or libraries.) > > Best, > > Dave > > [1] http://en.wikipedia.org/wiki/User_modeling > [2] > http://awelonblue.wordpress.com/2013/08/12/tacit-programming-with-arrows-hands-and-zippers/ > > [3] > http://awelonblue.wordpress.com/2013/08/14/multi-stack-environment-in-awelon/ > [4] > http://awelonblue.wordpress.com/2013/08/26/multi-stack-environment-part-2/ > [5] http://en.wikipedia.org/wiki/Substructural_type_system > [6] > http://awelonblue.wordpress.com/2013/08/24/pipes-that-flow-in-both-directions/ > [7] http://en.wikipedia.org/wiki/Capability-based_security > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
