home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.functional
- Path: sparky!uunet!decwrl!purdue!yuma!rro
- From: rro@CS.ColoState.EDU (Rod Oldehoeft)
- Subject: Re: Is efficient backtracking feasible in functional languages?
- Originator: rro@CS.ColoState.EDU
- Sender: news@yuma.ACNS.ColoState.EDU (News Account)
- Message-ID: <Nov12.234528.87342@yuma.ACNS.ColoState.EDU>
- Date: Thu, 12 Nov 1992 23:45:28 GMT
- Reply-To: rro@cs.ColoState.EDU
- References: <TMB.92Nov12122350@arolla.idiap.ch> <1992Nov12.162725.25836@cs.yale.edu> <BxM80r.1Hu@dcs.glasgow.ac.uk>
- Nntp-Posting-Host: debussy.cs.colostate.edu
- Organization: Colorado State University
- Keywords: lazy backtracking Gofer
- Lines: 35
-
-
- In article <BxM80r.1Hu@dcs.glasgow.ac.uk>, kh@dcs.glasgow.ac.uk (Kevin Hammond) writes:
-
- Stuff deleted.
-
- |>
- |> Most functional language implementations that I know in detail (strict
- |> or non-strict) have, or have had, significant space-leak problems.
-
- In our SISAL implementation, finding a space leak was finding a bug,
- which got fixed, always.
-
- |>
- |> To reiterate the point, this is an *implementation* issue, NOT a
- |> language issue. For what it's worth, the new Glasgow Haskell compiler
- |> has no problem with strangesucc 10000000. It always "black-holes"
- |> entered closures, and should never retain dead values on the stack.
- |>
-
- Agreed that implementors, not language designers, cause these errors.
- However, an option that allows faster execution when the user knows
- not recovering storage is not going to matter shouldn't be classified
- as a space leak. It's also stupid to recover space when leaving scope
- towards program termination.
-
- --
- |--------------------------------------------------------------|
- | Rod Oldehoeft Email: rro@cs.colostate.edu |
- | Computer Science Department Voice: 303/491-5792 |
- | Colorado State University Fax: 303/491-6639 |
- | Fort Collins, CO 80523 |
- |--------------------------------------------------------------|
- | I pay the price, but do not count the cost. |
- | John Barth, "The Tidewater Tales" |
- |--------------------------------------------------------------|
-