Re: [stack] language hierarchy

On Dec 11, 2007, at 19:04 , William Tanksley, Jr wrote:

> Don Groves <[email protected]> wrote:
>> William Tanksley, Jr wrote:
>>>> How about "self" as a call to its enclosing context?
>
>>> It won't work for dynamic definitions, because there's no distinct
>>> concept of "enclosing context". All you know is that you're inside a
>>> quotation that's inside another quotation; you can't look ahead  
>>> to see
>>> which enclosure is the one being defined and/or executed. There are
>>> several solutions:
>
>>> 1. Provide special syntax for quoted definitions (perhaps make them
>>> compiled).
>>> 2. Provide recursion primitives like linrec, genrec, etc.
>>> 3. Provide partial continuations.
>
>> You're probably right on this but I'm not entirely convinced.   
>> John said
>> "explicit recursion" which I take to mean calling a function from  
>> within
>> itself. This would seem to leave leave out 1. and 2.
>
> #1 actually is the definition of explicit recursion -- at least for
> any definition which allows using a pseudokeyword rather than naming
> the invoked function directly.
>
>> Maintaining a pointer to the current enclosure should be  
>> sufficient for
>> self invocation. That would require another stack, of course,  
>> which may
>> be worse than having a simple solution to the problem.
>
> Hmm, in effect most concatenative languages keep something
> functionally equivalent to a second stack -- the return addresses of
> all calls. Along with each return address you'd be able to keep a
> recursion address; both would be pushed at CALL time, and RET would
> use the return address while RECURSE uses the recursion address.
> That's not bad semantics... I'm almost tempted to play with it and see
> what else can be done (can one of those fields be used for other
> purposes?).
>
> Of course, the stack usage is doubled or worse, but such, it seems,  
> is life.

I was considering playing with it in ACL, so maybe I should reconsider.
If you do try it, please keep us posted on your results.


>> And using the
>> already existing recursive methods is more in line with concatenative
>> theory anyway, ..., so I'll forget about it ;-)
>
> Is that true? Are the *rec functions especially good with
> concatenative languages? (I don't know.) I'm sure they work with any
> functional language...

Well, they seem to be especially good in Joy, the prototypical  
concatenative
language. As to whether or not something else might work better, at  
this point
I'm not qualified to say.

Thanks,
Don




>
>> Don
>
> -Wm
>
>
>
> Yahoo! Groups Links
>
>
>
>