Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!Germany.EU.net!EU.net!uunet!sytex!smcl
From: smcl@sytex.com (Scott McLoughlin)
Subject: Re: psetq vs. setq
Message-ID: <7a5Dwc1w165w@sytex.com>
Sender: bbs@sytex.com
Organization: Sytex Access Ltd.
References: <3b620p$8b0@tools.near.net>
Date: Sat, 26 Nov 1994 09:02:41 GMT
Lines: 40

barmar@nic.near.net (Barry Margolin) writes:

> In article <DF.94Nov24061350@pollux.acs.oakland.edu> df@pollux.acs.oakland.ed
> >   psetq adds additional constraints to the compiler, which may slow it down
> 
> >Wouldn't the same contraints affect LET the same way?
> 
> No, because LET and LET* differ in which *lexical* environment they use,
> not the dynamic environment (unless some of the variables being bound are
> special).  So the early bindings in a LET can be added to the new
> environment immediately, but subsequent initforms will not be evaluated in
> that environment, they'll be evaluated in the outer environment.

Howdy,
        I'd think that the relative costs of setq, psetq, let, let*
etc. would be highly dependent on both: the compiler/interpreter 
implementation and the Lisp code that used these forms.  Minus these
factors, it seems pretty hard to say much about the relative performance
of these special forms.
        Of course, in spite of Lisp being the ONE TRUE LANGUAGE, this is
one of the things that is REALLY ANNOYING about Lisp. Relating this to 
some recent postings about the role a "machine model" plays in a 
programmer's "head" when designing and implementing programs -- maybe
this would be better termed a "performance model".
        And to toss in my two (useless) bits on setq/psetq -- a kick
butt compiler might have to generate extra temporaries for psetq
that could slow down execution. If all such temporaries could be kept
in registers (not bloody likely on lots of machines) there might be
no penalty.  If any of the r-value forms are function calls, I could
imagine there also being little if any penalty for the possibly
defered updates. OTOH, one could picture an interpreter that handled
psetq in a manner that avoided redundancy in certain runtime checks/
behavior on variable access/update - like constantp and boundp 
checks, looking through some a-list for variable bindings, etc. Then
psetq could indeed be faster than setq. Go figure.

=============================================
Scott McLoughlin
Conscious Computing
=============================================
