home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / prolog / 1460 < prev    next >
Encoding:
Text File  |  1992-07-27  |  1.9 KB  |  42 lines
  1. Newsgroups: comp.lang.prolog
  2. Path: sparky!uunet!mcsun!sunic!sics.se!sics.se!matsc
  3. From: matsc@sics.se (Mats Carlsson)
  4. Subject: Re: Unsafe variables
  5. In-Reply-To: bimbart@cs.kuleuven.ac.be's message of Mon, 27 Jul 1992 06:55:51 GMT
  6. Message-ID: <1992Jul28.072501.6238@sics.se>
  7. Sender: news@sics.se
  8. Organization: Swedish Institute of Computer Science, Kista
  9. References: <1992Jul27.065551.3053@cs.kuleuven.ac.be>
  10. Date: Tue, 28 Jul 1992 07:25:01 GMT
  11. Lines: 29
  12.  
  13. In article <1992Jul27.065551.3053@cs.kuleuven.ac.be> bimbart@cs.kuleuven.ac.be (Bart Demoen) writes:
  14.  
  15.    [...]
  16.  
  17.    Two more remarks: I want to make a link with BinProlog (by the way, the
  18.    relation between BinProlog and BIMProlog as not the same as between Nu-Prolog
  19.    and Mu-Prolog !) or a continuation based implementation of Prolog:
  20.    continuations on the heap actually means also environments on the heap, so that
  21.    it in fact puts uninitialized 'permanent' variables on the heap. Still, it trails as
  22.    much as a WAM implementation with unsafe variables. And it is difficult to get rid
  23.    of the extra dereference every time the variable is accessed.
  24.  
  25. I don't know how other WAM based Prologs do it, but in SICStus Prolog,
  26. the compiler ensures that all permanent variables are initialized at
  27. the first 'call' instruction of every clause.  The variables are initialized
  28. by 'put_variable' if they are not otherwise initialized already.
  29.  
  30. This is done to prevent there from being random bit patterns in the
  31. permanent variables in the event of a garbage collection.  Some other
  32. changes to the instruction set are also necessary to prevent similar
  33. trouble in the event of garbage collection after backtracking.
  34.  
  35. I don't have any figures, but I suspect that variables created by this
  36. mechanism would significantly contribute to the heap growth if one
  37. gets rid of unsafe variables.
  38. --
  39. Mats Carlsson
  40. SICS, PO Box 1263, S-164 28  KISTA, Sweden    Internet: matsc@sics.se
  41. Tel: +46 8 7521543     Ttx: 812 6154 7010 SICS     Fax: +46 8 7517230
  42.