Hi, all. A question arose recently on the Squeak-dev mailing list (a list mostly inhabited by software engineers) concerning "recursion in etoys." I wrote a reply, which I'm herewith forwarding to the Squeakland list, on the chance that this information might be useful to some readers. BTW my reply was suppressed by the moderators of the Squeak-dev list, who said it was too large, so it never did actually appear on that list ;-)
-- Scott
------------------------------------------------------------------------------------
Hi, Kevin,
Yes, etoys do support recursion. But they don't have a good way of detecting and recovering from *runaway* recursion, which is what was befalling your script.
Here's a recursive etoy script which does what you want, and which *does* converge, provided that there is a patch of the appropriate blue somewhere ahead of the Star:
Two points to note here:
(1) The critical difference between this and what you did is that after the *copy* is made, this script "includes" that copy in the container. Without the "include," the copy isn't present in the "world", so neither it nor any future generation of "copy" will be "over blue" and hence terminate the recursion. That's why your recursion ran away.
(2) In the last line, it's *okay* simply to have "Star's nextGuy approachBlue". The value of the "do" inserted here is that this defers the recursive #approachBlue script call until the next cycle of the simulation. The result will be there will be a sense of "movement" since each generation will be born on a different tick, whereas without the "do" all the generations will be born within the same "tick" so all will appear instantaneously -- a much less nice effect.
Cheers,
Scott
PS: Please check out Squeakland.org, and you may well want to subscribe to the Squeakland mailing list: http://www.squeakland.org/mailman/listinfo/squeakland
At 10:08 AM -0800 3/25/05, Kevin Lawrence wrote:
Is it appropriate to post questions about etoys to this list ?
[I'll risk it this time - let me know if there is somewhere else I should be asking, thanks.]
I tried making a simple etoys script with recursion and it hangs as soon as I click the run icon.
the script was essentially (excuse my Java-ish pseudocode) ...
spawn script test self.sees blue
yes
no self.newCopy = self.copy self.newCopy.forwardBy self.length self.newCopy.spawn
Assuming I haven't made a really silly *mistake, should this work ?
Is recursion supported ?
(I searched the bug database but couldn't find anything)
Thanks !
Kevin
- Please tell me if there is a silly mistake !
Interesting, Scott, however, I don't see what would stop apporachBlue script if nothing is in the Yes "fork."
Also, my experience with recursion was basically from my work with Logo, where I had to call a procedure (within itself) for that procedure to be recursive. Since a ticking Squeak script keeps calling itself why was it even necessary for you to add the "do approachBlue" (recursive call) to your version of the script?
Phil
On Mar 28, 2005, at 2:15 AM, Scott Wallace wrote:
Hi, all. A question arose recently on the Squeak-dev mailing list (a list mostly inhabited by software engineers) concerning "recursion in etoys." I wrote a reply, which I'm herewith forwarding to the Squeakland list, on the chance that this information might be useful to some readers. BTW my reply was suppressed by the moderators of the Squeak-dev list, who said it was too large, so it never did actually appear on that list ;-)
-- Scott
Hi, Kevin,
Yes, etoys do support recursion. But they don't have a good way of detecting and recovering from *runaway* recursion, which is what was befalling your script.
Here's a recursive etoy script which does what you want, and which *does* converge, provided that there is a patch of the appropriate blue somewhere ahead of the Star:
<image.tiff> Two points to note here:
(1) The critical difference between this and what you did is that after the *copy* is made, this script "includes" that copy in the container. Without the "include," the copy isn't present in the "world", so neither it nor any future generation of "copy" will be "over blue" and hence terminate the recursion. That's why your recursion ran away.
(2) In the last line, it's *okay* simply to have "Star's nextGuy approachBlue". The value of the "do" inserted here is that this defers the recursive #approachBlue script call until the next cycle of the simulation. The result will be there will be a sense of "movement" since each generation will be born on a different tick, whereas without the "do" all the generations will be born within the same "tick" so all will appear instantaneously -- a much less nice effect.
Cheers,
Scott
PS: Please check out Squeakland.org, and you may well want to subscribe to the Squeakland mailing list: http://www.squeakland.org/mailman/listinfo/squeakland
At 10:08 AM -0800 3/25/05, Kevin Lawrence wrote: Is it appropriate to post questions about etoys to this list ?
[I'll risk it this time - let me know if there is somewhere else I should be asking, thanks.]
I tried making a simple etoys script with recursion and it hangs as soon as I click the run icon.
the script was essentially (excuse my Java-ish pseudocode) ...
spawn script test self.sees blue
yes
no self.newCopy = self.copy self.newCopy.forwardBy self.length self.newCopy.spawn
Assuming I haven't made a really silly *mistake, should this work ?
Is recursion supported ?
(I searched the bug database but couldn't find anything)
Thanks !
Kevin
- Please tell me if there is a silly mistake !
<P5E04C520>_______________________________________________ Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Hi, Phil,
In this example, the approachBlue script is not *ticking* -- it is just run once per star, and the result -- until termination -- is the birth of a new star a bit to the right of the star, which is then told to run -- again *once* -- its approachBlue script.
This continues until one of the newborn stars finally hits blue, in which case it does *not* follow the NO branch and hence does not make a fresh copy -- so that's how things terminate.
(This is actually not true recursion, which, I think, would be when a script in an object calls the same script in that *same* object. But it's something close.)
In Squeak, we would normally do this example using a ticking script, as you suggest, without the recursion. If at each step the star used "stamp", the trail would end up with the same appearance as Kevin wanted, but all done using a single star rather than a whole series of them.
But I think Kevin wanted to try it the way he did just to explore the possibilities of recursion in Squeak.
Cheers,
-- Scott
At 8:22 AM -0500 3/28/05, Phil Firsenbaum wrote:
Interesting, Scott, however, I don't see what would stop apporachBlue script if nothing is in the Yes "fork."
Also, my experience with recursion was basically from my work with Logo, where I had to call a procedure (within itself) for that procedure to be recursive. Since a ticking Squeak script keeps calling itself why was it even necessary for you to add the "do approachBlue" (recursive call) to your version of the script?
Phil
On Mar 28, 2005, at 2:15 AM, Scott Wallace wrote:
Hi, all. A question arose recently on the Squeak-dev mailing list (a list mostly inhabited by software engineers) concerning "recursion in etoys." I wrote a reply, which I'm herewith forwarding to the Squeakland list, on the chance that this information might be useful to some readers. BTW my reply was suppressed by the moderators of the Squeak-dev list, who said it was too large, so it never did actually appear on that list ;-)
-- Scott
Hi, Kevin,
Yes, etoys do support recursion. But they don't have a good way of detecting and recovering from *runaway* recursion, which is what was befalling your script.
Here's a recursive etoy script which does what you want, and which *does* converge, provided that there is a patch of the appropriate blue somewhere ahead of the Star:
<image.tiff> Two points to note here:
(1) The critical difference between this and what you did is that after the *copy* is made, this script "includes" that copy in the container. Without the "include," the copy isn't present in the "world", so neither it nor any future generation of "copy" will be "over blue" and hence terminate the recursion. That's why your recursion ran away.
(2) In the last line, it's *okay* simply to have "Star's nextGuy approachBlue". The value of the "do" inserted here is that this defers the recursive #approachBlue script call until the next cycle of the simulation. The result will be there will be a sense of "movement" since each generation will be born on a different tick, whereas without the "do" all the generations will be born within the same "tick" so all will appear instantaneously -- a much less nice effect.
Cheers,
Scott
PS: Please check out Squeakland.org, and you may well want to subscribe to the Squeakland mailing list: http://www.squeakland.org/mailman/listinfo/squeakland
At 10:08 AM -0800 3/25/05, Kevin Lawrence wrote: Is it appropriate to post questions about etoys to this list ?
[I'll risk it this time - let me know if there is somewhere else I should be asking, thanks.]
I tried making a simple etoys script with recursion and it hangs as soon as I click the run icon.
the script was essentially (excuse my Java-ish pseudocode) ...
spawn script test self.sees blue
yes
no self.newCopy = self.copy self.newCopy.forwardBy self.length self.newCopy.spawn
Assuming I haven't made a really silly *mistake, should this work ?
Is recursion supported ?
(I searched the bug database but couldn't find anything)
Thanks !
Kevin
- Please tell me if there is a silly mistake !
<P5E04C520>_______________________________________________ Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Scott Wallace wrote:
In Squeak, we would normally do this example using a ticking script, as you suggest, without the recursion. If at each step the star used "stamp", the trail would end up with the same appearance as Kevin wanted, but all done using a single star rather than a whole series of them.
But I think Kevin wanted to try it the way he did just to explore the possibilities of recursion in Squeak.
Thanks for all the help Scott - I added the "include in playfield" and all was well.
I was helping a friend who was trying to make a grid of cells (he is trying to do Conway's Life). We tried lots of different (failed) approaches before resorting to recursion - at that point we would have been happy with anything that worked :-)
If someone has a simpler (or more 'natural') algorithm for "draw a 20x20 grid of cells", I'd love to see it !
Thanks !
Kevin
In Etoys, of course, one can call up a grid of any size which replaces the World's background...
On Mar 28, 2005, at 2:47 PM, Kevin Lawrence wrote:
If someone has a simpler (or more 'natural') algorithm for "draw a 20x20 grid of cells", I'd love to see it !
Thanks !
Kevin _______________________________________________ Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Hello all,
A couple of days ago (when this thread was still fresh), I tried to mail out a quick and dirty example of what I thought Alan was describing; the project file was too big and the message bounced.
Anyway, I finally found the relocated Squeakland super swiki and have posted the project there:
http://www.squeakalpha.org/project.jsp?http://www.squeakalpha.org/uploads/tr...
For those new to the list, the super swiki (http://squeakalpha.org:8080/super) serves as a repository and gallery of projects that have been shared by the Squeak community. You can choose to save a project to the super swiki when you click "publish it;" before this suggestion gets people in trouble, though, I remind you to think hard about privacy issues before publishing just any project on the super swiki.
Best,
John
There is also an example in a project called "Biobob", probably on BSS somewhere ...
Cheers,
Alan
At 08:07 AM 3/30/2005, JOHN VOIKLIS wrote:
Hello all,
A couple of days ago (when this thread was still fresh), I tried to mail out a quick and dirty example of what I thought Alan was describing; the project file was too big and the message bounced.
Anyway, I finally found the relocated Squeakland super swiki and have posted the project there:
http://www.squeakalpha.org/project.jsp?http://www.squeakalpha.org/uploads/tr...
For those new to the list, the super swiki (http://squeakalpha.org:8080/super) serves as a repository and gallery of projects that have been shared by the Squeak community. You can choose to save a project to the super swiki when you click "publish it;" before this suggestion gets people in trouble, though, I remind you to think hard about privacy issues before publishing just any project on the super swiki.
Best,
John _______________________________________________ Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Hi Folks --
This brings up an interesting pedagogical question about recursion and objects.
Smalltalk (and hence Squeak) has full capabilities for recursion, and etoys could (and maybe should) also.
On the other hand, let's take an example, such as drawing/building a tree shape. A LOGO-like recursive approach would be to make a procedure that draws a V shape, and then write a recursive procedure that invokes this V at different sizes and angles to draw the tree.
Another, more object oriented, approach that is a little more biological is to make a branch object with a non-looping method that creates sprouting further branches (copies of itself) of the tree and gives them "life" to create limbs of their own using the sprouting method. This is much simpler to think about and do, it actually creates a tree of branch objects, and the technique generalizes much better to massively parallel structures that are more complicated than simple nested structures.
The interesting dualism here was noted when objects where invented, that because objects have a full copy of state (whereas procedures don't), there often no good reason for using an invisible stack of contexts where a visible collection of objects would better serve ....
Not that there aren't some nice and neat things that can be done with recursion, but it seems to me, where kids are concerned, there should be big payoffs for each concept that is trying to find a place in the kids' 7+-2 chunks used to think with -- and recursion doesn't make the initial cut in my opinion.
Cheers,
Alan
At 11:15 PM 3/27/2005, Scott Wallace wrote:
Hi, all. A question arose recently on the Squeak-dev mailing list (a list mostly inhabited by software engineers) concerning "recursion in etoys." I wrote a reply, which I'm herewith forwarding to the Squeakland list, on the chance that this information might be useful to some readers. BTW my reply was suppressed by the moderators of the Squeak-dev list, who said it was too large, so it never did actually appear on that list ;-)
-- Scott
Hi, Kevin,
Yes, etoys do support recursion. But they don't have a good way of detecting and recovering from *runaway* recursion, which is what was befalling your script.
Here's a recursive etoy script which does what you want, and which *does* converge, provided that there is a patch of the appropriate blue somewhere ahead of the Star:
6ab46315.jpg
Two points to note here:
(1) The critical difference between this and what you did is that after the *copy* is made, this script "includes" that copy in the container. Without the "include," the copy isn't present in the "world", so neither it nor any future generation of "copy" will be "over blue" and hence terminate the recursion. That's why your recursion ran away.
(2) In the last line, it's *okay* simply to have "Star's nextGuy approachBlue". The value of the "do" inserted here is that this defers the recursive #approachBlue script call until the next cycle of the simulation. The result will be there will be a sense of "movement" since each generation will be born on a different tick, whereas without the "do" all the generations will be born within the same "tick" so all will appear instantaneously -- a much less nice effect.
Cheers,
Scott
PS: Please check out Squeakland.org, and you may well want to subscribe to the Squeakland mailing list: http://www.squeakland.org/mailman/listinfo/squeakland
At 10:08 AM -0800 3/25/05, Kevin Lawrence wrote:
Is it appropriate to post questions about etoys to this list ?
[I'll risk it this time - let me know if there is somewhere else I should be asking, thanks.]
I tried making a simple etoys script with recursion and it hangs as soon as I click the run icon.
the script was essentially (excuse my Java-ish pseudocode) ...
spawn script test self.sees blue
yes
no self.newCopy = self.copy self.newCopy.forwardBy self.length self.newCopy.spawn
Assuming I haven't made a really silly *mistake, should this work ?
Is recursion supported ?
(I searched the bug database but couldn't find anything)
Thanks !
Kevin
- Please tell me if there is a silly mistake !
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
squeakland@lists.squeakfoundation.org
-
Alan Kay -
JOHN VOIKLIS -
Kevin Lawrence -
Phil Firsenbaum -
Scott Wallace