Re: Making a function "forget" a variable

Our messages crossed, just saw this...

Spiros Bousbouras wrote:
On 19 Mar, 01:36, Ken Tilton <kennytil...@xxxxxxxxxxxxx> wrote:

Spiros Bousbouras wrote:

Assume I have 2 functions foo1 and foo2 which will be
defined in some lexical environment which contains the
variables v1 and v2. I want foo1 to know about v1 but not v2
and foo2 to know about v2 but not v1. What I mean by "not
know" is that if I were inadvertedly to use v2 inside foo1
for example I would get an error.

Here's an example of the kind of thing I have in mind:

(defun bar (...)
(let ((v1 value1) (v2 value2))
some-code
(defun foo1 (...)
more-code)
(defun foo2 (...)
yet-more-code)
code-again))

Variable v1 must be shared between bar and foo1 and
variable v2 must be shared between bar and foo2.

So how do I achieve this ?

You are worried about using a variable *by mistake*?! And you want the
language to miraculously prevent you from doing so?!


Not miraculously , the idea was that I would somehow inform
the compiler that an occurrence of a variable in a certain
scope would be by mistake.

Well I was thinking miraculous because you seemed to understand lexical scope, both that it existed and it was useful, and so probably also that it is ineluctable.

But then (declare (ignore ...)) seems to be what you are looking for, so I guess you are all set.




Tilton's Law of Programming says "Solve the real problem." If you can't
keep your variables straight, the real problem is that you have named
them too closely. Solution: give them farther apart names.


Has it not ever happened to you that you meant to write
one thing and you ended up writing another ?

Very rarely and then usually because I did get lazy and name things too closely, such as elephant-x and elephant-y, so I do not look for language tricks just because I am lazy because if I am lazy I sure do not have the energy to write a closure and then studiously create just the right (declare (ignore)).

Even if I were more energetic, I would not incur this cost on the authoring of every closure I ever authored just for the one time I will reference the wrong closed-over var.

As I said in the other response, that is the kind of trade-off the static typing crowd likes and likes to claim is vital to building good software. Lispers do not see the gain in reliability but do see the loss in expressiveness and productivity when one starts looking over ones shoulder at everything one does.

kenny

--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/

"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
.

Relevant Pages

  • Re: setq givs a warning i SBCL, Not CLISP
    ... Allegro 8 says that the function returned is a closure. ... (because a closure with a null lexical environment is perfectly legal, ... it implies that specials are dynamic and not lexical. ... declaration to the contrary (which implies that the special binding is ...
    (comp.lang.lisp)
  • Re: A question (confusion) about closure
    ... I have a confusion regarding closure and its definition. ... When a function refers to a variable defined outside it, ... lexical environment n. ... bindings whose names have lexical scope. ...
    (comp.lang.lisp)
  • Re: Confusion about closures
    ... var firstNameValue = { ... Via saved lexical environment a function finds its free variables. ... So answering your question, yes, this anonymous immediately invoked functional expression is a closure. ...
    (comp.lang.javascript)
  • Re: A question (confusion) about closure
    ... I have a confusion regarding closure and its definition. ... When a function refers to a variable defined outside it, ... lexical environment n. ... bindings whose names have lexical scope. ...
    (comp.lang.lisp)