home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3488 < prev    next >
Encoding:
Internet Message Format  |  1992-11-04  |  1.6 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!agate!doc.ic.ac.uk!uknet!mucs!m1!bevan
  2. From: bevan@cs.man.ac.uk (Stephen J Bevan)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: A challenge to the anti-goto
  5. Message-ID: <BEVAN.92Nov4204333@hippo.cs.man.ac.uk>
  6. Date: 4 Nov 92 20:43:33 GMT
  7. References: <PSM.92Nov3165530@soma.sics.se> <1992Nov3.165005.18037@midway.uchicago.edu>
  8.     <BEVAN.92Nov3211454@hippo.cs.man.ac.uk>
  9.     <Bx6z1J.57r@mentor.cc.purdue.edu>
  10. Sender: news@cs.man.ac.uk
  11. Organization: Department of Computer Science, University of Manchester
  12. Lines: 20
  13. In-reply-to: hrubin@pop.stat.purdue.edu's message of 4 Nov 92 12:36:55 GMT
  14.  
  15. In article <Bx6z1J.57r@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  16.  
  17.    [ you could use continuations ]
  18.  
  19.    There are two major problems with this.  For one, the stack grows with
  20.    the non-returns, and taking care of this would be at least as bad as
  21.    garbage collection, if not worse, as stack locations are, for extremely
  22.    good reasons, not globally known.  For another, this does not handle
  23.    procedures which continue the resource use of the current procedure.
  24.  
  25. If the whole thing is written using continuations, then the stack does
  26. not have to grow at all as each function has no "return" it only has a
  27. "goto next" call at the end.  As for using values in the current
  28. "procedure", pass them as parameters, the compiler _should_ notice
  29. that they are being used in a routine that is being "goto'd to" and so
  30. not actually push them on the stack or otherwise shuffle them about.
  31. If I had a (cooperative) Scheme compiler online I'd try this out to
  32. see what sort of code it produces, but I don't, so I can't :-<
  33.  
  34. bevan
  35.