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 ?
P� Tue, 18 Mar 2008 18:56:16 +0100, skrev Spiros Bousbouras
<······@gmail.com>:
> 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 ?
Have you considered using dynamic variables instead of lexical variables
to achieve this.
Then all you have to do is set the order.
(defun foo1 (...) (declare (special v1)) ...)
(defun foo2 (...) (declare (special v2)) ...)
(defun bar(...)
(let ((v1 value1)) (declare (special v1))
...
(foo1 ...)
...)
(let ((v2 value2)) (declare (special v2))
...
(foo2 ...)
...)
...)
When compiling foo1 and using v2 you get a 'warning: v2 assumed special)
You get a runtime error because it hasn't been defined yet.
Similarly with foo2 except here you get the error because v1 went out of
scope.
--------------
John Thingstad
Spiros Bousbouras <······@gmail.com> writes:
> 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.
Easiest: rebind the variable you want to mask:
(defun bar (...)
(let ((v1 value1)
(v2 value2))
some-code
(let (v2)
(defun foo1 (...)
more-code))
(let (v1)
(defun foo2 (...)
yet-more-code))
code-again))
> What I mean by "not
> know" is that if I were inadvertedly to use v2 inside foo1
> for example I would get an error.
Then you'll need a symbol-macrolet:
(defun bar (...)
(let ((v1 value1)
(v2 value2))
some-code
(symbol-macrolet ((v2 (error "Mustn't use v2 in foo1")))
(defun foo1 (...)
more-code))
(symbol-macrolet ((v1 (error "Mustn't use v1 in foo2")))
(defun foo2 (...)
yet-more-code))
code-again))
But the use of the variable will raise an error only at run-time.
Ok. The first problem with your code is that the function BAR
redefines a new foo1 and a new foo2 everytime it's called. This is
most probably NOT what you want. In any case, foo1 and foo2 are
perfectly visible from the outside. And since v1 and v2 are bound
inside BAR, next time BAR is executed, new variables will be created
and BAR won't have access to the v1 and v2 of the closures. Of course
it won't matter much since the closures are forgotten and recreated by
DEFUN.
I would do something like:
(let ((v1 100))
(defun foo1 ()
v1)
(defun bar-part1 (x)
(decf v1 x)))
(let ((v2 200))
(defun foo2 ()
v2)
(defun bar-part2 (x)
(incf v2 x)))
(defun bar ()
(list (bar-part1 2) (bar-part2 1) (foo1) (foo2)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
On Mar 18, 4:24 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> Spiros Bousbouras <······@gmail.com> writes:
> > 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.
>
> Then you'll need a symbol-macrolet:
>
> (defun bar (...)
> (let ((v1 value1)
> (v2 value2))
> some-code
> (symbol-macrolet ((v2 (error "Mustn't use v2 in foo1")))
> (defun foo1 (...)
> more-code))
> (symbol-macrolet ((v1 (error "Mustn't use v1 in foo2")))
> (defun foo2 (...)
> yet-more-code))
> code-again))
>
> But the use of the variable will raise an error only at run-time.
You can have the symbol-macro expand to a macro, and have that macro
signal an error at macroexpansion-time. To have the less surprising
behaviour of defaulting to v1 in the parent scope, you'd probably want
to gensym and symbol-macrolet to make the gensyms visible.
Paul Khuong
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 ?
Is this a joke question? As usual the other yobbos around here are
bending themselves into the most ridiculous shapes trying to give you
the nonsense for which you asked.
You are worried about using a variable *by mistake*?! And you want the
language to miraculously prevent you from doing so?! Never mind defuns,
how about just two branches of an if that both <gasp!> have lexical
access to v1 and v2? Omigod, save me! Save me!
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.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On 2008-03-18 21:36:42 -0400, Ken Tilton <···········@optonline.net> said:
> Is this a joke question? As usual the other yobbos around here are
> bending themselves into the most ridiculous shapes trying to give you
> the nonsense for which you asked.
gotta say, I'm having a difficult time seeing the point of this as
well. Maybe the OP could give us a useful real example (i.e., not
contrived foo v1 v2 stuff).
On 19 Mar, 05:36, Raffael Cavallaro <················@pas-d'espam-s'il-
vous-plait-mac.com> wrote:
> On 2008-03-18 21:36:42 -0400, Ken Tilton <···········@optonline.net> said:
>
> > Is this a joke question? As usual the other yobbos around here are
> > bending themselves into the most ridiculous shapes trying to give you
> > the nonsense for which you asked.
>
> gotta say, I'm having a difficult time seeing the point of this as
> well. Maybe the OP could give us a useful real example (i.e., not
> contrived foo v1 v2 stuff).
It's a perfectly serious question. As for real example
I don't have one ; it was a theoretical question. In
practice I would only be slightly worried of inadvertENtly
using a variable where it shouldn't occur. Nevertheless
having a way to make each function know only about the
variables it's supposed to be using and nothing more
satisfies me from an aesthetical point of view, adds a
little bit of safety, and leads to self-documenting code.
The "point" was curiosity as much as anything else.
Spiros Bousbouras wrote:
> On 19 Mar, 05:36, Raffael Cavallaro <················@pas-d'espam-s'il-
> vous-plait-mac.com> wrote:
>
>>On 2008-03-18 21:36:42 -0400, Ken Tilton <···········@optonline.net> said:
>>
>>
>>>Is this a joke question? As usual the other yobbos around here are
>>>bending themselves into the most ridiculous shapes trying to give you
>>>the nonsense for which you asked.
>>
>>gotta say, I'm having a difficult time seeing the point of this as
>>well. Maybe the OP could give us a useful real example (i.e., not
>>contrived foo v1 v2 stuff).
>
>
> It's a perfectly serious question. As for real example
> I don't have one ; it was a theoretical question. In
> practice I would only be slightly worried of inadvertENtly
> using a variable where it shouldn't occur. Nevertheless
> having a way to make each function know only about the
> variables it's supposed to be using and nothing more
> satisfies me from an aesthetical point of view, adds a
> little bit of safety, and leads to self-documenting code.
>
> The "point" was curiosity as much as anything else.
First of all, then, this is Lisp, we do not worry about safety.
Second, this gives me an error:
(defun xxx ()
(let ((x 42))
(lambda (n)
(declare (ignore x))
(* 2 n x))))
Third and left as an exercise, now you must find a way to make sure you
have listed in the ignore all the lexically visible names you wish to
make sure you do not accidentally reference, which is why (see first
reason).
Fourth, others vary on this, but for my money there are enough real
concerns in programming that mebbe next time you are counting angels on
the head of a pin you might warn us.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On 19 Mar, 17:51, Ken Tilton <···········@optonline.net> wrote:
> Spiros Bousbouras wrote:
> > It's a perfectly serious question. As for real example
> > I don't have one ; it was a theoretical question. In
> > practice I would only be slightly worried of inadvertENtly
> > using a variable where it shouldn't occur. Nevertheless
> > having a way to make each function know only about the
> > variables it's supposed to be using and nothing more
> > satisfies me from an aesthetical point of view, adds a
> > little bit of safety, and leads to self-documenting code.
>
> > The "point" was curiosity as much as anything else.
>
> First of all, then, this is Lisp, we do not worry about safety.
>
> Third and left as an exercise, now you must find a way to make sure you
> have listed in the ignore all the lexically visible names you wish to
> make sure you do not accidentally reference, which is why (see first
> reason).
I was assuming that a Lisp programme can be
organised in a such a way that one doesn't
have many variables in each lexical environment.
Apart from that the situation where you actually
want to ignore a name wouldn't arise very
often.
> Fourth, others vary on this, but for my money there are enough real
> concerns in programming that mebbe next time you are counting angels on
> the head of a pin you might warn us.
I don't consider my question counting angels and
the numerous answers with code I have seen indicate
that many others do not see it as counting angels
either. But since you bring up the topic I cannot
resist the temptation of mentioning that threads
on whether OSS is good or bad which you have a habit
of starting are most definitely "counting angels".
Same goes for threads on whether OSS is ethical and
threads Lisp vs. <other language>.
Spiros Bousbouras wrote:
> On 19 Mar, 17:51, Ken Tilton <···········@optonline.net> wrote:
>
>>Spiros Bousbouras wrote:
>>
>>>It's a perfectly serious question. As for real example
>>>I don't have one ; it was a theoretical question. In
>>>practice I would only be slightly worried of inadvertENtly
>>>using a variable where it shouldn't occur. Nevertheless
>>>having a way to make each function know only about the
>>>variables it's supposed to be using and nothing more
>>>satisfies me from an aesthetical point of view, adds a
>>>little bit of safety, and leads to self-documenting code.
>>
>>>The "point" was curiosity as much as anything else.
>>
>>First of all, then, this is Lisp, we do not worry about safety.
>>
>>Third and left as an exercise, now you must find a way to make sure you
>>have listed in the ignore all the lexically visible names you wish to
>>make sure you do not accidentally reference, which is why (see first
>>reason).
>
>
> I was assuming that a Lisp programme can be
> organised in a such a way that one doesn't
> have many variables in each lexical environment.
> Apart from that the situation where you actually
> want to ignore a name wouldn't arise very
> often.
Hmmm, we seem to be boxed into a very strange corner where there are not
too many lexicals to worry about having to declare all the ones we want
ignored ignored but enough that we have to worry about using the wrong
one and so will undertake a protective process not guaranteed to be any
less error prone -- ah, I see, what are the chances we'll get them
/both/ wrong -- and meanwhile never get around to writing any software.
Hmmm. I feel my Reinhom Messner analogy coming on.
>
>
>>Fourth, others vary on this, but for my money there are enough real
>>concerns in programming that mebbe next time you are counting angels on
>>the head of a pin you might warn us.
>
>
> I don't consider my question counting angels and
> the numerous answers with code I have seen indicate
> that many others do not see it as counting angels
> either. But since you bring up the topic I cannot
> resist the temptation of mentioning that threads
> on whether OSS is good or bad which you have a habit
> of starting are most definitely "counting angels".
Yikes! What a non-comparing comparison.
Anyway, my overall point stands: if you want to experiment with The Lisp
Roman Orgy Experience it might help not to look therein for the Java/C++
(how can I put this delicately....nope, better keep quiet) Experience.
Sorry for implying you were a troll, btw.
peace, kzo
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
In article
<····································@s37g2000prg.googlegroups.com>,
Spiros Bousbouras <······@gmail.com> wrote:
> On 19 Mar, 05:36, Raffael Cavallaro <················@pas-d'espam-s'il-
> vous-plait-mac.com> wrote:
> > On 2008-03-18 21:36:42 -0400, Ken Tilton <···········@optonline.net> said:
> >
> > > Is this a joke question? As usual the other yobbos around here are
> > > bending themselves into the most ridiculous shapes trying to give you
> > > the nonsense for which you asked.
> >
> > gotta say, I'm having a difficult time seeing the point of this as
> > well. Maybe the OP could give us a useful real example (i.e., not
> > contrived foo v1 v2 stuff).
>
> It's a perfectly serious question. As for real example
> I don't have one ; it was a theoretical question. In
> practice I would only be slightly worried of inadvertENtly
> using a variable where it shouldn't occur. Nevertheless
> having a way to make each function know only about the
> variables it's supposed to be using and nothing more
> satisfies me from an aesthetical point of view, adds a
> little bit of safety, and leads to self-documenting code.
>
> The "point" was curiosity as much as anything else.
As a general rule, Lisp doesn't provide too many features to protect
programmers from themselves. For example, many programmers think that
information hiding is an inherant feature of OO programming, which is
why most of them have methods "belonging" to classes (so that only they
can access the slots), but CLOS has none of that. Packages have public
and private symbols, but all you have to do to access private symbols is
type "::" -- most other languages enforce a strict barrier.
Lisp gives programmers plenty of rope with which to hang themselves at
the algorithmic level. We simply expect programmers to be smart enough
not to do that.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Spiros Bousbouras <······@gmail.com> writes:
> It's a perfectly serious question. As for real example
> I don't have one ; it was a theoretical question. In
> practice I would only be slightly worried of inadvertENtly
> using a variable where it shouldn't occur. Nevertheless
> having a way to make each function know only about the
> variables it's supposed to be using and nothing more
> satisfies me from an aesthetical point of view, adds a
> little bit of safety, and leads to self-documenting code.
Well, the simplest way to do this would be to actually pass those
variables in as function arguments. That's the traditional way to make
sure that functions don't use arguments they aren't supposed to.
I also find it a lot cleaner and easier to understand when the named
function definitions are not scattered randomly throughout the code, but
rather declared up front.
Also, If you don't have any free variables, then you don't have to worry
about whether things inadvertently leak in from the outside. So write
your functions like:
(defun bar (...)
(flet ((foo1 (... v1) more-code)
(foo2 (... v2) yet-more-code))
� (let ((v1 value1) (v2 value2))
� � some-code
� � code-again)))
--
Thomas A. Russ, USC/Information Sciences Institute
In article <···············@blackcat.isi.edu>,
···@sevak.isi.edu (Thomas A. Russ) wrote:
> Spiros Bousbouras <······@gmail.com> writes:
>
> > It's a perfectly serious question. As for real example
> > I don't have one ; it was a theoretical question. In
> > practice I would only be slightly worried of inadvertENtly
> > using a variable where it shouldn't occur. Nevertheless
> > having a way to make each function know only about the
> > variables it's supposed to be using and nothing more
> > satisfies me from an aesthetical point of view, adds a
> > little bit of safety, and leads to self-documenting code.
>
> Well, the simplest way to do this would be to actually pass those
> variables in as function arguments. That's the traditional way to make
> sure that functions don't use arguments they aren't supposed to.
Doesn't work if the function needs to update the variable.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <···············@blackcat.isi.edu>,
> ···@sevak.isi.edu (Thomas A. Russ) wrote:
>
>> Spiros Bousbouras <······@gmail.com> writes:
>>
>> > It's a perfectly serious question. As for real example
>> > I don't have one ; it was a theoretical question. In
>> > practice I would only be slightly worried of inadvertENtly
>> > using a variable where it shouldn't occur. Nevertheless
>> > having a way to make each function know only about the
>> > variables it's supposed to be using and nothing more
>> > satisfies me from an aesthetical point of view, adds a
>> > little bit of safety, and leads to self-documenting code.
>>
>> Well, the simplest way to do this would be to actually pass those
>> variables in as function arguments. That's the traditional way to make
>> sure that functions don't use arguments they aren't supposed to.
>
> Doesn't work if the function needs to update the variable.
Really?
(defmacro & (var)
(let ((m (gensym)) (v (gensym)))
`(lambda (,m &optional ,v)
(ecase ,m ((get) ,var) ((set) (setf ,var ,v))))))
(defun deref (locative) (funcall locative 'get )) ; sorry, I swaped the first
(defun (setf deref) (value locative) (funcall locative 'set value)) ; two argument in my other post.
(defun f1 (*v1)
(incf (deref *v1)))
(defun f2 (*v2)
(decf (deref *v2)))
(let ((v1 10) (v2 20))
(f1 (& v1))
(f2 (& v2))
(list v1 v2))
--> (11 19)
--
__Pascal Bourguignon__
In article <··············@pbourguignon.anevia.com>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Barry Margolin <······@alum.mit.edu> writes:
>
> > In article <···············@blackcat.isi.edu>,
> > ···@sevak.isi.edu (Thomas A. Russ) wrote:
> >
> >> Spiros Bousbouras <······@gmail.com> writes:
> >>
> >> > It's a perfectly serious question. As for real example
> >> > I don't have one ; it was a theoretical question. In
> >> > practice I would only be slightly worried of inadvertENtly
> >> > using a variable where it shouldn't occur. Nevertheless
> >> > having a way to make each function know only about the
> >> > variables it's supposed to be using and nothing more
> >> > satisfies me from an aesthetical point of view, adds a
> >> > little bit of safety, and leads to self-documenting code.
> >>
> >> Well, the simplest way to do this would be to actually pass those
> >> variables in as function arguments. That's the traditional way to make
> >> sure that functions don't use arguments they aren't supposed to.
> >
> > Doesn't work if the function needs to update the variable.
>
> Really?
While your technique is certainly cute, I hardly think it's what he
meant by "pass those variables in as function arguments".
>
> (defmacro & (var)
> (let ((m (gensym)) (v (gensym)))
> `(lambda (,m &optional ,v)
> (ecase ,m ((get) ,var) ((set) (setf ,var ,v))))))
> (defun deref (locative) (funcall locative 'get )) ; sorry,
> I swaped the first
> (defun (setf deref) (value locative) (funcall locative 'set value)) ; two
> argument in my other post.
>
> (defun f1 (*v1)
> (incf (deref *v1)))
>
> (defun f2 (*v2)
> (decf (deref *v2)))
>
> (let ((v1 10) (v2 20))
> (f1 (& v1))
> (f2 (& v2))
> (list v1 v2))
>
> --> (11 19)
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <··············@pbourguignon.anevia.com>,
> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>
>> Barry Margolin <······@alum.mit.edu> writes:
>>
>> > In article <···············@blackcat.isi.edu>,
>> > ···@sevak.isi.edu (Thomas A. Russ) wrote:
>> >
>> >> Spiros Bousbouras <······@gmail.com> writes:
>> >>
>> >> > It's a perfectly serious question. As for real example
>> >> > I don't have one ; it was a theoretical question. In
>> >> > practice I would only be slightly worried of inadvertENtly
>> >> > using a variable where it shouldn't occur. Nevertheless
>> >> > having a way to make each function know only about the
>> >> > variables it's supposed to be using and nothing more
>> >> > satisfies me from an aesthetical point of view, adds a
>> >> > little bit of safety, and leads to self-documenting code.
>> >>
>> >> Well, the simplest way to do this would be to actually pass those
>> >> variables in as function arguments. That's the traditional way to make
>> >> sure that functions don't use arguments they aren't supposed to.
>> >
>> > Doesn't work if the function needs to update the variable.
>>
>> Really?
>
> While your technique is certainly cute, I hardly think it's what he
> meant by "pass those variables in as function arguments".
That's exactly what's done in C. What would you call that if it was
written in C?
>> (defmacro & (var)
>> (let ((m (gensym)) (v (gensym)))
>> `(lambda (,m &optional ,v)
>> (ecase ,m ((get) ,var) ((set) (setf ,var ,v))))))
>> (defun deref (locative) (funcall locative 'get )) ; sorry,
>> I swaped the first
>> (defun (setf deref) (value locative) (funcall locative 'set value)) ; two
>> argument in my other post.
>>
>> (defun f1 (*v1)
>> (incf (deref *v1)))
>>
>> (defun f2 (*v2)
>> (decf (deref *v2)))
>>
>> (let ((v1 10) (v2 20))
>> (f1 (& v1))
>> (f2 (& v2))
>> (list v1 v2))
void f1(int *v1){
--(*v1);
}
void f2(int *v2){
++(*v2);
}
list_t* example(void){
int v1=10;
int v2=20;
f1(&v1);
f2(&v2);
return(list(v1,v2));
}
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Barry Margolin <······@alum.mit.edu> writes:
>
> > In article <··············@pbourguignon.anevia.com>,
> > ···@informatimago.com (Pascal J. Bourguignon) wrote:
> >
> >> Barry Margolin <······@alum.mit.edu> writes:
> >>
> >> > In article <···············@blackcat.isi.edu>,
> >> > ···@sevak.isi.edu (Thomas A. Russ) wrote:
> >> >
> >> >> Spiros Bousbouras <······@gmail.com> writes:
> >> >>
> >> >> > It's a perfectly serious question. As for real example
> >> >> > I don't have one ; it was a theoretical question. In
> >> >> > practice I would only be slightly worried of inadvertENtly
> >> >> > using a variable where it shouldn't occur. Nevertheless
> >> >> > having a way to make each function know only about the
> >> >> > variables it's supposed to be using and nothing more
> >> >> > satisfies me from an aesthetical point of view, adds a
> >> >> > little bit of safety, and leads to self-documenting code.
> >> >>
> >> >> Well, the simplest way to do this would be to actually pass those
> >> >> variables in as function arguments. That's the traditional way to make
> >> >> sure that functions don't use arguments they aren't supposed to.
> >> >
> >> > Doesn't work if the function needs to update the variable.
> >>
> >> Really?
> >
> > While your technique is certainly cute, I hardly think it's what he
> > meant by "pass those variables in as function arguments".
>
> That's exactly what's done in C. What would you call that if it was
> written in C?
I'd call it passing a pointer to a variable.
Passing a variable: foo(a);
Passing a pointer: foo(&a);
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> Barry Margolin <······@alum.mit.edu> writes:
>>
>> > In article <··············@pbourguignon.anevia.com>,
>> > ···@informatimago.com (Pascal J. Bourguignon) wrote:
>> >
>> >> Barry Margolin <······@alum.mit.edu> writes:
>> >> [...]
>> >> > Doesn't work if the function needs to update the variable.
>> >>
>> >> Really?
>> >
>> > While your technique is certainly cute, I hardly think it's what he
>> > meant by "pass those variables in as function arguments".
>>
>> That's exactly what's done in C. What would you call that if it was
>> written in C?
>
> I'd call it passing a pointer to a variable.
>
> Passing a variable: foo(a);
>
> Passing a pointer: foo(&a);
There is no pointer in lisp.
Technically, what I passed wasn't a pointer, but a closure.
Conceptually, both in C and in Lisp we passed a variable.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Barry Margolin <······@alum.mit.edu> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> >> Barry Margolin <······@alum.mit.edu> writes:
> >>
> >> > In article <··············@pbourguignon.anevia.com>,
> >> > ···@informatimago.com (Pascal J. Bourguignon) wrote:
> >> >
> >> >> Barry Margolin <······@alum.mit.edu> writes:
> >> >> [...]
> >> >> > Doesn't work if the function needs to update the variable.
> >> >>
> >> >> Really?
> >> >
> >> > While your technique is certainly cute, I hardly think it's what he
> >> > meant by "pass those variables in as function arguments".
> >>
> >> That's exactly what's done in C. What would you call that if it was
> >> written in C?
> >
> > I'd call it passing a pointer to a variable.
> >
> > Passing a variable: foo(a);
> >
> > Passing a pointer: foo(&a);
>
> There is no pointer in lisp.
> Technically, what I passed wasn't a pointer, but a closure.
>
> Conceptually, both in C and in Lisp we passed a variable.
The point is between passing by value and by reference. I'll bet tar
meant the former when he was making his recommendation. Tar, can you
confirm this?
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Mar 20, 11:55 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Barry Margolin <······@alum.mit.edu> writes:
> > In article <···············@blackcat.isi.edu>,
> > ····@sevak.isi.edu (Thomas A. Russ) wrote:
>
> >> Spiros Bousbouras <······@gmail.com> writes:
>
> >> > It's a perfectly serious question. As for real example
> >> > I don't have one ; it was a theoretical question. In
> >> > practice I would only be slightly worried of inadvertENtly
> >> > using a variable where it shouldn't occur. Nevertheless
> >> > having a way to make each function know only about the
> >> > variables it's supposed to be using and nothing more
> >> > satisfies me from an aesthetical point of view, adds a
> >> > little bit of safety, and leads to self-documenting code.
>
> >> Well, the simplest way to do this would be to actually pass those
> >> variables in as function arguments. That's the traditional way to make
> >> sure that functions don't use arguments they aren't supposed to.
>
> > Doesn't work if the function needs to update the variable.
>
> Really?
>
> (defmacro & (var)
> (let ((m (gensym)) (v (gensym)))
> `(lambda (,m &optional ,v)
> (ecase ,m ((get) ,var) ((set) (setf ,var ,v))))))
> (defun deref (locative) (funcall locative 'get )) ; sorry, I swaped the first
> (defun (setf deref) (value locative) (funcall locative 'set value)) ; two argument in my other post.
>
> (defun f1 (*v1)
> (incf (deref *v1)))
>
> (defun f2 (*v2)
> (decf (deref *v2)))
>
> (let ((v1 10) (v2 20))
> (f1 (& v1))
> (f2 (& v2))
> (list v1 v2))
>
> --> (11 19)
>
> --
> __Pascal Bourguignon__
Very cute. Locatives! I would just shorten DEREF and make it
(defun ^ (locative) (funcall locative 'get))
(defun (setf ^) (v locative) (funcall locative 'set v))
Shorter. Not C, but Pascal (not Costanza :) ).
Cheers
--
Marco
Marco Antoniotti wrote:
> On Mar 20, 11:55 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Barry Margolin <······@alum.mit.edu> writes:
>>> In article <···············@blackcat.isi.edu>,
>>> ····@sevak.isi.edu (Thomas A. Russ) wrote:
>>>> Spiros Bousbouras <······@gmail.com> writes:
>>>>> It's a perfectly serious question. As for real example
>>>>> I don't have one ; it was a theoretical question. In
>>>>> practice I would only be slightly worried of inadvertENtly
>>>>> using a variable where it shouldn't occur. Nevertheless
>>>>> having a way to make each function know only about the
>>>>> variables it's supposed to be using and nothing more
>>>>> satisfies me from an aesthetical point of view, adds a
>>>>> little bit of safety, and leads to self-documenting code.
>>>> Well, the simplest way to do this would be to actually pass those
>>>> variables in as function arguments. That's the traditional way to make
>>>> sure that functions don't use arguments they aren't supposed to.
>>> Doesn't work if the function needs to update the variable.
>> Really?
>>
>> (defmacro & (var)
>> (let ((m (gensym)) (v (gensym)))
>> `(lambda (,m &optional ,v)
>> (ecase ,m ((get) ,var) ((set) (setf ,var ,v))))))
>> (defun deref (locative) (funcall locative 'get )) ; sorry, I swaped the first
>> (defun (setf deref) (value locative) (funcall locative 'set value)) ; two argument in my other post.
>>
>> (defun f1 (*v1)
>> (incf (deref *v1)))
>>
>> (defun f2 (*v2)
>> (decf (deref *v2)))
>>
>> (let ((v1 10) (v2 20))
>> (f1 (& v1))
>> (f2 (& v2))
>> (list v1 v2))
>>
>> --> (11 19)
>>
>> --
>> __Pascal Bourguignon__
>
> Very cute. Locatives! I would just shorten DEREF and make it
>
> (defun ^ (locative) (funcall locative 'get))
> (defun (setf ^) (v locative) (funcall locative 'set v))
What about leaving deref as it is, call the macro location-of (or so),
and introduce & and ^ as reader macros?
> Shorter. Not C, but Pascal (not Costanza :) ).
I get that quite often. :}
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 19 Mar, 23:59, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Spiros Bousbouras <······@gmail.com> writes:
> > It's a perfectly serious question. As for real example
> > I don't have one ; it was a theoretical question. In
> > practice I would only be slightly worried of inadvertENtly
> > using a variable where it shouldn't occur. Nevertheless
> > having a way to make each function know only about the
> > variables it's supposed to be using and nothing more
> > satisfies me from an aesthetical point of view, adds a
> > little bit of safety, and leads to self-documenting code.
>
> Well, the simplest way to do this would be to actually pass those
> variables in as function arguments. That's the traditional way to make
> sure that functions don't use arguments they aren't supposed to.
>
> I also find it a lot cleaner and easier to understand when the named
> function definitions are not scattered randomly throughout the code, but
> rather declared up front.
>
> Also, If you don't have any free variables, then you don't have to worry
> about whether things inadvertently leak in from the outside. So write
> your functions like:
>
> (defun bar (...)
> (flet ((foo1 (... v1) more-code)
> (foo2 (... v2) yet-more-code))
> (let ((v1 value1) (v2 value2))
> some-code
> code-again)))
I thought of that. What I don't like about this
approach is that it doesn't make it obvious that
foo1 and foo2 always get called with the same
arguments ; you'd have to inspect every call to
see that. On the other hand if foo1 refers to a
variable v1 which doesn't get "defined" inside
foo1 and is not an argument then you can
immediately tell that it comes from the environment.
Spiros Bousbouras <······@gmail.com> writes:
> On 19 Mar, 23:59, ····@sevak.isi.edu (Thomas A. Russ) wrote:
>> Spiros Bousbouras <······@gmail.com> writes:
>> > It's a perfectly serious question. As for real example
>> > I don't have one ; it was a theoretical question. In
>> > practice I would only be slightly worried of inadvertENtly
>> > using a variable where it shouldn't occur. Nevertheless
>> > having a way to make each function know only about the
>> > variables it's supposed to be using and nothing more
>> > satisfies me from an aesthetical point of view, adds a
>> > little bit of safety, and leads to self-documenting code.
>>
>> Well, the simplest way to do this would be to actually pass those
>> variables in as function arguments. �That's the traditional way to make
>> sure that functions don't use arguments they aren't supposed to.
>>
>> I also find it a lot cleaner and easier to understand when the named
>> function definitions are not scattered randomly throughout the code, but
>> rather declared up front.
>>
>> Also, If you don't have any free variables, then you don't have to worry
>> about whether things inadvertently leak in from the outside. �So write
>> your functions like:
>>
>> (defun bar (...)
>> � (flet ((foo1 (... �v1) more-code)
>> � � � � �(foo2 (... �v2) yet-more-code))
>> �� (let ((v1 value1) (v2 value2))
>> � � � some-code
>> � � � code-again)))
>
> I thought of that. What I don't like about this
> approach is that it doesn't make it obvious that
> foo1 and foo2 always get called with the same
> arguments ; you'd have to inspect every call to
> see that. On the other hand if foo1 refers to a
> variable v1 which doesn't get "defined" inside
> foo1 and is not an argument then you can
> immediately tell that it comes from the environment.
There are always ways to express what you mean:
(defun bar (...)
(flet ((foo1 (v1 ...) more-code)
(foo2 (v2 ...) yet-more-code))
(let ((v1 value1) (v2 value2))
(flet ((foo1 (...) (foo1 v1 ...))
(foo2 (...) (foo2 v2 ...)))
(foo2 ...) some-code (foo1 ...)
(foo1 ...) code-again (foo2 ...)))))
So while you still have to inspect ALL the calls to foo1 and foo2,
there are only one of each.
And I'd bet it would be more efficient to prepend arguments than to append them.
--
__Pascal Bourguignon__
P� Wed, 19 Mar 2008 02:36:42 +0100, skrev Ken Tilton
<···········@optonline.net>:
>
> Is this a joke question? As usual the other yobbos around here are
> bending themselves into the most ridiculous shapes trying to give you
> the nonsense for which you asked.
>
> You are worried about using a variable *by mistake*?! And you want the
> language to miraculously prevent you from doing so?! Never mind defuns,
> how about just two branches of an if that both <gasp!> have lexical
> access to v1 and v2? Omigod, save me! Save me!
>
> 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.
>
> kenny
>
lol.. Yeah this is something I would never contemplate. Still it was
interesting to see some of the solutions.
(I've never used symbol-macrolet.)
--------------
John Thingstad
On 19 Mar, 01:36, Ken Tilton <···········@optonline.net> 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.
> 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 ?
To the other posters: thank you for your replies. Being
fairly new to the language I will need to spend some
time looking up some of your constructs and then possibly
I will have more questions.
Our messages crossed, just saw this...
Spiros Bousbouras wrote:
> On 19 Mar, 01:36, Ken Tilton <···········@optonline.net> 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
On 19 Mar, 19:10, Ken Tilton <···········@optonline.net> wrote:
>
> Spiros Bousbouras wrote:
>
> >>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.
The ineluctable part I didn't know. And it's
not clear what you mean either since others
have suggested workarounds.
> But then (declare (ignore ...)) seems to be what you are looking for...
The jury seems to be out on this one for now.
> 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.
You have said no such thing in any other
response in this thread. This *is* actually
informative.
Spiros Bousbouras wrote:
> On 19 Mar, 19:10, Ken Tilton <···········@optonline.net> wrote:
>
>>Spiros Bousbouras wrote:
>>
>>
>>>>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.
>
>
> The ineluctable part I didn't know. And it's
> not clear what you mean either since others
> have suggested workarounds.
I think I acknowledged that:
> As usual the other yobbos around here are bending themselves into the
> most ridiculous shapes trying to give you the nonsense for which you asked.
When you know Lisp better you should come back and have a good laugh at
their non-working around workarounds. You need to understand that you
are dealing here mostly with Elizan Lispbots who will respond to any
request for functionality with the silliest code they will confess if
pressed they would never actually use, it's just instant parlor game
around here with any question like -- well, when I was growing up we had
a series of cracks about things being as useful as a screen door on a
submarine and before I finish this sentence someone will have posted the
blueprints. You get the idea.
>
>
>>But then (declare (ignore ...)) seems to be what you are looking for...
>
>
> The jury seems to be out on this one for now.
OK. Worked for me (to my surprise).
>>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.
>
>
> You have said no such thing in any other
> response in this thread.
I see two such things. First of all:
> And you want the language to miraculously prevent you from doing so?!
Second of all:
> First of all, then, this is Lisp, we do not worry about safety.
If you kennyexpand either of those you'll get the above paragraph.
> This *is* actually
> informative.
:( I was hoping I would get to tell the Reinhold Analogy again. Maybe
I'll blog it.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Spiros Bousbouras <······@gmail.com> writes:
> 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.
I think your best language construct would be the SYMBOL-MACROLET
approach.
I think the better approach is to not define things inside lexical
scopes where you don't want the scope to reach. Especially things like
the global functions that you evaluate at run-time.
> > 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 ?
Well, yes, but I would generally be driven crazy by any need to
carefully examine my code to figure out which lexical variables I don't
want to have visible somewhere inside the lexical scope of a binding.
Actually, phrased that way, it seems almost like a contradiction in
terms.
If you don't want a lexical variable visible, then define whatever-it-is
OUTSIDE the lexical scope of that variable.
Looking for all of the free variables that I want to use in the code, or
even trying to analyze that seems to be to be time I could better spend
just checking the code to make sure I didn't make the mistake in the
first place.
--
Thomas A. Russ, USC/Information Sciences Institute
On Mar 18, 10:56 am, Spiros Bousbouras <······@gmail.com> wrote:
> 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 ?
(let ((v1 42) (v2 43))
(declare (ignore v1))
;; now references to v1 should be diagnosed
)
Inside foo1, declare v2 ignored, and inside foo2, declare v1 ignored.
See, Lisp has an answer for everything, no matter how ill-conceived
may be the requirement.
Kaz Kylheku <········@gmail.com> writes:
> On Mar 18, 10:56�am, Spiros Bousbouras <······@gmail.com> wrote:
>> 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 ?
>
> (let ((v1 42) (v2 43))
> (declare (ignore v1))
> ;; now references to v1 should be diagnosed
> )
>
> Inside foo1, declare v2 ignored, and inside foo2, declare v1 ignored.
>
> See, Lisp has an answer for everything, no matter how ill-conceived
> may be the requirement.
Not really. Remember that we want to detect use of v2 in f1 and v1 in
f2. But in the let, both v1 and v2 will be used. If you declare
inside the functions, it doesn't work:
S/CL-USER[2]> (compile nil '(lambda ()
(let (v1 v2)
(defun f1 () (declare (ignore v1)) (list v1 v2))
(defun f2 () (declare (ignore v2)) (list v1 v2)))))
#<FUNCTION {10034BFDE9}>
NIL
NIL
No error, no warning...
--
__Pascal Bourguignon__
In article <··············@pbourguignon.anevia.com>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Kaz Kylheku <········@gmail.com> writes:
>
> > On Mar 18, 10:56�am, Spiros Bousbouras <······@gmail.com> wrote:
> >> 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 ?
> >
> > (let ((v1 42) (v2 43))
> > (declare (ignore v1))
> > ;; now references to v1 should be diagnosed
> > )
> >
> > Inside foo1, declare v2 ignored, and inside foo2, declare v1 ignored.
> >
> > See, Lisp has an answer for everything, no matter how ill-conceived
> > may be the requirement.
>
>
> Not really. Remember that we want to detect use of v2 in f1 and v1 in
> f2. But in the let, both v1 and v2 will be used. If you declare
> inside the functions, it doesn't work:
>
>
> S/CL-USER[2]> (compile nil '(lambda ()
> (let (v1 v2)
> (defun f1 () (declare (ignore v1)) (list v1 v2))
> (defun f2 () (declare (ignore v2)) (list v1 v2)))))
>
> #<FUNCTION {10034BFDE9}>
> NIL
> NIL
>
> No error, no warning...
Maybe this would work:
(let (v1 vs)
(locally (declare (ignore v1))
(defun f1 () (list v1 v2)))
(locally (declare (ignore v2))
(defun f2 () (list v1 v2))))
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <··············@pbourguignon.anevia.com>,
> ···@informatimago.com (Pascal J. Bourguignon) wrote:
>
>> Kaz Kylheku <········@gmail.com> writes:
>>
>> > On Mar 18, 10:56�am, Spiros Bousbouras <······@gmail.com> wrote:
>> >> 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 ?
>> >
>> > (let ((v1 42) (v2 43))
>> > (declare (ignore v1))
>> > ;; now references to v1 should be diagnosed
>> > )
>> >
>> > Inside foo1, declare v2 ignored, and inside foo2, declare v1 ignored.
>> >
>> > See, Lisp has an answer for everything, no matter how ill-conceived
>> > may be the requirement.
>>
>>
>> Not really. Remember that we want to detect use of v2 in f1 and v1 in
>> f2. But in the let, both v1 and v2 will be used. If you declare
>> inside the functions, it doesn't work:
>>
>>
>> S/CL-USER[2]> (compile nil '(lambda ()
>> (let (v1 v2)
>> (defun f1 () (declare (ignore v1)) (list v1 v2))
>> (defun f2 () (declare (ignore v2)) (list v1 v2)))))
>>
>> #<FUNCTION {10034BFDE9}>
>> NIL
>> NIL
>>
>> No error, no warning...
>
> Maybe this would work:
>
> (let (v1 vs)
> (locally (declare (ignore v1))
> (defun f1 () (list v1 v2)))
> (locally (declare (ignore v2))
> (defun f2 () (list v1 v2))))
This sounds better, but implementations that complain, complain about
declaring ignore a free variable, not about using an ignored variable.
Anyways, since we're speaking of closures, I'd mention another
solution, to prevent any error:
(defmacro & (var)
(let ((m (gensym)) (v (gensym)))
`(lambda (,m &optional ,v)
(ecase ,m ((get) ,var) ((set) (setf ,var ,v))))))
(defun deref (locative) (funcall 'get locative))
(defun (setf deref) (value locative) (funcall 'set locative value))
(defun f1 (*v1)
(setf (deref *v1) (do-something (deref *v1))))
(defun f2 (*v2)
(setf (deref *v2) (do-something (deref *v2))))
(let (v1 v2)
(f1 (& v1))
(f2 (& v2)))
This way, you clearly indicate what variable(s) of the closure each
function can use, and there's no risk of accidental use of the others.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."