DEFSTRUCT and lexical environment
in [Lisp]
|
From: vippstar on 18 Oct 2009 12:20 On Oct 18, 7:02 pm, Tim Bradshaw <t...(a)cley.com> wrote: > On 2009-10-18 13:40:38 +0100, Pascal Costanza <p...(a)p-cos.net> said: > > > Paul Graham uses the terms "macro argument capture" for what Ron > > describes as "inward capture", and "free symbol capture" for "outward > > capture" in his book "On Lisp". > > I much prefer Ron's terminology, as it resonates so well with downward > / upward funargs. I'd rather cite a book instead of a usenet post for my terminology though.
From: Kaz Kylheku on 18 Oct 2009 13:27 On 2009-10-17, Tim Bradshaw <tfb(a)cley.com> wrote: > On 2009-10-17 16:59:16 +0100, Ron Garret <rNOSPAMon(a)flownet.com> said: > >> I'm not sure, because this is not an example of capture. > > Yes, it's not. I think I was thinking of some alternative dialect of > Lisp where it would be though clearly not being coherent (I *think* > that I remember things in Cambridge Lisp, which was the first Lisp I > used, where things like this gave problems. > > I like your terminology though: i was thinking of upward & downward > (based on the funarg terminology) but that's not right because that was > based on stacks, and this is based on position in source. I don't think I will be able to remember which is which. These terms are inherently ambiguous, because every in has is its out! Does in refer the referencing direction or the binding direction? > So, I think: > > Inward capture is where something wraps itself around your code and > inserts names it should not into the scope of your code. This can be > resolved by just introducing such names. This could easily be called outward capture, because free references emanating outward from the code are intercepted. Moreover, that is always the case. It's some wrapper which steals the reference inside something that is wrapped! So even if we train ourselves to remember the direction, it doesn't help: > Outward capture is where something inserts code within the scope of > your code, and that code depends on names which your code may (or may > not) have introduced. Right, and that inserted makes references which emanate outward, but go to something in your code instead of where they should! So, outward capture, again! What is the /key/ difference between the captures? In both cases, there is user code, and a foreign mechanism (like a macro, but not necessarily) which may inserts invisible code into the situation. The difference is whether the invisible code introduces /references/ which interfere, or whether it introduces /definitions/ that interfere. If invisible naive references are inserted, this may lead to what you are calling inward capture. If invisible naive definitions are inserted, this may lead to outward capture. I propose: "naive ref capture" "naive def capture" In a context where it's clear we are discussing capture, we can drop the "capture". As in "your macro has an instance of naive ref". We need the "naive" because we already know the problem is some kind of capture, so if we drop "capture" and "naive", we are left with "ref" and "def", which are as useless as "inward" and "outward", since every capture involves both a ref and a def. The naive reminds us that it's the ref or def that is being bad, and we know that the ref or def is inside the macro because it's always the macro that is considered bad, never the site where it is used. How about that?
From: Don Geddis on 18 Oct 2009 14:57 Ron Garret <rNOSPAMon(a)flownet.com> wrote on Sun, 18 Oct 2009: > You can't choose to apply one standard to yourself and another to others. > (Unless you are a hypocrite. Are you a hypocrite?) If you're going to be a hypocrite, it's important to take it very seriously: http://www.penny-arcade.com/comic/2007/1/10/ _______________________________________________________________________________ Don Geddis http://don.geddis.org/ don(a)geddis.org Broccoli: When this is all over you're going to wish we had never met. The Customer: So not much will change. -- Goats.com, 9/1/2009
From: Madhu on 18 Oct 2009 20:48 * Tim Bradshaw <2009101816511275249-tfb(a)cleycom> : Wrote on Sun, 18 Oct 2009 16:51:12 +0100: | Yes, that''s why I didn't want to say "macro" - DEFSTRUCT obviously is | a macro, but it clearly is not relevant that it is, as it could | obviously (and I'm guessing everyone but Madhu thinks that it | obviously *should*) resolve any free references in the environment the | macro is defined. No, I think it should resolve the free references in the environment in which the form appears. The defstruct model indicates the form as appearing in a lambda list of a DEFUN MAKE-FOO which the defmacro defined. This MAKE-FOO is not constructed at the place where the initform is specified. The scoping rules and defaulting mechanisms for ordinary lambda lists in DEFUN are well specified. -- Madhu
From: Ron Garret on 18 Oct 2009 21:28
In article <87fx9gzg18.fsf(a)geddis.org>, Don Geddis <don(a)geddis.org> wrote: > Ron Garret <rNOSPAMon(a)flownet.com> wrote on Sun, 18 Oct 2009: > > You can't choose to apply one standard to yourself and another to others. > > (Unless you are a hypocrite. Are you a hypocrite?) > > If you're going to be a hypocrite, it's important to take it very seriously: > http://www.penny-arcade.com/comic/2007/1/10/ Unless you aspire to be a meta-hypocrite. Then you can be hypocritical about your hypocrisy. ;-) rg |