<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: Getting Squeak to write Squeak (a feeble effort
at</title></head><body>
<div>Hi Michael --</div>
<div><br></div>
<div>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 ...</div>
<div><br></div>
<div>Cheers,</div>
<div><br></div>
<div>Alan</div>
<div><br></div>
<div>At 6:16 AM -0800 11/17/03, Michael Grant wrote:</div>
<blockquote type="cite" cite>Hope this is readable--I've got to get my
edit window preferences straightened up :-)</blockquote>
<blockquote type="cite" cite><br>
<i><b>Ned Konz <ned@bike-nomad.com></b></i> wrote:<br>
<blockquote>On Sunday 16 November 2003 8:25 pm, mwgrant2001 wrote:<br>
<br>
Ned: I don't understand why you need to do assignments.<br>
</blockquote>
<blockquote>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.<br>
</blockquote>
<blockquote>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.<br>
</blockquote>
<blockquote>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.<br>
</blockquote>
<blockquote>So the tree, specified by the user
on-the-fly, is generated and evaluated.<br>
</blockquote>
<blockquote>ned:<br>
Can't you just do something like:<br>
<br>
myMorph _ Node named: answer asSymbol.<br>
<br>
where the #named: message is setting state in the Node?<br>
</blockquote>
<blockquote>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!!!).<br>
</blockquote>
<blockquote>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.<br>
</blockquote>
<blockquote>ned:<br>
</blockquote>
<blockquote>More generally, look at the bigger picture: as you create
these things,<br>
something's got to hold onto them or they won't continue to exist.<br>
</blockquote>
<blockquote>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.<br>
</blockquote>
<blockquote>Ned:<br>
So the assignment of<br>
c := TextMorph new<br>
<br>
just doesn't make any sense here.<br>
</blockquote>
<blockquote>mwg:<br>
</blockquote>
<blockquote>It obviously didn't make sense to Squeak either :o).<br>
</blockquote>
<blockquote>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.<br>
</blockquote>
<blockquote>Ned:<br>
Going a bit further, if you look at the various flavors of #evaluate:
you will</blockquote>
<blockquote>find some where you can specify a context in which to do
the evaluation. For<br>
instance, Workspaces hold variable bindings, and will provide them
when and<br>
if the Compiler needs them (see #bindingOf:).<br>
</blockquote>
<blockquote>mwg:<br>
</blockquote>
<blockquote>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?<br>
<br>
Thanks for you comments, Ned...they do give me some things to try.<br>
</blockquote>
<blockquote>Best Regards,<br>
</blockquote>
<blockquote>Mike<br>
</blockquote>
<blockquote> <br>
</blockquote>
</blockquote>
<blockquote type="cite" cite>
<hr size="1"></blockquote>
<blockquote type="cite" cite>Do you Yahoo!?<br>
<a href="http://antispam.yahoo.com/whatsnewfree">Protect your identity
with Yahoo! Mail AddressGuard</a></blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
</body>
</html>