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 > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
