From the Bibliographic Notes of Chapter 12 Continuations in a Functional Language, Theories of Programming Languages by John C. Reynolds, page 370:
"A history of the repeated discoveries of continuations (occurring largely in the context of functional languages) is given in Reynolds [1993]; relevant original papers include those by van Wijngaarden [1996], F. L. Morris [1993], Strachey and Wadsworth [1974], J. H. Morris [1972], Fischer [1972; 1993], and Abdali [1976]. The operations callcc and throw first appeared in Scheme, but are descendents of Landin's [1965b] "J-operator". Both the continuation-passing transformation from direct to continuation semantics and defunctionalization were described, in the setting of programs for interpreting eager-evaluation functional languages, by Reynolds [1972a]."
"Beginning with the implementation of Scheme [Sussman and Steele Jr., 1975] continuations and the continuation-passing transformation have played a major role in the design of compilers. More recently, this topic has been explored at book length by Appel [1992]."
Reynolds [1993] The Discoveries of Continuations. van Wijngaarden [1996] Recursive Definition of Syntax and Semantics F. L. Morris [1993] The Next 700 Formal Language Descriptions Strachey and Wadsworth [1974] Continuations, A Mathematical Semantics for Handling Full Jumps. J. H. Morris [1972] A Bonus from van Wijngarden's Device Fischer [1972, 1993] Lambda Calculus Schemata Abdali [1976] A Lambda Calculus Model of Programming Languages - I. Simple Constructs, II. Jumps and Procedures Sussman and Steele Jr. [1975] SCHEME: An Interpreter for Extended Lambda Calculus Compiling With Continuations, Andrew W. Appel, 2007
- - - - - - - - - -
> (2) its syntax and semantics in emacs lisp, common lisp, scheme
The Scheme Programming Language, R. Kent Dybvig 3.3 Continuations 5.5 Continuations http://www.scheme.com/tspl3/
Scheme and the Art of Programming, Springer and Friedman Chapter 16 Introduction to Continuations Chapter 17 Using Continuations
- - - - - - - - - - - - -
> (6) any good readable references that explain it lucidly ?
3. Theories of Programming Languages, John C. Reynolds 5.7 Continuation Semantics [of imperative languages] Chapter 12 Continuations in a Functional Language http://www.cs.indiana.edu/eopl/
From the Bibliographic Notes of Chapter 5 Failure, Input-Output and Continuations, Theories of Programming Languages, John C. Reynolds
"Most of the literature on continuations discusses the concept in the setting of functional languages (where we will return to continuations in Section 12.1). However, the properties of continuation semantics for imperative languages are described, perhaps to excess, by Reynolds [1977]."
Reynolds [1977] Semantics of the Domain of Flow Diagrams
2. Essentials of Programming Languages (2nd edition) Friedman, Wand and Haynes Chapter 7 Continuation-Passing Interpreters Chapter 8 Continuation-Passing Style http://www.cs.indiana.edu/eopl/
3. Theories of Programming Languages, John C. Reynolds 5.7 Continuation Semantics [of imperative languages] Chapter 12 Continuations in a Functional Language http://www.cs.cmu.edu/~jcr/tpl.html
jcomeau_ictx <john.com...@gmail.com> writes: > On Oct 9, 1:21 pm, gnuist...@gmail.com wrote: >> On Oct 9, 4:04 am, Rod MacBan <rod_mc...@yahoo.co.uk> wrote: >> > Hi all. >> > What a shock! After reading few wikipedia pages about this argument >> > here around, I realized that early Forth implementations widely used >> > these concepts without naming them: >> > - The vocabulary is a real "spaghetti stack" >> > - Function-pointers (and closures) are customary >> > - The <build-does> creation words produce a continuation.
>> plz give the link to the wiki page you are talking about so we can >> follow you.
> This conversation is from comp.lang.scheme, a discussion on > continuations. "Continuation", "Spaghetti stack", and "Closure" are > all Wikipedia articles.
Don't trust Wikipedia so much.
> But I don't remember the FIG-FORTH vocabulary > as being a spaghetti stack, rather a simple linked list.
It is not.
Each vocabulary (except FORTH) contains loop: it starts with special word called " " (blank), so you could not enter it with keyboard, and ends with top word of vocabulary, which is pointed from within special one. Words in dictionary are stacked, you can FORGET them, but they are threaded with links in vocabularies, the latter gives you tree-structured logical dictionary and hidden loops, so you could get to top words, while search is performed down to the root.
As for Scheme, Chuck Moore attended McCarthy's class, IIRC, he knew LISP anyway.
You confuse vocabulary and dictionary, they differ a lot. Dictionary is a set of all words, vocabulary is not. Vocabulary is known as WORDLIST nowadays.
<BUILDS DOES> doesn't produce continuation, though you can do it, if you wish. You should take a look at FORTH multitasking, it can be done almost portably. (Actually, you may need to rewrite part of system to achive that.)
Yes Aleksej, I mix up two ideas and was wrong about the rest (*blush*). Sorry for the concern: yesterday I posted a bit too fast straight off. The Wikipedia article is: http://en.wikipedia.org/wiki/Continuation and its bottom links. Don't need to continue this thread. Thanks. Rod.
> > On Oct 9, 1:21 pm, gnuist...@gmail.com wrote: > >> On Oct 9, 4:04 am, Rod MacBan <rod_mc...@yahoo.co.uk> wrote: > >> > Hi all. > >> > What a shock! After reading few wikipedia pages about this argument > >> > here around, I realized that early Forth implementations widely used > >> > these concepts without naming them: > >> > - The vocabulary is a real "spaghetti stack" > >> > - Function-pointers (and closures) are customary > >> > - The <build-does> creation words produce a continuation.
> >> plz give the link to the wiki page you are talking about so we can > >> follow you.
> > This conversation is from comp.lang.scheme, a discussion on > > continuations. "Continuation", "Spaghetti stack", and "Closure" are > > all Wikipedia articles.
> Don't trust Wikipedia so much.
> > But I don't remember the FIG-FORTH vocabulary > > as being a spaghetti stack, rather a simple linked list.
> It is not.
> Each vocabulary (except FORTH) contains loop: it starts with special word > called " " (blank), so you could not enter it with keyboard, and ends > with top word of vocabulary, which is pointed from within special one. > Words in dictionary are stacked, you can FORGET them, but they are threaded > with links in vocabularies, the latter gives you tree-structured logical > dictionary and hidden loops, so you could get to top words, while search is > performed down to the root.
> As for Scheme, Chuck Moore attended McCarthy's class, IIRC, > he knew LISP anyway.
> You confuse vocabulary and dictionary, they differ a lot. > Dictionary is a set of all words, vocabulary is not. > Vocabulary is known as WORDLIST nowadays.
> <BUILDS DOES> doesn't produce continuation, though you can do it, if you wish. > You should take a look at FORTH multitasking, it can be done almost portably. > (Actually, you may need to rewrite part of system to achive that.)
> jcomeau_ictx <john.com...@gmail.com> writes: > > On Oct 9, 1:21 pm, gnuist...@gmail.com wrote: > >> On Oct 9, 4:04 am, Rod MacBan <rod_mc...@yahoo.co.uk> wrote: > >> > Hi all. > >> > What a shock! After reading few wikipedia pages about this argument > >> > here around, I realized that early Forth implementations widely used > >> > these concepts without naming them: > >> > - The vocabulary is a real "spaghetti stack" > >> > - Function-pointers (and closures) are customary > >> > - The <build-does> creation words produce a continuation.
> >> plz give the link to the wiki page you are talking about so we can > >> follow you.
> > This conversation is from comp.lang.scheme, a discussion on > > continuations. "Continuation", "Spaghetti stack", and "Closure" are > > all Wikipedia articles.
> Don't trust Wikipedia so much.
> > But I don't remember the FIG-FORTH vocabulary > > as being a spaghetti stack, rather a simple linked list.
> It is not.
> Each vocabulary (except FORTH) contains loop: it starts with special word > called " " (blank), so you could not enter it with keyboard, and ends > with top word of vocabulary, which is pointed from within special one.
Forth doesn't define how the wordlist (or vocabulary, or dictionary) is implemented. Some are implemented as lists, others as hashes; there are many technqiues. No Forth that I know of contains a special word " ". Perhaps you are confusing it with BL, and it may or may not be the top word in the vocabulary. The parser uses blanks to delimit words.
> Words in dictionary are stacked, you can FORGET them, but they are threaded > with links in vocabularies, the latter gives you tree-structured logical > dictionary and hidden loops, so you could get to top words, while search is > performed down to the root.
Hidden loops?
> As for Scheme, Chuck Moore attended McCarthy's class, IIRC, > he knew LISP anyway.
> You confuse vocabulary and dictionary, they differ a lot. > Dictionary is a set of all words, vocabulary is not. > Vocabulary is known as WORDLIST nowadays.
Vocabularies are named WORDLISTs, and they are not the same.
> <BUILDS DOES> doesn't produce continuation, though you can do it, if you wish. > You should take a look at FORTH multitasking, it can be done almost portably. > (Actually, you may need to rewrite part of system to achive that.)
gnuist...@gmail.com writes: > Again I am depressed to encounter a fundamentally new concept that I > was all along unheard of. Its not even in paul graham's book where i > learnt part of Lisp. Its in Marc Feeley's video.
> Can anyone explain:
> (1) its origin > (2) its syntax and semantics in emacs lisp, common lisp, scheme > (3) Is it present in python and java ? > (4) Its implementation in assembly. for example in the manner that > pointer fundamentally arises from indirect addressing and nothing new. > So how do you juggle PC to do it. > (5) how does it compare to and superior to a function or subroutine > call. how does it differ.
Basically, there is no difference to function/subroutine call. The difference is just that there is no "call stack": the dynamic context for a call is created on the heap and is garbage-collected when it is no longer accessible. A continuation is just a reference to the state of the current dynamic context. As long as a continuation remains accessible, you can return to it as often as you like.
Alex McDonald <b...@rivadpm.com> writes: > On Oct 10, 8:17 am, Aleksej Saushev <a...@inbox.ru> wrote: >> jcomeau_ictx <john.com...@gmail.com> writes: >> > On Oct 9, 1:21 pm, gnuist...@gmail.com wrote: >> >> On Oct 9, 4:04 am, Rod MacBan <rod_mc...@yahoo.co.uk> wrote: >> >> > Hi all. >> >> > What a shock! After reading few wikipedia pages about this argument >> >> > here around, I realized that early Forth implementations widely used >> >> > these concepts without naming them: >> >> > - The vocabulary is a real "spaghetti stack" >> >> > - Function-pointers (and closures) are customary >> >> > - The <build-does> creation words produce a continuation.
>> >> plz give the link to the wiki page you are talking about so we can >> >> follow you.
>> > This conversation is from comp.lang.scheme, a discussion on >> > continuations. "Continuation", "Spaghetti stack", and "Closure" are >> > all Wikipedia articles.
>> Don't trust Wikipedia so much.
>> > But I don't remember the FIG-FORTH vocabulary >> > as being a spaghetti stack, rather a simple linked list.
>> It is not.
>> Each vocabulary (except FORTH) contains loop: it starts with special word >> called " " (blank), so you could not enter it with keyboard, and ends >> with top word of vocabulary, which is pointed from within special one.
> Forth doesn't define how the wordlist (or vocabulary, or dictionary) > is implemented.
We speak about FIG model here, see above.
> Some are implemented as lists, others as hashes; there > are many technqiues.
Right, modern Forth does not specify whether WORDLIST is actually list.
> No Forth that I know of contains a special word " ". > Perhaps you are confusing it with BL, and it may or may not be the > top word in the vocabulary. The parser uses blanks to delimit words.
I speak about classic FIG-Forth, as in rev. 1.0, it does vocabularies this way. BL is just a name for blank, right, the name is single BL.
>> Words in dictionary are stacked, you can FORGET them, but they are threaded >> with links in vocabularies, the latter gives you tree-structured logical >> dictionary and hidden loops, so you could get to top words, while search is >> performed down to the root.
> Hidden loops?
I can't find more appropriate words to describe pointer from within, say, FORTH, to TASK, which is initial top word in dictionary.
>> As for Scheme, Chuck Moore attended McCarthy's class, IIRC, >> he knew LISP anyway.
>> You confuse vocabulary and dictionary, they differ a lot. >> Dictionary is a set of all words, vocabulary is not. >> Vocabulary is known as WORDLIST nowadays.
> Vocabularies are named WORDLISTs, and they are not the same.
You speak about ANS Forth again.
If it were from the very beginning, everything would be different.
In standard Forth: a) vocabulary is not a stack, you have to explicitly show nesting with MARKER, if supported; b) dictionary is just a set of independent WORDLISTs, which may be linked in any arbitrary way; c) <BUILDS is replaced with CREATE, but it still doesn't give you continuations; d) you can't create continuations unless you have implementation-defined support.
Well, I mean "easy" ways, obviously nothing stops you from replacing all you have with your new world.
>> <BUILDS DOES> doesn't produce continuation, though you can do it, if you wish. >> You should take a look at FORTH multitasking, it can be done almost portably. >> (Actually, you may need to rewrite part of system to achive that.)
On Wed, 10 Oct 2007 12:49:58 +0200, David Kastrup <d...@gnu.org> wrote: >gnuist...@gmail.com writes:
>> Again I am depressed to encounter a fundamentally new concept that I >> was all along unheard of. Its not even in paul graham's book where i >> learnt part of Lisp. Its in Marc Feeley's video.
>> Can anyone explain:
>> (1) its origin >> (2) its syntax and semantics in emacs lisp, common lisp, scheme >> (3) Is it present in python and java ? >> (4) Its implementation in assembly. for example in the manner that >> pointer fundamentally arises from indirect addressing and nothing new. >> So how do you juggle PC to do it. >> (5) how does it compare to and superior to a function or subroutine >> call. how does it differ.
>Basically, there is no difference to function/subroutine call. The >difference is just that there is no "call stack": the dynamic context >for a call is created on the heap and is garbage-collected when it is >no longer accessible. A continuation is just a reference to the state >of the current dynamic context. As long as a continuation remains >accessible, you can return to it as often as you like.
Yes and no. General continuations, as you describe, are not the only form continuations take. Nor are they the most common form used. The most common continuations are function calls and returns. Upward one-shot continuations (exceptions or non-local returns) are the next most common form used, even in Scheme.
Upward continuations can be stack implemented. On many CPU's, using the hardware stack (where possible) is faster than using heap allocated structures. For performance, some Scheme compilers go to great lengths to identify upward continuations and nested functions that can be stack implemented.
George Neuner <gneuner2/@/comcast.net> writes: > Yes and no. General continuations, as you describe, are not the > only form continuations take. Nor are they the most common form > used. The most common continuations are function calls and returns. > Upward one-shot continuations (exceptions or non-local returns) are > the next most common form used, even in Scheme.
> Upward continuations can be stack implemented. On many CPU's, using > the hardware stack (where possible) is faster than using heap > allocated structures. For performance, some Scheme compilers go to > great lengths to identify upward continuations and nested functions > that can be stack implemented.
There is a Scheme implementation (I keep forgetting the name) which actually does both: it actually uses the call stack but never returns, and the garbage collection includes the stack.
David Kastrup <d...@gnu.org> wrote: +--------------- | George Neuner <gneuner2/@/comcast.net> writes: | > Upward continuations can be stack implemented. On many CPU's, using | > the hardware stack (where possible) is faster than using heap | > allocated structures. For performance, some Scheme compilers go to | > great lengths to identify upward continuations and nested functions | > that can be stack implemented. | | There is a Scheme implementation (I keep forgetting the name) which | actually does both: it actually uses the call stack but never returns, | and the garbage collection includes the stack. +---------------
Chicken Scheme is actually using the C call stack *as* the heap[1], and thus all its continuations are *heap*-allocated, and thus not actually "stack-allocated" at all.
But that's not what George Neuner is talking about, as I read it, but rather probably about such things as Kent Dybvig's PhD thesis:
http://www.cs.indiana.edu/~dyb/papers/3imp.pdf "Three Implementation Models for Scheme" R. Kent Dybvig, UNC Chapel Hill, 1987 (thesis) (190pp) ... Chapter 4: The Stack-Based Model ... Early Scheme implementors believed that because of the need to support first class functions, the standard techniques used for block-structured languages were not suitable for Scheme. The need to optimize tail calls and support continuations further convinced early implementors that the standard stack techniques were unsuitable. However, as this chapter will show, these techniques can be made to work for Scheme with a few modications. The resulting implementation model allows most function calls to be performed with little or no allocation, and allows variable references to be performed in one or two memory references. Heap allocation remains necessary to support closures, assigned variables, and continuations. Since function calls and variable references are faster and heap allocation is limited, the running time for most programs is greatly decreased. ...
David Kastrup <d...@gnu.org> writes: > There is a Scheme implementation (I keep forgetting the name) which > actually does both: it actually uses the call stack but never returns, > and the garbage collection includes the stack.
Matthias Benkard <mulkiat...@gmail.com> wrote: > continuations. There used to be a project called Stackless Python that > tried to add continuations to Python, but as far as I know, it has always > been separate from the official Python interpreter. I don't know whether > it's still alive. You may want to check http://stackless.com/
Alive and well, but it has removed continuations (which were indeed in early versions, as per the paper at <http://www.stackless.com/spcpaper.htm>).
In message <see-36543E.18592809102...@lust.ihug.co.nz>, Barb Knox wrote:
> Instead of function A returning to its caller, the > caller provides an additional argument (the "continuation") which is a > function B to be called by A with A's result(s).
That's just a callback. I've been doing that in C code (and other similar-level languages) for years.
>> Instead of function A returning to its caller, the >> caller provides an additional argument (the "continuation") which is a >> function B to be called by A with A's result(s).
>That's just a callback. I've been doing that in C code (and other >similar-level languages) for years.
Callbacks are a form of continuation. However, general continuations such as those in Scheme, carry with them their execution context. This allows them to used directly for things like user-space threading.
>>>Instead of function A returning to its caller, the >>>caller provides an additional argument (the "continuation") which is a >>>function B to be called by A with A's result(s).
>>That's just a callback. I've been doing that in C code (and other >>similar-level languages) for years.
> Callbacks are a form of continuation.
Yes, in the same sense that a shoe is a form of aircraft carrier.
>>>>Instead of function A returning to its caller, the >>>>caller provides an additional argument (the "continuation") which is a >>>>function B to be called by A with A's result(s).
>>>That's just a callback. I've been doing that in C code (and other >>>similar-level languages) for years.
>> Callbacks are a form of continuation.
>Yes, in the same sense that a shoe is a form of aircraft carrier.
I was pointing out a simple technical fact. I'm not at all sure what you are pointing out. shoe <=> aircraft carrier?
Beside which, CL doesn't have "real" continuations ... a fact that amuses Schemers no end. You are a Lisper so I don't know where you get off acting so smug.
>>>>>Instead of function A returning to its caller, the >>>>>caller provides an additional argument (the "continuation") which is a >>>>>function B to be called by A with A's result(s).
>>>>That's just a callback. I've been doing that in C code (and other >>>>similar-level languages) for years.
>>>Callbacks are a form of continuation.
>>Yes, in the same sense that a shoe is a form of aircraft carrier.
> I was pointing out a simple technical fact.
Well, I am just a simple application programmer so I am having trouble understanding how a callback is a continuation, emphasis on "continue". Please elucidate. My fear is that your answer is that it is a continuation that happens to continue nothing, like an object at rest is moving but at a zero velocity. Just as ...
> I'm not at all sure what > you are pointing out. shoe <=> aircraft carrier?
... a shoe is an aircraft carrier without all the planes. Inter alia.
> Beside which, CL doesn't have "real" continuations ... a fact that > amuses Schemers no end.
No, you are thinking of the fact that your spec is shorter than the index to our spec. I hear it's growing fast, tho, and every serious Schemer is locked into just as big a ball of mud as Lisp, except it is one they built and the consequence that you have this tower of bable thing going which CL solved twenty years ago with the standard whose index size amuses you amuses us. No end.
Continuations would be great if I needed anything like them more than once every twelve months and could not Greenspun them myself with state which is probably the right way to go anyway since it makes the state required to continue a calculation explicit -- ok, sorry, continuations are a stupid pet trick, obscurantist and superflewous and they probably hasten hair loss. You should lose them, make your spec even smaller.
> You are a Lisper so I don't know where you > get off acting so smug.
>Well, I am just a simple application programmer so I am having trouble >understanding how a callback is a continuation, emphasis on "continue".
And here I was laboring under the impression that you were a god 8-)
>Please elucidate.
Technically, a continuation is just "whatever happens next". It manifests at all levels:
- as the next CPU instruction in a sequence. Sequences are not necessarily contiguous, e.g., FPU instructions may take many cycles so the FPU instruction that continues the computation may follow several unrelated instructions destined for other units.
- as the next basic block in a compiler trace. The outputs of a basic block are the inputs of the one that follows.
- at the programming language level in virtually all languages as gotos, function/procedure calls and returns, non-local returns, etc. In this context, closures are just fancy functions, not a separate category.
- and ultimately as in Scheme where they might represent the context of a paused execution path. Reified execution context is the basis of OS process and thread abstractions. What is unique about Scheme's continuation is not the idea, rather the way the idea is integrated into the language.
High level programming books, particularly those based on Scheme, like to profess that continuations are something magical, but in practice their use tends to be rather mundane.
>My fear is that your answer is a continuation that happens to continue >nothing, like an object at rest is moving but at a zero velocity. >Just as ...
Depends on your point of view. I'm not knocking continuations - far from it - continuations are everywhere and nothing could be done without them. I'm just pointing out that they are not magic.
George Neuner wrote: > On Mon, 15 Oct 2007 11:22:28 -0400, Ken Tilton > <kennytil...@optonline.net> wrote:
>>Well, I am just a simple application programmer so I am having trouble >>understanding how a callback is a continuation, emphasis on "continue".
> And here I was laboring under the impression that you were a god 8-)
I see. You people won't listen to me on GUI programming but you are hard at work on my Bible? Time for the yellow bulldozers, this experiement is done.
>>Please elucidate.
> Technically, a continuation is just "whatever happens next".
See, this is why need not just dumb trench-digging application programmers like me, we also need supertheoretical functional geniuses to come up the Deep Insights. Until now I thought I was about to make a coffee run, but now I see that even though it will be a new coffee run it is still what happens next and if I get pulled over and the cop wants to know what's the hurry I'll just tell him he is interrupting a Scheme continuation.
Ken Tilton <kentil...@gmail.com> wrote: +---------------
| George Neuner wrote:
| > Technically, a continuation is just "whatever happens next". | | See, this is why need not just dumb trench-digging application | programmers like me, we also need supertheoretical functional geniuses | to come up the Deep Insights. Until now I thought I was about to make a | coffee run, but now I see that even though it will be a new coffee run | it is still what happens next and if I get pulled over and the cop wants | to know what's the hurry I'll just tell him he is interrupting a Scheme | continuation. +---------------
Ahhh, Kenny, Kenny, you're missing the whole point of "real" (Schemish) continuations. Here's how your story *should* go, which may help explain (or not):
0. You're slaving away on Cello version 72531.22.91 when you realize you've *got* to have some coffee, but you know you're going to be working all night and you only have enough cash left after buying that 42nd mongo flatpanel [needed to show off the full feature set of Cello version 72531.22.90] to buy one cup. Thankfully, you've been reading this thread, so you...
1. Put a sticky note on your monitor to remind you what it is you want to do next after your coffee break [note (and this is very important): you SETF the note, not LET-bind it!!] and then you make your coffee run (but *DON'T* drink it yet!!) and bring it back to the CelloCAVE, and while it's nice and hot, just before you take the first sip, you do a CALL/CC and stick the resulting continuation you got into a special box on a shelf near the door. Then you...
2. Enjoy your coffee, get your caffeine rush, and head back to your coding CAVE and start doing whatever it says on the little yellow sticky you put on your monitor in step #1.
Now here's where the real fun starts...
3. Several hours [minutes?!?] later, having used up your caffeine rush [but Cello 72531.22.91 still being unfinished], it's time for another coffee run, but as noted in #0 you now have no money left. No problemo! Make a note to yourself on a little yellow sticky saying what you want to do after your coffee and stick it on your monitor [SETF, not LET-bind!], then go over next to the door and FUNCALL the continuation in the box on the shelf by the door, and you...
4. Wake up, just back from the coffee run you made in #1, with a hot steaming cut of fresh coffee in your hand, which you enjoy, get your rush, and head back to your coding CAVE and start doing whatever it says on the little yellow sticky you put on your monitor in step #1.
3a. Several hours [minutes?!?] later, having used up your caffeine rush [but Cello 72531.22.91 still being unfinished], it's time for another coffee run, but as noted in #0 you now have no money left. No problemo! Make a note to yourself on a little yellow sticky saying what you want to do after your coffee and stick it on your monitor [SETF, not LET-bind!], then go over next to the door and FUNCALL the continuation in the box on the shelf by the door, and you...
4a. Wake up, just back from the coffee run you made in #1, with a hot steaming cut of fresh coffee in your hand, which you enjoy, get your rush, and head back to your coding CAVE and start doing whatever it says on the little yellow sticky you put on your monitor in step #1.
And you continue in this way, never having to pay for another cup of coffee, until Cello 72531.22.91 *is* finally finished, then you...
5. Crash all weekend, and get up on Sunday night just long enough to post the announcement of Cello 72531.22.91 [no documentation, of course, but it all *WORKS*!!] to "comp.lang.lisp", and then crash back in your bed again. [Only to wake up Monday morning to discover that the ungrateful yobbos of "c.l.lisp" are all bitching about the (lack of) documentation instead of singing hosannas about all the new features... But that's another story.]
In a nutshell: The thing that's different about full/real/Schemish continuations is that you can call them more than once. But note that only the *control* path is repeated; any globals that you SETF'd [such as the yello sticky] *aren't* reset when you call the continuation a 2nd, 3rd, 4th, etc., time, so you can use them to tell the difference between successive FUNCALLs of the continuation.
-Rob
p.s. Smart Schemers will realize I've cheated in the above story. Well, unless somebody knows how to instantiate a cup of coffee entirely in the control path and not in a stateful "coffee-mug object" whose mutations (and eventual emptiness) *will* be noticed across reinvocations of the continuation.
----- Rob Warnock <r...@rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
> In a nutshell: The thing that's different about full/real/Schemish > continuations is that you can call them more than once. But note > that only the *control* path is repeated; any globals that you > SETF'd [such as the yello sticky] *aren't* reset when you call the > continuation a 2nd, 3rd, 4th, etc., time, so you can use them to > tell the difference between successive FUNCALLs of the continuation.
Thank you for that. I've read about continuations, but the accounts missed off the crucial detail that the globals aren't reset, so I was left going "Huh? That's not gonna work!"
r...@rpw3.org (Rob Warnock) writes: > In a nutshell: The thing that's different about full/real/Schemish > continuations is that you can call them more than once. But note > that only the *control* path is repeated; any globals that you > SETF'd [such as the yello sticky] *aren't* reset when you call the > continuation a 2nd, 3rd, 4th, etc., time, so you can use them to > tell the difference between successive FUNCALLs of the continuation.
Local bindings that have been SETF'd are also not reset, though of course they're subject to scope as usual. For example, this:
Jed Davis <j...@panix.com> wrote: +--------------- | r...@rpw3.org (Rob Warnock) writes: | > In a nutshell: The thing that's different about full/real/Schemish | > continuations is that you can call them more than once. But note | > that only the *control* path is repeated; any globals that you | > SETF'd [such as the yello sticky] *aren't* reset when you call the | > continuation a 2nd, 3rd, 4th, etc., time... | | Local bindings that have been SETF'd are also not reset, though of | course they're subject to scope as usual. +---------------
Yes, of course. You caught me oversimplifying for tutorial purposes...
-Rob
----- Rob Warnock <r...@rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
Rod MacBan <rod_mc...@yahoo.co.uk> writes: >Hi all. >What a shock! After reading few wikipedia pages about this argument >here around, I realized that early Forth implementations widely used >these concepts without naming them: >- The vocabulary is a real "spaghetti stack"
In fig-Forth the dictionary is a cactus stack (aka spaghetti stack): each vocabulary was an extension of its parent dictionary (at the time that the child vocabulary was created). That partially alleviates the absence of a search order in fig-Forth.
In modern Forth systems the wordlists (a concept simular to a vocabulary) are separate, and the search order allows searching them in any order (not just the CONTEXT vocabulary, its ancestors, and the CURRENT vocabulary and its ancestors).
>- Function-pointers (and closures) are customary
Not sure what you mean by that, but execution tokens (XTs) are (a generalised form of) function pointers (you have XTs for all words, not just for colon definitions (which correspond to functions in C and Lisp)).
Forth does not have closures in the usual sense, because Forth does not normally have nested definitions; moreover, pure Forth does not have local variables. And even if a Forth system has both locals and nested definitions, it does not allow referencing locales that are not from the innermost definition.
You can get something like a closure with CREATE...DOES> (in fig-Forth, <BUILDS...DOES>), or by defining a colon definition with the contents of the free variables compiled in as literals (the latter can even be anonymous in ANS Forth). However, in Forth the resulting word will stay around until the system is terminated, whereas you usually expect closures to be garbage collected.
>- The <build-does> creation words produce a continuation.
Not in the least. The only kind of continuation you have in Forth is the contents of the return stack (and for a proper continuation, you need to combine this with the contents of the other stacks (data, FP, and possibly locals). And that's a second-class citizen in any Forth implementation, and even more restricted in standard Forth (i.e., no standard Forth way to save and restore a continuation).
