Finally got a look at the Sublime editor. Looks cool! I suppose a few of
those tricks were using special keyboard macros, though... didn't really
'see' what was happening there. But I had an impression of "programming
macros by example", which would be really neat.
Lenses for common structures would be a fun library to write in my tacit
language anyway. I do have an advantage over Haskell, here, in that I'm
actually traversing a heterogeneous type (which may contain rationals and
text values) rather than a homogeneous tree data structure: affine
traversals are easier to enforce (if you operate on them, you must have
left some other type in their place).
One thing I'm curious about is whether the following set of (arrowized)
data plumbing operators is complete (i.e. no need for 'first'):
assocl :: (a * (b * c)) ~> ((a * b) * c)
swap :: (a * b) ~> (b * a)
intro1 :: a ~> (1 * a) -- 1 is unit
elim1 :: (1 * a) ~> a
rot3 :: (a * (b * (c * d))) ~> (c * (a * (b * d)))
I haven't figured out a good way to express the proof. But these have
worked for every pure data-plumbing function I've tried writing (or prodded
Prolog into writing for me). There are advantages of a block-free encoding
for the pure data plumbing... especially in a tacit language which needs to
first load the 'block' into the type.
I suppose a block-free encoding of a tree-zipper, traversals, and lenses
would be a pretty good proof. :)
Thanks for the advice, Michael.
On Thu, Aug 29, 2013 at 10:45 PM, Michael Sloan <[email protected]> wrote:
> Substructural type systems do seem to go hand in hand with the lens
> menagerie. Speaking quite informally about quite formal topics:
>
> * Affine types seem to have something to do with traversals, as it
> violates traversal laws to visit something multiple times. Of course, this
> is unchecked in its usage in Haskell.
>
> * Linear types seem to have something to do with isomorphisms. If you
> show that all inputs / output possibilities are handled (like GHC's pattern
> match checker), then unless a variable has only one or zero possible
> values, it must be used (relevant types). If it's only used once (linear),
> and the only functions used are isomorphisms, then you know the whole thing
> has to be an isomorphism.
>
> I'm doubting the "deepness" of this one, because you could certainly
> construct a valid isomorphism where values are not used in a linear
> fashion. Still, it's nice that there's a large set of things that are
> "straightforwardly" isomorphic.
>
> * Prisms are somewhere between what's called an affine traversal and an
> isomorphism. They're functions that can fail in one direction but not the
> other. If it's not failing in one direction, then running it in the other
> must yield the input. A good example of this is if you have a parser that
> preserves all syntax info - locations, comments, whitespace, etc. The
> parser could fail, but if it doesn't, then the printer ought to take you
> back to the exact input.
>
> Overall, lens seems like an excellent place to draw inspiration for a DSL
> that is in some ways very imperative (focused on mutation), while also
> playing nicely with the type system and providing nice abstractions for
> thinking about the properties of your code.
>
>
>
> On Thu, Aug 29, 2013 at 9:42 PM, David Barbour <[email protected]>wrote:
>
>> 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
>>
>>
>
> _______________________________________________
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
