I could not resist commenting upon your clever idea.
As a way to rewrite the original version :
>to selgetal :lijst
>if emptyp :lijst [op []]
>if memberp first :lijst [1 2 3 4 5 6 7 8 9][op fput first :lijst (selgetal bf
:lijst)]
>op selgetal bf :lijst
>end
you suggest :
>to selgetal :lijst
>if emptyp :lijst [op []]
>output sentence ifelse memberp first :lijst [1 2 3 4 5 6 7 8 9] ~
> [first :lijst] [] selgetal butfirst :lijst
>end
which avoids calling selgetal butfirst :lijst
in two different lines.
Just a few comments.
1- I don't have any available Logo right now,
but I'm not sure your version would work, as is, on all interpreters.
You probably intended :
>output sentence ifelse memberp first :lijst [1 2 3 4 5 6 7 8 9] ~
> [first :lijst] [[]] selgetal butfirst :lijst
2- What if, instead of [1 2 3 4 5 6 7 8 9],
the list of acceptable candidates was [1 2 3 [4] 5 6 7 8 9]?
This means that 4 should be rejected, and [4] should be kept and
selgetal [1 2 d 4 5 6 [4] 8] should answer [1 2 5 6 [4] 8].
To achieve this, we could simply replace [1 2 3 4 5 6 7 8 9]
by [1 2 3 [4] 5 6 7 8 9] in the code of the procedure.
Now the original version would still work as expected,
but the second version would answer [1 2 5 6 4 8]!
A minor adjustment is needed, because
sentence [4] [5 6 7] is not equivalent to fput [4] [5 6 7].
As a workaround, we could use
sentence (list <something>) <list>
which is really equivalent to fput <something> <list>
Ex: sentence (list [4]) [5 6 7] is equivalent to fput [4] [5 6 7]
(both expressions output [[4] 5 6 7 ])
So here is a third (even less efficient) version.
to selgetal :lijst
if emptyp :lijst [op []]
output sentence ifelse memberp first :lijst [1 2 3 4 5 6 7 8 9] ~
[list (first :lijst)] [[]] selgetal butfirst :lijst
end
3- Speaking of efficiency (which is a little besides the point here) :
Let's say we have a list of length n from which to keep m items.
(i.e. m <= n)
- in all versions selgetal is called exactly n times
(including the top level call)
- the first version calls fput ONLY m times
- to emulate those m calls,
the second version ALWAYS calls sentence n times
(plus m calls to list in the third version)
Unless sentence is a much more efficient list constructor than fput
(which I doubt), there is surely an overhead.
Of course there might be other factors involved here,
such as the way logo interprets procedures.
(Perhaps Brian Harvey would have more to say on this).
4- There remains the issue of style, but this is another matter.
Thanks again for a refreshing idea.
Happy New Year!
Jean-Pierre L'Archeveque
---------------------------------------------------------------
Please post messages to the Logo forum to logo-l@gsn.org. Mail
questions about the list administration to logofdn@gsn.org. To
unsubscribe send unsubscribe logo-l to majordomo@gsn.org.