The theory Algebra of Communicating Processes (ACP) offers non-determinism (as in Meta II) plus concurrency. I will present a paper on extending Scala with ACP next month at Scala Days 2012. For an abstract, see http://days2012.scala-lang.org/node/92
A non-final version of the paper is at http://code.google.com/p/subscript/downloads/detail?name=SubScript-TR2012.pdf André Op 15 mrt. 2012, om 03:03 heeft Alan Kay het volgende geschreven: > Well, it was very much a "mythical beast" even on paper -- and you really > have to implement programming languages and make a lot of things with them to > be able to assess them .... > > But -- basically -- since meeting Seymour and starting to think about > children and programming, there were eight systems that I thought were really > nifty and cried out to be unified somehow: > 1. Joss > 2. Lisp > 3. Logo -- which was originally a unification of Joss and Lisp, but I > thought more could be done in this direction). > 4. Planner -- a big set of ideas (long before Prolog) by Carl Hewitt for > logic programming and "pattern directed inference" both forward and backwards > with backtracking) > 5. Meta II -- a super simple meta parser and compiler done by Val Schorre > at UCLA ca 1963 > 6. IMP -- perhaps the first real extensible language that worked well -- by > Ned Irons (CACM, Jan 1970) > 7. The Lisp-70 Pattern Matching System -- by Larry Tesler, et al, with some > design ideas by me > 8. The object and pattern directed extension stuff I'd been doing > previously with the Flex Machine and afterwards at SAIL (that also was > influenced by Meta II) > > One of the schemes was to really make the pattern matching parts of this > "work for everything" that eventually required "invocations and binding". > This was doable semantically but was a bear syntactically because of the > different senses of what kinds of matching and binding were intended for > different problems. This messed up the readability and desired "simple things > should be simple". > > Examples I wanted to cover included simple translations of languages (English > to Pig Latin, English to French, etc. some of these had been done in Logo), > the Winograd robot block stacking and other examples done with Planner, the > making of the language the child was using, message sending and receiving, > extensions to Smalltalk-71, and so forth. > > I think today the way to try to do this would be with a much more graphical > UI than with text -- one could imagine tiles that would specify what to > match, and the details of the match could be submerged a bit. > > More recently, both OMeta and several of Ian's matchers can handle multiple > kinds of matching with binding and do backtracking, etc., so one could > imagine a more general language that could be based on this. > > On the other hand, trying to stuff 8 kinds of language ideas into one new > language in a graceful way could be a siren's song of a goal. > > Still .... > > Cheers, > > Alan > > From: shaun gilchrist <shaunxc...@gmail.com> > To: fonc@vpri.org > Sent: Wednesday, March 14, 2012 11:38 AM > Subject: Re: [fonc] [IAEP] Barbarians at the gate! (Project Nell) > > Alan, > > "I would go way back to the never implemented Smalltalk-71" > > Is there a formal specification of what 71 should have been? I have only ever > read about it in passing reference in the various histories of smalltalk as a > step on the way to 72, 76, and finally 80. > > I am very intrigued as to what sets 71 apart so dramatically. -Shaun > > On Wed, Mar 14, 2012 at 12:29 PM, Alan Kay <alan.n...@yahoo.com> wrote: > Hi Scott -- > > 1. I will see if I can get one of these scanned for you. Moore tended to > publish in journals and there is very little of his stuff available on line. > > 2.a. "if (a<b) { ... }" is easier to read than "if a<b then ..."? There is no > hint of the former being tweaked for decades to make it easier to read. > > Several experiments from the past cast doubt on the rest of the idea. At > Disney we did a variety of "code display" generators to see what kinds of > transformations we could do to the underlying Smalltalk (including syntactic) > to make it something that could be subsetted as a "growable path from Etoys". > > We got some good results from this (and this is what I'd do with Javascript > in both directions -- Alex Warth's OMeta is in Javascript and is quite > complete and could do this). > > However, the showstopper was all the parentheses that had to be rendered in > tiles. Mike Travers at MIT had done one of the first tile based editors for a > version of Lisp that he used, and this was even worse. > > More recently, Jens Moenig (who did SNAP) also did a direct renderer and > editor for Squeak Smalltalk (this can be tried out) and it really seemed to > be much too cluttered. > > One argument for some of this, is "well, teach the kids a subset that doesn't > use so many parens ...". This could be a solution. > > However, in the end, I don't think Javascript semantics is particularly good > for kids. For example, one of features of Etoys that turned out to be very > powerful for children and other Etoy programmers is the easy/trivial parallel > methods execution. And there are others in Etoys and yet others in Scractch > that are non-standard in regular programming languages but are very powerful > for children (and some of them are better than standard CS language ideas). > > I'm encouraging you to do something better (that would be ideal). Or at least > as workable. Giving kids less just because that's what an existing language > for adults has is not a good tactic. > > 2.c. Ditto 2.a. above > > 2.d. Ditto above above > > Cheers, > > Alan > > > > From: C. Scott Ananian <csc...@laptop.org> > To: Alan Kay <alan.n...@yahoo.com> > Cc: IAEP SugarLabs <i...@lists.sugarlabs.org>; Fundamentals of New Computing > <fonc@vpri.org>; Viewpoints Research <a...@vpri.org> > Sent: Wednesday, March 14, 2012 10:25 AM > Subject: Re: [IAEP] [fonc] Barbarians at the gate! (Project Nell) > > On Wed, Mar 14, 2012 at 12:54 PM, Alan Kay <alan.n...@yahoo.com> wrote: > The many papers from this work greatly influenced the thinking about personal > computing at Xerox PARC in the 70s. Here are a couple: > > -- O. K. Moore, Autotelic Responsive Environments and Exceptional Children, > Experience, Structure and Adaptabilty (ed. Harvey), Springer, 1966 > -- Anderson and Moore, Autotelic Folk Models, Sociological Quarterly, 1959 > > Thank you for these references. I will chase them down and learn as much as > I can. > > 2. Separating out some of the programming ideas here: > > a. Simplest one is that the most important users of this system are the > children, so it would be a better idea to make the tile scripting look as > easy for them as possible. I don't agree with the rationalization in the > paper about "preserving the code reading skills of existing programmers". > > I probably need to clarify the reasoning in the paper for this point. > > "Traditional" text-based programming languages have been tweaked over decades > to be easy to read -- for both small examples and large systems. It's > somewhat of a heresy, but I thought it would be interesting to explore a > tile-based system that *didn't* throw away the traditional text structure, > and tried simply to make the structure of the traditional text easier to > visualize and manipulate. > > So it's not really "skills of existing programmers" I'm interested in -- I > should reword that. It's that I feel we have an existence proof that the > traditional textual form of a program is easy to read, even for very > complicated programs. So I'm trying to scale down the thing that works, > instead of trying to invent something new which proves unwieldy at scale. > > b. Good idea to go all the way to the bottom with the children's language. > > c. Figure 2 introduces another -- at least equally important language -- in > my opinion, this one should be made kid usable and programmable -- and I > would try to see how it could fit with the TS language in some way. > > This language is JSON, which is just the object-definition subset of > JavaScript. So it can in fact be expressed with TurtleScript tiles. > (Although I haven't yet tackled quasiquote in TurtleScript.) > > d. There is another language -- AIML -- introduced for recognizing things. I > would use something much nicer, easier, more readable, etc., -- like OMeta -- > or more likely I would go way back to the never implemented Smalltalk-71 > (which had these and some of the above features in its design and also tried > to be kid usable) -- and try to make a version that worked (maybe too hard to > do in general or for the scope of this project, but you can see why it would > be nice to have all of the mechanisms that make your system work be couched > in kid terms and looks and feels if possible). > > This I completely agree with. The AIML will be translated to JSON on the > device itself. The use of AIML is a compromise: it exists and has > well-defined semantics and does 90% of what I'd like it to do. It also has > an active community who have spend a lot of time building reasonable dialog > rules in AIML. At some point it will have to be extended or replaced, but I > think it will get me through version 1.0 at least. > > I'll probably translate the AIML example to JSON in the next revision of the > paper, and state the relationship of JSON to JavaScript and TurtleScript more > precisely. > > 3. It's out of the scope of your paper and these comments to discuss "getting > kids to add other structures besides stories and narrative to think with". > You have to start with stories, and that is enough for now. A larger scale > plan (you may already have) would involve a kind of weaning process to get > kids to add non-story thinking (as is done in math and science, etc.) to > their skills. This is a whole curriculum of its own. > > I make these comments because I think your project is a good idea, on the > right track, and needs to be done > > Thank you. I'll keep your encouragement in mind during the hard work of > implementation. > --scott > > -- > ( http://cscott.net ) > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
