smalltalk-tng
view doc/Lisp3LexicalReflection @ 323:454c18798969
merger
| author | Tony Garnock-Jones <tonygarnockjones@gmail.com> |
|---|---|
| date | Tue Feb 07 11:34:20 2012 -0500 (3 months ago) |
| parents | |
| children |
line source
1 see comp.lang.scheme msg id 4596c2d8$0$68976$742ec2ed@news.sonic.net
2 "Re: let binding" by Ray Dillinger <bear@sonic.net>
4 ---------------------------------------------------------------------------
6 Pascal Costanza wrote:
7 > Jeffrey Mark Siskind wrote:
9 >>> What about good old reflection, like in 3-Lisp and languages
10 >>> influenced by 3-Lisp, like Brown, etc.?
12 >> I am not sufficiently familiar with 3-Lisp to answer this.
14 > Very roughly, 3-Lisp (and similar approaches) add an nlambda construct
15 > that is like lambda, but doesn't evaluate its arguments and gets passed
16 > a representation of the expression, the lexical environment in which the
17 > nlambda is called and the respective continuation. So, for example, you
18 > can implement an if statement with nlambda:
20 > (define if (nlambda (exp env cnt)
21 > (eval (cadr exp) env
22 > (lambda (res)
23 > (cond (res (eval (caddr exp) env cnt)
24 > (else (eval (cadddr exp) env cnt)))))))
26 I think before you can throw the above example around,
27 you have to discuss the extension of 'eval' you're
28 assuming. I see what it does, but I'm not who
29 you're trying to explain 3-lisp to.
31 (explanation for those unfamiliar: in addition to
32 the nlambda construct that Mr. Constanza is trying
33 to explain, the above code assumes a version of
34 'eval' that takes three arguments: an expression,
35 an environment, and a continuation. The expression
36 is evaluated in the environment, and then the
37 continuation is called. If the continuation doesn't
38 return, then the call to eval doesn't return.
39 Otherwise, it returns what the continuation returns.)
41 There's still a problem here, in that sometimes and
42 for some functions, you want to pass an argument along
43 to *other* functions, still unevaluated. When you
44 do so, this model causes you to implicitly pass your
45 current lexical environment rather than the one that
46 argument arrived with, and the expression form arrives
47 at the next function with a lexical environment that
48 isn't directly useful for evaluating the expression.
49 Rinse & repeat for however great a depth you want to
50 pass argument expressions lazily, and you get quite
51 a thorny thicket in which to code.
53 For a more general solution to the problem that nlambda
54 attempts to address, every unevaluated argument should
55 be some kind of entity from which the callee may
56 extract both the expression and that expression's own
57 lexical environment, which may be different from the
58 lexical environment of other expressions in the same
59 call.
61 > The IMHO best overview paper is "Control-Related Meta-Level Facilities
62 > in Lisp" by Jim des Rivieres (in Maes/Nardi, "Meta-Level Architectures
63 > and Reflection).
65 IMNSHO, the best overview paper is barely adequate. This
66 is memespace that's lying fallow right now because it is
67 outside the design space of all four of the surviving
68 major Lisp dialects, and learning this stuff from
69 overview papers without hands-on experience is like
70 trying to learn the geography and boulevards of Paris
71 from a map when you've never been there.
73 As long as it's lying fallow, we can't expect any advances
74 in the practice, and darn few in the theory, because
75 thousands of smart people just don't have their hands and
76 minds in it every day. All we can expect is the work of
77 several dozen or maybe a few hundred grad students, and
78 frankly less and less of that given that most Ph.D
79 committees see lambda as already pretty thoroughly explored.
81 > Since you get access to the arguments before they are evaluated, you can
82 > probably also transform them to the kinds of arguments that you actually
83 > need.
84 > It would probably be interesting to reflect on variable lookup as such -
85 > maybe slambda, similar to symbol macros in Common Lisp or R6RS Scheme -
86 > and values - maybe vlambda. (This doesn't exist, I am just speculating
87 > here...)
89 slambda is a trivial reduction in power from the
90 nlambda construct you mentioned before, easily
91 implementable simply as a restriction on its
92 argument set, and vlambda is already familiar as
93 the "normal" lambda-form in a call-by-value Lisp
94 such as Scheme. It is interesting to distinguish
95 a vlambda form in an otherwise-lazy lisp dialect,
96 but for the area of memespace people here/today
97 are knowledgeable about, the ability of nlambda
98 to handle lazy semantics is more interesting,
99 counterintuitive, or surprising.
101 >>> Or for that matter, what about implementing your own evaluator?
103 >> That in of itself doesn't allow nonstandard interpretations to be
104 >> first-class. Without the ability for changing the basis, you can't
105 >> compose nonstandard interpretations (potentially in different orders)
107 Here's the same point I explained above. Composing
108 nonstandard interpretations requires a lexical
109 environment to be passed with each *argument*, rather
110 than with each *call*. If you're passing an environment
111 with each *call*, it's properly the dynamic environment
112 rather than the lexical environment. When you pass an
113 "open" expression to an nlambda form, the system has to
114 "close" it, attaching the current lexical environment
115 When you pass an expression that's already closed, it
116 already has an environment attached, and it doesn't get
117 a new one. But your nlambda analogue needs to get all
118 the expressions in closed form, each with an environment
119 pointer attached. And your closed forms need to be a
120 data type with accessors that can separately extract
121 the expression and the lexical environment.
123 > Very interesting. The term "nonstandard interpretation" led me to
124 > believe that this is about interpreters (as in "The Art of the
125 > Interpreter" ;). But this seems to be quite related nevertheless...
127 Programming language interpreters are cases of the exact
128 same kind of interpretation he's talking about above.
129 In fact, programming mathematical interpretation is an
130 excellent way to find bugs in your math (although you
131 have to work past the bugs in your programming to be
132 sure of exactly what you've found).
134 But mostly they're much more loosely specified and have a
135 universe of discourse limited to representable values in
136 a particular machine's finite memory. On typical computer
137 approximations of the set of real numbers, not even
138 commutativity and associativity hold for addition or
139 multiplication, so it gets very hard to actually prove
140 anything.
142 Bear