Multiple cursors...like having one cursor at the beginning of a line and moving that cursor to the next line etc. Then if the doc was a flat file, have two cursors which are at columns 5 and 9 relative to the first cursor and row 0 relative to the first cursor--this defines a selection which can be copied. Then write a loop that processes every row, essentially moving the selection down the column of text. You could have multiple selected text regions in the document. On Aug 29, 2013 5:47 PM, "David Barbour" <[email protected]> wrote:
> [fwd to fonc] > > Use of tree zippers to model multi-media documents in the type system is > an interesting possibility. It seems obvious in hindsight, but I had been > focusing on other problem spaces. > > Hmm. I wonder if it might be intuitive to place the doc as an object on > the stack, then use the stack for the up/down (inclusion/extrusion) zipper > ops, allowing ops on sub-docs, as opposed to always keeping the full tree > as the top stack item. OTOH, either approach would be limited to one > cursor. > > What are you envisioning when you say "multiple cursors"? I can't think > how to do that without picking the doc apart and essentially modeling > hyperlinks (I.e. putting different divs on different named stacks so I can > have a different cursor in each div, then using a logical href to docs on > other stacks). This might or might not fit what you're imagining. > > (I can easily model full multi-stack environments as first-class types. > This might also be a favorable approach to representing docs.) > > Model transform by example sounds like something this design could be very > good for. Actually, I was imagining some of Bret Victor's drawing examples > (where it builds a procedure) would also be a good fit. > > My language has a name: Awelon. But thanks for offering the name of your > old project. :) > > > On Aug 29, 2013 2:11 PM, "John Carlson" <[email protected]> wrote: > >> I was suggesting MOOSE as a working name for your project. >> >> I used to keep a list of features for MOOSE that I wanted to develop. >> MOOSE (future) was the next step beyond TWB/TE (now) that never got >> funded. TWB was single threaded for the most part. I have done some work >> on creating multiple recorder desktop objects. MOOSE would have had a way >> to create new desktop objects as types, instead of creating them in C++. >> There would have been way to create aggregate desktop objects, either as >> lists or maps. I would have provided better navigation for Forms, which >> are essentially used for XML and EDI/X12. One thing I recall wanting to >> add was some kind of parser for desktop objects in addition to text file >> parsers and C++ persistent object parsers. >> >> RPN was only for the calculator. The other stack that we had was the >> undo stack for reversible debugging. >> >> I believe an extension to VIPR was to add object visualization to the >> pipeline. The reason I pointed you at VIPR is that the programmer model is >> similar to ours. >> >> I found that document was the best implementation I had of of tree >> zipper. You could focus the activity anywhere in the document. I tried to >> do form as a tree zipper, but limited movement made it difficult to use. I >> ruined a demo by focusing on the form too much. At one point, I could kind >> of drag the icon on the form to the document and produce a text document >> from the form (and vica versa). I think I also worked on dragging the >> recorder icon to the document. This would have converted the iconic >> representation to the C++ representation. >> >> All the MOOSE extensions after TWB/TE left production were rather >> experimental in nature. >> >> I suggest you might use a multimedia document as the visualization of >> your tree zipper. Then have multiple cursors which might rely on each >> other to manipulate the tree. >> >> Check out end-user programming and model transformation by demonstration >> for more recent ideas. >> On Aug 29, 2013 2:37 AM, "David Barbour" <[email protected]> wrote: >> >>> >>> On Wed, Aug 28, 2013 at 5:57 PM, John Carlson <[email protected]>wrote: >>> >>>> Multi-threaded Object-Oriented Stack Environment ... MOOSE for short. >>> >>> >>> Would you mind pointing me to some documentation? I found your document >>> on "A Visual Language for Data Mapping" but it doesn't discuss MOOSE. From >>> the intro thread, my best guess is that you added objects to and arrays to >>> your RPN language? But I'm not sure how the multi-threading is involved. >>> >>> >>>> Also check out VIPR from Wayne Citrin and friends at UC Boulder. Also >>>> check out AgentSheets, AgentCubes and XMLisp while you are at it. Not far >>>> from SimCity and friends. Also looking at videos from unreal kismet may be >>>> helpful if you haven't already seen them. >>> >>> >>> I've now checked these out. I am curious what led you to recommend >>> them. >>> >>> To clarify, my interest in visual programming is about finding a way to >>> unify HCI with programming and vice versa. To make the 'programmer-model' a >>> formal part of the 'program' is, I now believe, the most promising step in >>> that direction after live programming. As I described (but did not clarify) >>> this enables the IDE to be very thin, primarily a way of rendering a >>> program and extending it. The bulk of the logic of the IDE, potentially >>> even the menu systems, is shifted into the program itself. >>> >>> (While I am interested in game development, my mention of it was >>> intended more as a declaration of expressiveness than a purpose.) >>> >>> Croquet - with its pervasively hackable user environment - is much >>> closer to what I'm looking for than AgentCubes. But even Croquet still has >>> a strong separation between 'interacting with objects' and 'programming'. >>> >>> Other impressions: >>> >>> VIPR - Visual Imperative PRogramming - seems to be exploring visual >>> representations. I was confused that they did not address acquisition or >>> assignment of data - those would be the most important edges in data-flow >>> systems. But I guess VIPR is more a control-flow model than a data-flow. >>> One good point. made repeatedly in the VIPR papers is that we need to avoid >>> "edges" because they create complexity that is difficult to comprehend, >>> especially as we zoom away from the graph. >>> >>> I do like that Kismet is making reactive computation accessible and >>> useful to a couple million people. >>> >>> >>> >>>> >>>> I think you should replace stack with collection >>>> >>> >>> I could model a number of different collections, within the limit that >>> it be constructed of products (pairs) to fit the >>> arrowized<http://en.wikipedia.org/wiki/Arrow_(computer_science)>semantics. >>> So far I've modeled: >>> >>> * one stack (operate only near top - take, put, roll; no navigation) >>> * list zippers (navigational interface in one dimension: stepLeft, >>> stepRight) >>> * tree zipper (two-dimensional navigation in a tree; up, down, left, >>> right) >>> * list zipper of stacks (stepLeft, stepRight, take, put, roll) >>> * named stacks via metaprogramming (ad-hoc navigation: "foo" goto) >>> >>> The tree-zipper is the most expressive I can achieve without >>> metaprogramming. >>> >>> The more expressive collections, however, are not necessarily "good". >>> After building the tree zipper, I couldn't figure out how I wanted to use >>> it. Same for the list zipper, though the 'hand' concept serves a similar >>> role (take and put instead of stepLeft and stepRight). For a list of >>> anonymous stacks: I tend to stick around on one stack for a while, and >>> forget the relative positions of other stacks. That's why I eventually went >>> for named stacks. >>> >>> >>>> >>>> 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. [..] You'd probably want to add copy >>>> and paste as well. [..] Along with the recorder metaphor we added >>>> breakpoints which worked travelling in either direction in the code. >>> >>> >>> My language doesn't have runtime stacks, program counters, or iterators. >>> But I've mentioned viewing and animating parts of the compile-time history. >>> >>> >>>> >>> >>> I know you can make a recipe maker with a recipe, but who decides what >>>> a recipe makes? >>> >>> >>> Another recipe maker; you need to bootstrap. >>> >>> >>> >>> Can you make more than one type of thing at the same time? Can a human >>>> make more than one type of thing at the same time? Or a robot? >>> >>> >>> Living humans are always making more than one type of thing at a time. I >>> mean, unless you discount 'perspiration' and 'CO2' and 'heat' and 'sound' >>> and a bunch of other products I don't care to mention. I imagine the same >>> could be said for robots. ;) >>> >>> Humans can do a lot once it's shifted into their subconscious thoughts. >>> But their eye focus is about the size of a dime at arms length, and they >>> aren't very good at consciously focusing on more than one problem at a >>> time. Robots, however, are only limited by their mobility, sensors, >>> actuators, processors, programming, and resources. Okay... that's a lot of >>> limits. But if you had the funds and the time and the skills, you could >>> build a robot that can make more than one thing at a time. >>> >>> >>> _______________________________________________ >>> fonc mailing list >>> [email protected] >>> http://vpri.org/mailman/listinfo/fonc >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Augmented Programming" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to >> [email protected]. >> Visit this group at http://groups.google.com/group/augmented-programming. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
