You'd probably want to add copy and paste as well. On Aug 28, 2013 8:29 PM, "John Carlson" <[email protected]> wrote:
> 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
