Thanks for the refs. I hadn't heard of multi-focus zippers. I'll give modeling those a try soon. Even if just for curiosity. I've used traversals but I could certainly use a refresher there.
Lenses might also be worth modeling, if I can do so within the limits of not knowing which types might be linear. Probably not a problem. :) On Aug 29, 2013 8:58 PM, "Michael Sloan" <[email protected]> wrote: > My current preferred text editor nicely supports multiple cursors: > https://www.youtube.com/watch?v=E9QYlmvRVRQ > > It's extremely convenient because it's like having some of the power of > macros without the necessity of premeditation. In a sense, it's the > speculative / live version of macros. Now, sublime's implementation of > this isn't perfect, but it's functional enough to obviate macros for my > text editing needs. My ideal multiple cursors implementation would also > attempt to make all cursors visible by omitting intermediary lines when > necessary. Of course, this won't manage all cases - but it would be very > cool to be able to edit a bunch of files at once, seeing all of the > affected code. > > Of course, it's also possible with emacs: > https://github.com/emacsmirror/multiple-cursors > > > As for tree zippers and multiple selections, it turns out that higher > order (higher derivative) zippers introduce multiple focuses: > http://blog.poucet.org/2007/07/higher-order-zippers/ > > I tried to build a minimal text editor on this idea, and it got very > clumsy, so I'm not really recommending this approach beyond it being a > curiosity. A single zipper was of course beautiful for text editing, but > when you got into the real world of having selections and such things got > pretty hairy. > > Have you seen the lens library's zippers? Not only does it provide > generic zippers as a library, but it also provides for something like > having many "focuses" by being able to move along a "level" within the > tree. Whereas lenses can refer to one component and be used to modify it, > traversals refer to multiple targets and allow you to modify them. Levels > come from descending into the tree using different traversals > > > http://hackage.haskell.org/packages/archive/lens/latest/doc/html/Control-Lens-Zipper.html > > The main property of these levels, a result of the traversal laws, is that > the different focuses cannot contain eachother. Otherwise, there would be > no reasonable way to mutate them concurrently. Seems very related to your > "stack of stacks" ideas. > > > On Thu, Aug 29, 2013 at 8:36 PM, David Barbour <[email protected]>wrote: > >> Thanks for clarifying. I can think of a few ways to model such cursors, >> but I think this use-case would generally not fit Awelon's model. >> >> * if we have 'reactive' text, we'll generally be limited to atomic text >> signals (the small time-varying chunks of text) and whatever >> post-processing we choose to perform. >> * with static text, we have a similar features for reactive text... but >> due to stability across updates (e.g. if we later have a multi-language >> app, the text would change; how should the selection and copy change?) So >> in general, we'd be operating on atomic chunks of static text. >> * I can, of course, create stateful copies of the text-as-it-is. But this >> would essentially be external to Awelon's type system. >> >> > Given your concern with stability / consistency / commutativity, CRDTs and > their ilk might be interesting: > http://hal.upmc.fr/docs/00/55/55/88/PDF/techreport.pdf > > They have nice properties for collaborative editing, and could help make > it efficient to know what derived information needs to be recomputed. > > -Michael > > >> >> >> On Thu, Aug 29, 2013 at 7:10 PM, John Carlson <[email protected]> wrote: >> >>> 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 >>> >>> >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> >> > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
