Along with the recorder metaphor we added breakpoints which worked travelling in either direction in the code. On Aug 28, 2013 8:39 PM, "John Carlson" <[email protected]> wrote:
> 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
