Xref: utzoo comp.object:563 comp.lang.c++:5754
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!zephyr.ens.tek.com!tekcrl!tekchips!kend
From: kend@tekchips.LABS.TEK.COM (Ken Dickey)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Continuations
Message-ID: <5153@tekcrl.LABS.TEK.COM>
Date: 2 Dec 89 23:51:41 GMT
References: <2664@bingvaxu.cc.binghamton.edu> <9624@pyr.gatech.EDU> <1623@odin.SGI.COM> <1989Nov28.183816.15252@odi.com> <9964@june.cs.washington.edu> <1989Nov29.225826.19483@odi.com> <10008@june.cs.washington.edu>
Sender: ftp@tekcrl.LABS.TEK.COM
Reply-To: kend@mrloog.WR.TEK.COM (Ken Dickey)
Followup-To: comp.object
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 81

Sorry, you got me in a bad mood.  FLAME ON!

In article <10008@june.cs.washington.edu> peterd@june.cs.washington.edu (Peter C. Damron) writes:
>
>The problem I have with including continuations into an object oriented
>language is a philisophical one.  Objects should be self-contained and
>hide information.  All interactions with objects should be through
>the well defined methods of the object.  Now, if you add continuations,
>there is the potential to pass the continuation outside of the object, thus
>creating another entry point into the object that is not a member function.
>I see this as an information hiding problem for continuations in OO languages.

So Smalltalk is not object oriented because it has blocks and returns
objects (remember that may be internal to/components of other
objects)?  How do you implement backtracking objects?  Having the
ability to deal with control flow in well structures ways is very
helpful.  It seems that you are trying to push everything through an
OO keyhole.  Functional interfaces are also well defined.  In
languages such as Scheme, you can program in functional, imparative,
OO, etc. styles as appropriate to the solutions you are trying to
structure.  There are real problems in trying to use a single paradigm
to cover all solutions.  Some just don't fit.

>Let's get this straight.
>...
>2. C and C++ do not allow nested functions, but they do support block
>   structure.  Thus the lexical scoping is not "trivial".

In C you get a local/global namespace.  You don't have name scoping in
blocks nested more than 1 deep.  That's pretty trivial.

>3. Continuations are orthogonal to first-class functions (e.g. languages
>   that allow both upward and downward funargs) and are orthogonal to
>   block structure.  It is not apparent to me that continuations are
>   any less useful without block structure (though C and C++ have it anyway).
>   It is also not apparent to me that continuations are any less useful
>   without nested functions (though maybe more cumbersome).

I suggest that you look at some of the Scheme literature for examples
(e.g. Abelson & Sussman: "Structure and Interpretation of Computer
Programs", MIT Press/McGraw-Hill, 1985).

>4. C and C++ have first class functions.  Functions can be passed as
>   parameters, returned as function values, and assigned to variables.

They cannot be unnamed.  They cannot be parameterized.  They are *not*
first class.

Perhaps a concrete example would help:

(define (curried-add x)
   (lambda (y) (+ x y)) )     ; returns an unnamed function

(define add3 (curried-add 3)) ; function is parameterized & bound
			      ; to a variable.

(add3 5) --> 8                ; usage: add 5 and 3 to get 8


>   The reason that C and C++ do not allow nested functions is precisely
>   so that they can have first-class functions implemented on a stack
>   (e.g. no closure required).  The "parent block" of a function is
>   simply the global variables.

Here you have something.  To quote from David Kranz's thesis ("ORBIT,
an optimizing Compiler for Scheme", Yale U, 1988; p. 9):
	  The important thing to realize is that Pascal and C are really just
	restricted subsets of Scheme, in particular those parts of Scheme
	which can be implemented efficiently using conventional compiler
	technology! 

You have to use non-standard compiler/runtime technology to compile
Scheme efficiently.  However, Scheme is a much smaller, more powerful
language than C.  When C++ becomes a language (when it is described in
a single document and has a well defined semantics) Scheme will be
smaller than C++ as well [the Scheme language report is ~50 pages,
including a formal semantics].

END-FLAME!

-Ken


Brought to you by Super Global Mega Corp .com