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. 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
