Re: why did MIT drop scheme for python in intro to computing?
On Oct 8, 1:23 pm, [EMAIL PROTECTED] (Brian Harvey) wrote: > "Kjetil S. Matheussen" <[EMAIL PROTECTED]> writes: > > >I don't think your speculations makes very much sence. > > Amen. > > And, in any case, there's no need to speculate. MIT has published, on their > web site, pages and pages of rationale for the new curriculum. > > The most important point, imho, is that the programming language was the > /least/ important aspect of the decision. The most important aspect was > the move to an application-based (rather than topic-based) organization > of the curriculum. The details flow out of that big shift of focus. Where is the logic ? python = application based ? scheme = topic based ? Does python have continuations ? Is python progress or regress to the fortran style of natural language ? Dont they both have a great IDE in eclipse with respective plugins? Does scheme have a gui library? I really dont follow the logic. -- http://mail.python.org/mailman/listinfo/python-list
Re: why did MIT drop scheme for python in intro to computing?
On Oct 8, 9:04 pm, Grant Edwards <[EMAIL PROTECTED]> wrote: > On 2007-10-09, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Does scheme have a gui library? > > Yes. It had a far, far better Tk binding than Python. > > http://kaolin.unice.fr/STk/ > > I've used both for real-world applications, and STk was _miles_ > ahead of tkinter. It was a real, native binding to the Tk > library rather than something stuck together with TCL. GUI > widgets were real Scheme objects that acted the way one > expected them to, rather than wrapped TCL objects. > > However, Tk has been largely abandoned in favor of a native > GTK+ binding > > http://www.stklos.org/ > > -- > Grant Edwards grante Yow! You should all JUMP > at UP AND DOWN for TWO HOURS >visi.comwhile I decide on a NEW >CAREER!! Comparing apples with apples, how do you compare the scheme gui library with wxpython ? Isnt it better than Tkinter ? -- http://mail.python.org/mailman/listinfo/python-list
The fundamental concept of continuations
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. Thanks a lot. (6) any good readable references that explain it lucidly ? -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
On Oct 8, 10:59 pm, Barb Knox <[EMAIL PROTECTED]> wrote: > > Lambda calculus. 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). In pure "continuation > style" coding, nothing ever "returns" a result. > > It is easy to mechanically transform normal function-style lambda > calculus into continuation-style, but the reverse is not so. > Explanation and reference please > > You can have a "spaghetti stack", or keep continuation data-structures > in the heap. A picture, diagram? a picture is worth a thousand words -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
On Oct 8, 11:07 pm, Bakul Shah <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > Again I am depressed to encounter a fundamentally new concept that I > > was all along unheard of. > > The concept is 37 years old. Wadsworth in his "Continuation > Revisited" paper says he & Strachey were struggling with > extending the technique of denotational semantics to describe > jumps and not finding a satisfactory answer. Then, in his > words: > >in October 1970 Strachey showed me a paper "Proving >algorithms by tail functions" by Mazurkiewicz [2] which he >had obtained from an IFIP WG2.2 meeting. Just the phrase >"tail functions" in the title was enough -- given the >experience of our earlier struggles -- for the ideas to >click into place! The (meaning of the) "rest of the program" >was needed as an argument to the semantic functions -- just >so those constructs that did not use it, like jumps, could >throw it anyway. The term "continuation" was coined as >capturing the essence of this extra argument (though I >often wished to have a shorter word!) and the rest, as they >say, is history. > > > 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. > > > > Thanks a lot. > > > > (6) any good readable references that explain it lucidly ? > > You might like this one: > > http://www.intertwingly.net/blog/2005/04/13/Continuations-for-Curmudg... thanks for the link but can you plz upload the paper so we can also get it. -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
On Oct 8, 11:09 pm, "." <[EMAIL PROTECTED]> wrote: > On Tue, 09 Oct 2007 05:15:49 +, gnuist006 wrote: > > 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 > > One of the lambda papers, I think. I don't remember which. > > > (2) its syntax and semantics in emacs lisp, common lisp, scheme > > elisp and Common Lisp don't have them (although sbcl and maybe others user > continuations internally). In scheme CALL-WITH-CURRENT-CONTINUATION takes > a function of one argument, which is bound to the current continuation. > Calling the continuation on some value behaves like > CALL-WITH-CURRENT-CONTINUATION returning that value. So > (call/cc (lambda (k) (k 42))) => 42 > You can think of it as turning the whatever would happen after call/cc > was called into a function. The most practical use for continuations in > implementing control structures, though there are some other neat tricks > you can play with them. > > > (3) Is it present in python and java ? > > Certainly not Java, I dunno about Python. I've never seen someone use > them in Python, but the pythonistas seem to want to add everything but a > decent lambda to their language so I wouldn't be surprised if someone had > added a call/cc. Ruby has it. > > > (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. > > You have Lisp in Small Pieces. Read Lisp in Small Pieces. > > > (5) how does it compare to and superior to a function or subroutine > > call. how does it differ. > > You use them like a function call. You can also use them like > setjmp/longjmp in C. You can implement coroutines with them, or > events, or simulate non-determinism or write things like ((call/cc call/cc) > (call/cc call/cc)) and make your head explode, use it like goto's inbred > second cousin or in general whatever perverse things you might like to do > with the flow of control in your program. > > > > > Thanks a lot. > > > (6) any good readable references that explain it lucidly ? > > Lisp in Small Pieces for implementation details, the Scheme Programming > Language for examples. which lambda paper ? -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
On Oct 8, 11:09 pm, "." <[EMAIL PROTECTED]> wrote: > On Tue, 09 Oct 2007 05:15:49 +, gnuist006 wrote: > > > Can anyone explain: > > > (1) its origin > > One of the lambda papers, I think. I don't remember which. Hey no-name "dot" you are the only one who says its origin is in one of the old lambda papers. Give me a reference or someone give me a reference. I dont have access to any ACM journals or other conferences. So step 1 reference and the idea in it step 2 if you can upload it This is for historical and conceptual development at the same time as learning the ideas to use them. Thanks a lot. -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
Special thanks to many of you for your very decent replies. On Oct 9, 11:18 am, George Neuner wrote: > On Tue, 09 Oct 2007 05:15:49 -, [EMAIL PROTECTED] wrote: > >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 > > Lambda calculus. Continuation is just a formal term for "what the > code does next". It manifests, literally, as the next instruction(s) > to be executed. > > >(2) its syntax and semantics in emacs lisp, common lisp, scheme > > Lisp does not have explicit continuations so there is no syntax for > them. Continuations in Lisp mainly take the form of function calls, > function returns, exceptions, conditions, etc. Sometimes code is > written in "continuation passing style" (CPS) in which each function > has one or more additional function parameters (the continuations) - > the function terminates by passing its result as an argument to one of > those continuation functions. > > Scheme has explicit continuations based on closures. Closure > continuations are created using CALL-WITH-CURRENT-CONTINUATION > (usually abbreviated as CALL/CC). Some Schemes also recognize a > LET/CC form used mainly for escape continuations (exceptions). > Scheme's closure continuations can be stored in data structures and > used for complex control forms such as multitasking. Like Lisp, > Scheme code also is sometimes written using CPS. > > >(3) Is it present in python and java ? > > It is present in all languages. It generally takes the form of > procedure or function calls, returns, exceptions, etc. > > >(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. > > As I stated above, every function call or return _is_ a continuation > ... their implementation is obvious. > > For the closure form used in Scheme, the implementation is to create a > closure, a data structure containing the function address and some > method of accessing the function's free variables, and to call the > function. How you do this depends greatly on the instruction set. > > >(5) how does it compare to and superior to a function or subroutine > >call. how does it differ. > > Calling closure continuations is a little more complicated and a bit > slower than calling a normal function. Creating the closure in the > first place may be simple or complicated depending on the complexity > of the source code and the processor's instruction set. > > >Thanks a lot. > > >(6) any good readable references that explain it lucidly ? > > Get yourself a good textbook on compilers. Most of the techniques are > applicable to all languages - even for seemingly very different > languages, the differences in their compilers are simply in how the > basic compilation techniques are combined. > > My favorite intermediate-level books are > > Aho, Sethi & Ullman. "Compilers: Principles, Techniques and Tools". > 2nd Ed. 2006. ISBN 0-321-48681-1. > The first edition from 1986, ISBN 0-201-10088-6, is also worth having > if you can still find it. The 1st edition is mainly about procedural > languages, the 2nd gives more time to functional languages and modern > runtime issues like GC and virtual machines. > > Cooper & Torczon, "Engineering a Compiler", 2004. > ISBN 1-55860-698-X (hardcover), 1-55860-699-8 (paperback). > Also available as a restricted 90-day ebook > fromhttp://rapidshare.com/files/24382311/155860698X.Morgan_20Kaufmann.Eng... > > There are also some decent intro books available online. They don't > go into excruciating detail but they do cover the basics of code > shaping which is what you are interested in. > > Torben Mogensen. "Basics of Compiler > Design"http://www.diku.dk/~torbenm/Basics/ > > "Engineering a Compiler". I don't have this author's name, nor can > Google find it at the moment. I have a copy though (~2MB) - if you > are interested, contact me by email and I'll send it to you. > > Also Google for free CS books. Many older books (including some > classics) that have gone out of print have been released > electronically for free download. > > George > -- > for email reply remove "/" from address -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
On Oct 9, 5:50 am, Matthias Blume <[EMAIL PROTECTED]> wrote: > "." <[EMAIL PROTECTED]> writes: > > On Tue, 09 Oct 2007 05:15:49 +, gnuist006 wrote: > > >> 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 > > One of the lambda papers, I think. I don't remember which. > > This is a common misconception. There is very little that > originated from the "lambda" papers. But they did a marvelous job at > promoting some of the ideas that existed in the PL community for > years. > > As for the concept of continuations, there is Scott and Strachey's > work on denotational semantics, and there is Landin's J operator. > (There's probably more that I am forgetting right now.) > > >> (6) any good readable references that explain it lucidly ? > > One of the most lucid explanations of definitional interpreters -- > including those that are based on continuation-passing -- are > explained in J. Reynolds' famous 1971 "Definitional Interpreters for > Higher-Order Functions" paper. (It has been re-published in 1998 in > HOSC.) The paper also explains how to perform defunctionalization, > which can be seen as a way to compile (and even hand-compile) > higher-order programs. > > Matthias Matthias, thanks for the reference, but I dont have access to an engineering library. I would appreciate, if you have access to paper/ scanner or electronic copy to help many of us out, you are not just helping me but many will thank you. -- http://mail.python.org/mailman/listinfo/python-list
