dorai@hedera.rice.edu (Dorai Sitaram) (03/18/90)
$The efficiency issue is not clear. It all depends on the exact
$implementation of call-with-current-continuation. If the
$continuations share structure (as they do in some implementationts),
$the solution based on F is no more time or space efficient.
$
$Note also that your version is shorter because you have moved some of
$the code to the use point (by inserting "prompts").
Hi, I'll take the liberty of answering you on the net too, for
purposes of clarification. This will not prevent the following from
being a bit dense at times, since I'm looking for answers too, not
being an awesome efficiency person (I program in Scheme, right?!).
My (_not_ sole) misgiving about (just) callcc is that because of its
higher-order continuations, it'll end up being just a wee bit too
powerful. Even when it's being used in a purely first-order setting
that requires _no_ structure (heap) at all, let alone structure
sharing, e.g., function/loop exits or just about any _delimiting_ use
of callcc.
Sharing structure between a grabbed continuation k1 and a subsequently
grabbed continuation k2, while fine, doesn't help (IMHO. You can
correct me here.) in the following cases:
a) If k1 is never used but as a delimiter to k2, the structure
allotted to k1 is excess baggage.
b) If k2 is used only to abort to k1, the structure alloted to k2
(whether the whole enchilada or just the difference from k1), is e.b.
I suspect that these things are not compiler-recognizable in a purely
callcc world. (IMHO, of course.) The k1/k2 syndrome shows up in Rick
Schaut's code, and it shows up not infrequently, though not so
clearly, in many other callcc situations.
Now, in a P world, a) is recognizable for the trivial reason that the
user supplies the information! This information doesn't consist of
the user saying "this is a delimiting use of callcc"; it is specified
by mentioning the delimiting, period (i.e., no continuation, shared or
otherwise, is grabbed at all). Hence, the ability of the user to
specify this information gives her a useful programming paradigm. She
hasn't lost anything however: she can continue to use callcc (or C or
F) _only_ and never bother about P at all. Furthermore, delimiting
costs nothing: it does lessen the cost of the control reifiers used
within it.
To be complete, b) is easily recognizable in a P world using a
cleaned-up but equivalent version of callcc, C (not the language!), or
an enhanced version, F. This isn't terribly interesting so I won't go
into it.
Re the positioning of P in tree-map: it appears to make sense to use
it at the start of a debug code-run. I.e., at the point where one
receives the result, or failing which, debug information. (That's
what "prompts" (albeit non-first-class) _are_ in the realworld (tm)
anyway.) However, it might appear I'm using too many textual P's;
this can be easily abstracted away, by putting them into the tree-map
code itself:
(define tree-map
(lambda (filter tree)
;-
(P (let ... (cond ...
;-
[(atom? tree)
... (F (lambda (context)
(list 'not-yet tree
;----------------------------
(lambda (debug-insert)
(P (context debug-insert)))))) ...]
;----------------------------
...)))))
Sure, this clouds the fact that each debug-run is run inside a prompt,
but retrieves Rick's callcc-based debugging style.
Going to things other than efficiency, note that I've made no claim
about the second piece of code being shorter (I'm not aiming for APL-
or C-like oneliners :-]). It may well be, but that's not a priority.
The presence of a delimiter/prompt (orthogonal from a
continuation-generator like callcc or F) is IMHO a better gain than
either conciseness or even efficiency alone would be.
Of course, the code could be (as has already been) written using only
callcc or F, but P abstracts away a convoluted style of delimiting,
not unlike the way callcc abstracts away the convoluted style of
passing continuations as arguments in the non-callcc version.
--dorai
--
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------dorai@helma.rice.edu (Dorai Sitaram) (03/22/90)
In article <5855@brazos.Rice.edu> dorai@hedera.rice.edu (Dorai Sitaram) writes: >$The efficiency issue is not clear. It all depends on the exact >$implementation of call-with-current-continuation. If the >$continuations share structure (as they do in some implementationts), >$the solution based on F is no more time or space efficient. >$ >$Note also that your version is shorter because you have moved some of >$the code to the use point (by inserting "prompts"). > >Hi, I'll take the liberty of answering you on the net too, for >purposes of clarification. This will not prevent the following from While I took the questionable liberty of quoting the $'d email above, I neglected to say who it was from. It's from Guillermo J. Rozas, MIT. My apologies to Guillermo. *** About Rice's Scheme88 which I earlier mentioned was available via anonymous ftp: It derives from Indiana's Scheme84, and was written predominantly by John Greiner (jg@..., currently at CMU) in Ibuki CommonLisp. It is now mostly maintained by Steve Weeks (weeks@rice), Rice. Questions may be directed to either of them. (I'm sure they won't mind :-].) Once again, the ftp address is titan.rice.edu, _not_ rice.edu, and the file to get is public/scheme88.sh . --dorai -- ------------------------------------------------------------------------------- It may be that the gulfs will wash us down; It may be we shall touch the Happy Isles. -------------------------------------------------------------------------------
jdg@gs2.sp.cs.cmu.edu (John Greiner) (03/22/90)
In article <5944@brazos.Rice.edu> dorai@helma.rice.edu (Dorai Sitaram) writes: >About Rice's Scheme88 which I earlier mentioned was available via >anonymous ftp: It derives from Indiana's Scheme84, and was written >predominantly by John Greiner (jg@..., currently at CMU) in Ibuki >CommonLisp. It is now mostly maintained by Steve Weeks (weeks@rice), >Rice. Questions may be directed to either of them. (I'm sure they >won't mind :-].) > >Once again, the ftp address is titan.rice.edu, _not_ rice.edu, and the >file to get is public/scheme88.sh . > >--dorai That's jdg@cs.cmu.edu, dorai. Unfortunately, Scheme88 uses some IBUKI CL specific functions. I'm in the slow process of figuring out what changes are necessary in the code for some other dialects. If you have any problems in porting it, I can tell you what needs to be changed and why, but not necessarily to what. BTW, Scheme88 is _almost_ R^3S compatible. jg