Hi Dr Kay, thank you for the pointer to Newman's work I was not aware of.
Regarding the state machine, Engelbart already pointed out that it was not a good model for user control language in [1]. "In the first attempt, the control language was described as a finite state machine, and the language allowed a formal textual definition of such a machine. [...] It was originally thought that such an approach was adequate for the definition of user-system control languages. But, to paraphrase John McCarthy, the model is metaphysically adequate, but epistemologically inadequate. Implementation revealed that the dialogue is a non-Markovian (nonstochastic, historically dependent) process on the part of both the machine and the user, and accurate characterization as a finite state machine results in so many states that the model is useless. A better model is a two-stack automaton with a small number of immediate-access storage registers." I didn't encounter a lot of systems like NLS/AUGMENT during my time at a french engineer school. I guess the situation is similar to US universities. I'm trying now to catch up and was wondering if there are other software systems built using the same principles and techniques (collection of domain specific languages). I, of course, know already about Franck and the STEPS project. Thank you again for the pointers. - Benoit [1] Development of a multidisplay, time-shared computer facility and computer-augmented management-system research (Final Report), http://bitsavers.org/pdf/sri/arc/Development_of_a_Multidisplay_Time-Shared_Computer_Facility_Apr68.pdf On Sat, Jul 23, 2011 at 11:39 PM, Alan Kay <[email protected]> wrote: > The idea of using a grammar to create a user interface goes back at least as > far as Engelbart's AHI group. They used a distant past cousin of OMeta > (called Tree Meta) to do this. Ca. 1966. > > One of the first systems to specify and make graphical grammars (and UIs) > via user interactions was William Newman's "The Reaction Handler" PhD thesis > about the same time. (William is the Newman of "Newman and Sproull"). > > It's worthwhile to contemplate that a state machine (recursive or not) is > the opposite of "modeless" -- it is the epitome of modes. So this is not a > great way to specify a really nice modeless interface (because you have to > draw arrows outward from pretty much every state to pretty much every other > state). "Modeless" at PARC meant "you don't have to explicitly back out of > your current 'mode' to initiate any other command". > > Cheers, > > Alan > > ________________________________ > From: Benoît Fleury <[email protected]> > To: Fundamentals of New Computing <[email protected]> > Sent: Sat, July 23, 2011 11:05:49 PM > Subject: [fonc] HotDraw's Tool State Machine Editor > > Hi, > > I found HotDraw's tool state machine editor [1] very interesting as a > graphical editor for a "syntax-directed translator". The state machine > transforms a stream of mouse events into a stream of commands on the > structured drawing. Did I push the analogy too far? > > I was wondering if anyone knows similar examples of graphical editor > for grammars? > > Moreover, we didn't find (yet) a good metaphor for writing programs in > general purpose programming language in a graphical editor. Do you > think that might change with "domain specific languages"? > > Thank you to everyone on this list for the very interesting > discussions and links. > > - Benoit > > [1] http://st-www.cs.illinois.edu/users/brant/HotDraw/Conversion.html> > > _______________________________________________ > 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
