Getting Squeak to write Squeak (a feeble effort at LISPY stuff)

Alan Kay Alan.Kay at squeakland.org
Mon Nov 17 15:34:44 UTC 2003


Hi Michael --

Since the original Smalltalk was in part inspired by LISP and because 
ST, like LISP, does its conversion on the fly from input strings to 
runnable objects and code, this is obviously doable. Look a little 
more at how a method is compiled from its editable string and bound 
into a context ...

Cheers,

Alan

At 6:16 AM -0800 11/17/03, Michael Grant wrote:
>Hope this is readable--I've got to get my edit window preferences 
>straightened up :-)
>
>Ned Konz <ned at bike-nomad.com> wrote:
>
>On Sunday 16 November 2003 8:25 pm, mwgrant2001 wrote:
>
>Ned: I don't understand why you need to do assignments.
>
>mwg: The quick answer is because it suits the way I think about the 
>problem.  I did this a number of years ago as a text-based app. in 
>LISP and so it makes a nice substantive exercise in Squeak. The keys 
>to the (OO) LISP implementation were 1.) symbolic computation--in 
>particular the ability of have objects create objects-- 2.) 
>recursion, 3) and of it was object-oriented. Indeed the ease of the 
>task was in part because I was able to think of the nodes as little 
>agents which could determine from the context of their own 
>creation where they belonged and what they had to do--when to create 
>more nodes and when evaluate themselves and disappear into the 
>garbage collector.
>
>In more detail: The goal is to generate a decision tree (ala SRI 
>approach), or rather have a decision tree generate and evaluate 
>itself where only 'blueprints' of the uncertainty and decision nodes 
>are input by the user via the on-the-fly construction of the 
>influence diagram. Once the IF is specificied a base node--typically 
>decision--is created and told to 'bloom'. By 'bloom'ing it then 
>creates creates a node--typically an uncertainty--for each of it 
>branch.
>
>Each of these nodes will then in turn 'bloom' and so on until 
>terminal nodes are reached. Here bloom cause the node to return a 
>probability weighted value to that node which created it. When a 
>node has values returned from each of the nodes it created, then it 
>takes those values and uses them to calculate a weighted value which 
>is returned to its creator, and so on.
>
>So the tree, specified by the user on-the-fly, is generated and evaluated.
>
>ned:
>Can't you just do something like:
>
>myMorph _ Node named: answer asSymbol.
>
>where the #named: message is setting state in the Node?
>
>mwg: I don't know. That is why I asked for help in the first place. 
>I appreciate the tip. One possible problem  here is I don't know 
>beforehand how many Morphs will be created and how many need to 
>exist concurrently. So anything static like myMorph is not 
>workable.  I am  looking for the ST equivalent of LISP's GENSYMing a 
>string into an interned symbol in a dynamic context. (I believe this 
>is the appropriate description--it's been years!!!).
>
>BTW ultimately nodes would not be subclasses of a Morphic class, but 
>each node instance would have one or more morphs as a variables. I 
>just simplified things here.
>
>ned:
>
>More generally, look at the bigger picture: as you create these things,
>something's got to hold onto them or they won't continue to exist.
>
>mwg: I expected scope could be part of the issue. I looked at some 
>of other #evaluate's  in th eimage but no examples or 
>guidance...that was the determining factor for my the original email.
>
>Ned:
>So the assignment of
>c := TextMorph new
>
>just doesn't make any sense here.
>
>mwg:
>
>It obviously didn't make sense to Squeak either :o).
>
>But the need to do what I tried to do is critical to the present 
>approach. So maybe the approach gets modified--but first I want to 
>duplicate as much as possible. One of the reasons I started 
>THIS EXERCISE is to see how much extra effort it is to do symbolic 
>calculation in ST. I suspected and still suspect thatit is easier to 
>do in LISP, but that isn't an issue. I'm PLAYING with ST.
>
>Ned:
>Going a bit further, if you look at the various flavors of #evaluate: you will
>find some where you can specify a context in which to do the evaluation. For
>instance, Workspaces hold variable bindings, and will provide them when and
>if the Compiler needs them (see #bindingOf:).
>
>mwg:
>
>In truth I did. I thought scope was important and was not real 
>surprised when the code didn't work. Obviously things like 
>'#evaluate in:' showed up in the method finder, but no example and 
>hence I could only that execution of 'Compiler evaluate' might take 
>note of the 'scope' and act according. This is where even an example 
>in the image would have been very helpful, but I can't be suprised 
>there wasn't one. After all who would be looking at #evaluates 
>unless the knew what they were doing, huh?
>
>Thanks for you comments, Ned...they do give me some things to try.
>
>Best Regards,
>
>Mike
>
>
>
>
>Do you Yahoo!?
><http://antispam.yahoo.com/whatsnewfree>Protect your identity with 
>Yahoo! Mail AddressGuard


-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20031117/c99308f1/attachment.htm


More information about the Squeak-dev mailing list