define-top-level-value
Damien R. Sullivan
to make more portable. The SWL (Chez's portable graphics) author suggested I
try DrScheme for better maintained graphics. So I set in on that today. But
the program makes heavy use of define-top-level-value, as in
(define-syntax slipnet-node-list*
(syntax-rules
(conceptual-depth:)
((slipnet-node-list* (n s conceptual-depth: d) ...)
(begin
(define-top-level-value 'n (make-slipnode 'n s d)) ...
(list n ...)))))
Inspired by the FAQ I tried making a fake:
(require (lib "defmacro.ss"))
(define-macro (define-top-level-value +name +value)
(eval `(define ,+name ,+value) (interaction-environment)))
which works a bit
(let ((x 4)) (define-top-level-value a (+ 3 4)))
but not very far
> (let ((x 4)) (define-top-level-value a (+ x 3)))
reference to undefined identifier: x
Is there a way out, or should I go back to SWL? If I have to largely rewrite
how the program works I'm probably jumping to Common Lisp.
-xx- Damien X-)
Jim Bender
(define-syntax define-top-level-value
(syntax-rules ()
((_ name val)
(namespace-set-variable-value! 'name val))))
I haven't tried this with slipnet-node-list*, but it works with the
other two examples. Actually, looking at the slipnet-node-list* macro,
if define-top-level-value is a function, rather than syntax, perhaps
it is (almost?) equivalent to namespace-set-variable-value! ???
Jim
"Damien R. Sullivan" <dasu...@cs.indiana.edu> wrote in message news:bgpngf$sa6$1...@hood.uits.indiana.edu...
Matthias Radestock
> I have a large Chez Scheme program using non-portable graphics, which I want
> to make more portable. The SWL (Chez's portable graphics) author suggested I
> try DrScheme for better maintained graphics. So I set in on that today. But
> the program makes heavy use of define-top-level-value, as in
> ...
> Inspired by the FAQ I tried making a fake:
> (require (lib "defmacro.ss"))
>
> (define-macro (define-top-level-value +name +value)
> (eval `(define ,+name ,+value) (interaction-environment)))
You didn't read the FAQ far enough :)
Try
(define-syntax define-top-level-value
(syntax-rules ()
((_ name value)
((eval '(begin (define name #f)
(lambda (val) (set! name val)))
(interaction-environment))
value))))
Unlike the solution Jim posted, which is PLT-specific, the above will
work in any R5RS-compliant Scheme that supports interaction-environment.
Matthias.
Michael Sperber
Matthias> Try
Matthias> (define-syntax define-top-level-value
Matthias> (syntax-rules ()
Matthias> ((_ name value)
Matthias> ((eval '(begin (define name #f)
Matthias> (lambda (val) (set! name val)))
Matthias> (interaction-environment))
Matthias> value))))
Matthias> Unlike the solution Jim posted, which is PLT-specific, the above will
Matthias> work in any R5RS-compliant Scheme that supports
Matthias> interaction-environment.
I don't think so.
First off, the "_" should be "define-top-level-value".
Next, from R5RS, Section 7.5
(eval expression environment-specifier) procedure
Evaluates expression in the specified environment and returns its
value. Expression must be a valid Scheme expression represented as
data, [...]
The argument to EVAL in the above code isn't an expression.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Matthias Radestock
> I don't think so.
>
> First off, the "_" should be "define-top-level-value".
Correct. easy to fix.
> The argument to EVAL in the above code isn't an expression.
Correct. I will update the FAQ.
Let me rephrase my original assertion
Matthias> Unlike the solution Jim posted, which is PLT-specific,
Matthias> the above will
Matthias> work in any R5RS-compliant Scheme that supports
Matthias> interaction-environment.
"Unlike the solution Jim posted, which is PLT-specific, the above will
work in any R5RS-compliant Scheme that support interaction-environment
and EVALuation of definitions. There are many Schemes that do." :-)
Matthias.
Gustavo Gomez
> I haven't tried this with slipnet-node-list*, but it works with the
> other two examples. Actually, looking at the slipnet-node-list* macro,
> if define-top-level-value is a function, rather than syntax, perhaps
> it is (almost?) equivalent to namespace-set-variable-value! ???
Chez's define-top-level-value *is* a function, so you are able to do
something like
> symbol
Error: variable symbol is not bound.
Type (debug) to enter the debugger.
> (define-top-level-value (cadr '(this symbol is now bound to 5))
(+ 2 3))
> symbol
5
So you can do
> (define define-top-level-value namespace-set-variable-value!)
Regarding the "is not portable" whine, the OP specifically asked for a
PLT solution, no?
-ggem.
Damien R. Sullivan
> > (define define-top-level-value namespace-set-variable-value!)
Thank you! Scheme is saved, at least until the next crisis.
>Regarding the "is not portable" whine, the OP specifically asked for a
>PLT solution, no?
Yeah, given the graphics Scheme portability's a laugh. Common Lisp has the
CLIM, but I'm trying to maximize the chance of being done by the end of the
month. (20,000 lines of Chez Scheme/SXM. Not the SXM on the web, an SXM from
Motorola 10 years ago.)
-xx- Damien X-)
Scott Miller
<finds dead horse, begins beating:>
Schemes on Java have portable graphics.
Scott
Damien R. Sullivan
><finds dead horse, begins beating:>
>Schemes on Java have portable graphics.
I appreciate the thought (and envy Java). But I'm doing computationally
greedy AI work, so I refuse to use anything which doesn't fully compile to
machine code. Part of me still suspects any Lisp is too dynamic, no matter
what people say about CL compilers, and that I should be using O'Caml (or
hell, C++ (urk)), but moving Scheme code into O'Caml is another risk I don't
want to bear.
As it happens, having solved the define-top-level-value problem (and a related
"set! doesn't set top level values" problem, solved with extra (define)s) I
ran into a "look, no record-case" problem. I saw someone's version of
record-case for PLT, but I'm thinking I should give up and just try to use
SWL, lest more little niggling things drag me down. Sigh.
-xx- Damien X-)
Jens Axel Søgaard
> As it happens, having solved the define-top-level-value problem (and a related
> "set! doesn't set top level values" problem, solved with extra (define)s) I
> ran into a "look, no record-case" problem. I saw someone's version of
> record-case for PLT, but I'm thinking I should give up and just try to use
> SWL, lest more little niggling things drag me down. Sigh.
I vaguely remember having seen a version of record-case written
by Dybvig as an example of syntax-case. But where?
--
Jens Axel Søgaard
Jim Bender
version requires a list of tags, not a single tag, at the head of a clause. This is to align with the specification of
record-case in the Chez manual.)
(define-syntax record-case
(lambda (x)
(syntax-case x (else)
((_ exp clause ...)
(not (identifier? (syntax exp)))
(syntax (let ((id exp))
(record-case id clause ...))))
((_ id (else exp ...)) (syntax (begin exp ...)))
((_ id (name-set fields exp ...) clause ...)
(syntax (if (memq (car id) 'name-set)
(apply (lambda fields exp ...) (cdr id))
(record-case id clause ...))))
((_ id) (syntax (error 'record-case "no clause matches: ~s" id))))))
Jim
"Jens Axel Søgaard" <use...@jasoegaard.dk> wrote in message news:3f318772$0$97256$edfa...@dread12.news.tele.dk...
Jens Axel Søgaard
> Damien R. Sullivan wrote:
>
>> As it happens, having solved the define-top-level-value problem (and a
>> related
>> "set! doesn't set top level values" problem, solved with extra
>> (define)s) I
>> ran into a "look, no record-case" problem. I saw someone's version of
>> record-case for PLT, but I'm thinking I should give up and just try to
>> use
>> SWL, lest more little niggling things drag me down. Sigh.
Have you tried this one?
<http://www.cs.uml.edu/~williams/courses/DPL/appendixa.ss>
--
Jens Axel Søgaard
Scott Miller
> Scott Miller <scgm...@freenetproject.org> wrote:
>
>
>><finds dead horse, begins beating:>
>>Schemes on Java have portable graphics.
>
>
> I appreciate the thought (and envy Java). But I'm doing computationally
> greedy AI work, so I refuse to use anything which doesn't fully compile to
> machine code. Part of me still suspects any Lisp is too dynamic, no matter
> what people say about CL compilers, and that I should be using O'Caml (or
> hell, C++ (urk)), but moving Scheme code into O'Caml is another risk I don't
> want to bear.
high performance, but that may be irrelevant. I would question whether
PLT is high performance enough in that case, but I'll defer to the more
knowledgeable.
Scott
Damien R. Sullivan
>Understood. One could argue that the graphics surely don't need to be
>high performance, but that may be irrelevant. I would question whether
AFAIK the graphics don't, they're just giving some insight into the thinking
of the program, and it's that thinking which I want to be fast. *How* to make
the program think is exactly the research program, which I take as part of the
justification for using a Lisp, despite any loss of speed that may or may not
incur.
>PLT is high performance enough in that case, but I'll defer to the more
>knowledgeable.
I had in fact dismissed it before for just that reason (people here saying it
wasn't that fast, compared to Chez or bigloo), turning back when the SWL guy
suggested it, tempted by the graphics; as I may have mentioned, I got a dumb
fibonacci in it to run decently fast, which was reassuring, even though it's
hardly all that informative.
By the way, I thank everyone who's contributed for their kind comments and
help.
-xx- Damien X-)
Scott G. Miller
> Scott Miller <scgm...@freenetproject.org> wrote:
>
>
>>Understood. One could argue that the graphics surely don't need to be
>>high performance, but that may be irrelevant. I would question whether
>
>
> AFAIK the graphics don't, they're just giving some insight into the thinking
> of the program, and it's that thinking which I want to be fast. *How* to make
> the program think is exactly the research program, which I take as part of the
> justification for using a Lisp, despite any loss of speed that may or may not
> incur.
Theres no reason you can't have both. Use a Scheme thats good for
graphics as a frontend to a Scheme thats fast at 'thinking'. This is
standard practice in a lot of software systems (separating UI from logic).
Scott
David Rush
>
> Matthias> Unlike the solution Jim posted, which is PLT-specific,
> Matthias> the above will
> Matthias> work in any R5RS-compliant Scheme that supports
> Matthias> interaction-environment.
>
> "Unlike the solution Jim posted, which is PLT-specific, the above will
> work in any R5RS-compliant Scheme that support interaction-environment
> and EVALuation of definitions. There are many Schemes that do." :-)
Err...There is no requirement that eval *alter* the
interaction-environment, so it still probably doesn't portably work
for OP.
david rush
--
He who would make his own liberty secure, must guard even his enemy
from repression
-- Thomas Paine
Matthias Radestock
> Err...There is no requirement that eval *alter* the
> interaction-environment,
I'd be interest to hear how you came to that conclusion. According to
R5RS, EVAL "evaluates expression in the specified environment and
returns its value". This would seem to imply that SET! and DEFINE
should alter/establish bindings in the specified environment. Further
evidence of that is the explicit prohibition for creating new bindings
in NULL-ENVIRONMENT and SCHEME-REPORT-ENVIRONMENT.
Matthias.
David Rush
<language-lawyer>
three reasons:
1 interaction-environment is *optional* under R5RS
2 (as referred to by Michael Sperber) R5RS 6.5:
Implementations may extend eval to allow non-expression programs
(definitions) as the first argument and to allow other
values as environments, with the restriction that eval is not
allowed to create new bindings in the environments associated with
null- environment or scheme-report-environment.
`may' does not mandate behavior in any standards-speak that I ever
heard. Nor is it the case that the restriction on null-environment and
scheme-report-environment mandates any mutability for
interaction-environment.
3 interaction-environment is inadequately defined
(define x 'foo)
(define env (interaction-environment))
(eval 'x env)
(define x 'bar)
(eval 'x env)
is one interesting scenario. another is
(define x 'foo)
(define env (interaction-environment))
(eval '(define x 'bar) env)
x
in neither of these cases does the R5RS language guarantee that the
final result is 'bar. Mind you, such behavior is *permitted* by the
R5RS language about eval and interaction-environment, it is just not
*guaranteed* - hence not (strictly) portable.
</language-lawyer>
It gets even weirder when you factor in the behavior of module
systems. It can then become very difficult to define just what
actually *is* bound in the interaction-environment.
Matthias Radestock
> 1 interaction-environment is *optional* under R5RS
>
> 2 (as referred to by Michael Sperber) R5RS 6.5:
>
> Implementations may extend eval to allow non-expression programs
> (definitions) as the first argument and to allow other
> values as environments, with the restriction that eval is not
> allowed to create new bindings in the environments associated with
> null- environment or scheme-report-environment.
>
> `may' does not mandate behavior in any standards-speak that I ever
> heard. Nor is it the case that the restriction on null-environment and
> scheme-report-environment mandates any mutability for
> interaction-environment.
I agree with all of these. See earlier posts, so nothing new there.
> 3 interaction-environment is inadequately defined
>
> (define x 'foo)
> (define env (interaction-environment))
> (eval 'x env)
> (define x 'bar)
> (eval 'x env)
I fail to see how a compliant Scheme could return anything other than
'foo and 'bar for the two EVALs above. The reason is that R5RS is pretty
clear what the interaction environment is supposed to be:
"this procedure will return the environment in which the implementation
would evaluate expressions dynamically typed by the user"
This makes it absolutely clear that EVAL in the INTERACTION-ENVIRONMENT
should see the same current top-level bindings as the REPL [What if
there is no REPL? Pass.]
> (define x 'foo)
> (define env (interaction-environment))
> (eval '(define x 'bar) env)
> x
For the same reason as above, any compliant Scheme that supports
EVALuation of definitions should return 'bar.
Matthias
be...@sonic.net
No, it doesn't. "the environment in which the implementation would
evaluate expressions dynamically typed" leaves open the question of
whether later mutations to the interaction environment side-effect
a variable whose value was set to that environment at an earlier
time. You are interpreting that as meaning a mutable object with an
eq? relationship to the interaction environment - But values are generally
nonmutable in scheme and the eq? relationship isn't specified.
Bear
Matthias Radestock
> Matthias Radestock wrote:
>>"this procedure will return the environment in which the implementation
>>would evaluate expressions dynamically typed by the user"
>>
>>This makes it absolutely clear that EVAL in the INTERACTION-ENVIRONMENT
>>should see the same current top-level bindings as the REPL [What if
>>there is no REPL? Pass.]
>
>
> No, it doesn't. "the environment in which the implementation would
> evaluate expressions dynamically typed" leaves open the question of
> whether later mutations to the interaction environment side-effect
> a variable whose value was set to that environment at an earlier
> time.
I disagree. R5RS talks about *the* interaction environment. Clearly if
there is only one it has to be mutable and therefore EVALuating
something in *the* interaction environment should affect the REPL
environment and vice versa.
I concede that the language in R5RS could make this more clear /
explicit, but this is hardly the only place in R5RS where that is the case.
Matthias.
Jens Axel Søgaard
>>> "this procedure will return the environment in which the implementation
>>> would evaluate expressions dynamically typed by the user"
>>>
>>> This makes it absolutely clear that EVAL in the INTERACTION-ENVIRONMENT
>>> should see the same current top-level bindings as the REPL [What if
>>> there is no REPL? Pass.]
>>
>> No, it doesn't. "the environment in which the implementation would
>> evaluate expressions dynamically typed" leaves open the question of
>> whether later mutations to the interaction environment side-effect a
>> variable whose value was set to that environment at an earlier time.
> I disagree. R5RS talks about *the* interaction environment. Clearly if
> there is only one it has to be mutable and therefore EVALuating
> something in *the* interaction environment should affect the REPL
> environment and vice versa.
Isn't eval underspecified by purpose?
This early proposal supports that idea (I haven't read the rest
of the archived discussion).
<http://zurich.ai.mit.edu/pipermail/rrrs-authors/1992-May/001307.html>
If that interpretation holds, then couldn't
"the environment in which the implementation would
evaluate expressions dynamically typed"
also mean the initial environment, the implementation starts in,
when a repl is started?
--
Jens Axel Søgaard
Anton van Straaten
> >> "this procedure will return the environment in which the implementation
> >> would evaluate expressions dynamically typed by the user"
> >>
> >>This makes it absolutely clear that EVAL in the INTERACTION-ENVIRONMENT
> >>should see the same current top-level bindings as the REPL [What if
> >>there is no REPL? Pass.]
> >
> >
> > No, it doesn't. "the environment in which the implementation would
> > evaluate expressions dynamically typed" leaves open the question of
> > whether later mutations to the interaction environment side-effect
> > a variable whose value was set to that environment at an earlier
> > time.
>
> I disagree. R5RS talks about *the* interaction environment. Clearly if
> there is only one it has to be mutable and therefore EVALuating
> something in *the* interaction environment should affect the REPL
> environment and vice versa.
So it depends on what the meaning of "the" is. Now *that's* language
lawyering! ;)
What about a purely functional implementation of Scheme, which passes the
current global environment around as a parameter? This would behave like a
mutable global environment, including at the REPL level, except in the
situation being discussed here. A saved reference to such an environment
would not be affected by subsequent "modification" of the environment.
In such an implementation, calling INTERACTION-ENVIRONMENT *does* return
"the environment in which the implementation would evaluate expressions
dynamically typed by the user". Rather than making a strong assumption
about the implications of "the", I think it's at least as reasonable to
assume that it's talking about "the" environment available at a point in
time, and saying nothing about whether that environment is mutable, or what
happens to that environment in future.
> I concede that the language in R5RS could make this more clear /
> explicit, but this is hardly the only place in R5RS where that is the
case.
R5RS is a subtly-disguised cross between a Chinese finger trap and a
Rorschach test...
Anton
Scott G. Miller
> Matthias Radestock wrote:
>>I disagree. R5RS talks about *the* interaction environment. Clearly if
>>there is only one it has to be mutable and therefore EVALuating
>>something in *the* interaction environment should affect the REPL
>>environment and vice versa.
>
>
> So it depends on what the meaning of "the" is. Now *that's* language
> lawyering! ;)
>
> What about a purely functional implementation of Scheme, which passes the
> current global environment around as a parameter? This would behave like a
> mutable global environment, including at the REPL level, except in the
> situation being discussed here. A saved reference to such an environment
> would not be affected by subsequent "modification" of the environment.
Ah, but one could easily argue that said implementation calls the next
read in the read-eval-print-loop with the functionally-updated
interaction environment. It would similarly do so when presented with a
set! by the user at the REPL prompt. It could certainly do either.
Scott
Anton van Straaten
> Anton van Straaten wrote:
> > What about a purely functional implementation of Scheme, which passes
the
> > current global environment around as a parameter? This would behave
like a
> > mutable global environment, including at the REPL level, except in the
> > situation being discussed here. A saved reference to such an
environment
> > would not be affected by subsequent "modification" of the environment.
>
> Ah, but one could easily argue that said implementation calls the next
> read in the read-eval-print-loop with the functionally-updated
> interaction environment. It would similarly do so when presented with a
> set! by the user at the REPL prompt. It could certainly do either.
I'm guessing I may not have given enough context in my post to make clear
what I meant. Even if the REPL did what you suggest, any saved reference to
the interaction environment, as in the example that Matthias R. gave, would
not be updated as the REPL continued looping. The code given was as
follows:
> (define x 'foo)
> (define env (interaction-environment))
> (eval 'x env)
> (define x 'bar)
> (eval 'x env)
After 'env' is defined, subsequent loops of the REPL will have a new
functionally-updated environment, but that would not affect the value of
'env'. Unless I'm missing something, to make it work otherwise, any time
the environment is mutated or extended, you'd also have to update all saved
references to the environment, to point to the new environment. While that
*would* simulate the behavior of a single mutable environment, it seems like
a perverse requirement to me. In the sort of functional interpreter I have
in mind, you'd simply have to use code like this:
(define x 'foo)
(eval 'x (interaction-environment))
(define x 'bar)
(eval 'x (interaction-environment))
...if you wanted to perform multiple evals in the same environment.
Anton
Alcibiades Petrofsky
> >>>>> "Matthias" == Matthias Radestock <matt...@sorted.org> writes:
> Matthias> (define-syntax define-top-level-value
> Matthias> (syntax-rules ()
> Matthias> ((_ name value)
> Matthias> ((eval '(begin (define name #f)
> Matthias> (lambda (val) (set! name val)))
> Matthias> (interaction-environment))
> Matthias> value))))
>
> Matthias> Unlike the solution Jim posted, which is PLT-specific, the
> Matthias> above will work in any R5RS-compliant Scheme that supports
> Matthias> interaction-environment.
>
> I don't think so.
>
> First off, the "_" should be "define-top-level-value".
One might as well insist that the "_" should be
"I-am-the-fairest-in-the-land". R5rs explicitly requires in section
4.3.2 that the name of this identifier be ignored:
The keyword at the beginning of the pattern in a <syntax rule> is
not involved in the matching and is not considered a pattern
variable or literal identifier.
-al
Aloe Vera Petrofsky
> interaction-environment is inadequately defined
>
> (define x 'foo)
> (define env (interaction-environment))
> (eval 'x env)
> (define x 'bar)
> (eval 'x env)
>
> is one interesting scenario. another is
>
> (define x 'foo)
> (define env (interaction-environment))
> (eval '(define x 'bar) env)
> x
In both of these scenarios, the (define x 'bar) is a redefinition. In
r5rs, redefinitions are merely assignments. Assignments do not modify
environments, they modify locations in the store. An environment is
simply a function mapping variable names to locations. Before and
after a (set! x 'bar) expression is evaluated, the environment in which
it is evaluated will map X to the same location.
Relevant portion of r5rs 3.1:
An identifier that names a location is called a variable and is
said to be bound to that location. The set of all visible bindings
in effect at some point in a program is known as the environment in
effect at that point.
So your scenarios are essentially equivalent to these scenarios:
(define x (list 'foo))
(define env (interaction-environment))
(car (eval 'x env))
(set-car! x 'bar)
(car (eval 'x env))
(define x (list 'foo))
(define env (interaction-environment))
(eval '(set-car! x 'bar) env)
(car x)
In systems that support interaction-environment and EVALed
definitions, the CAR expressions in these programs should evaluate to
BAR.
-al
Anton van Straaten
> Even if the REPL did what you suggest, any saved reference to
> the interaction environment, as in the example that Matthias R.
> continued looping.
...but Aloe Vera Petrofsky has exposed a flaw in the example being used,
which is that since the environment is not being extended by (define x 'bar)
in the example, the mutability, or lack thereof, of the saved environment is
moot. (Maybe that's what Scott was getting at?)
The behavior I was talking about would still apply to the following code:
(define x 'foo)
(define env (interaction-environment))
(eval 'x env) ; => foo
(define y 'bar)
(eval 'y env)
In a Scheme with a single mutating interaction-environment, the last line
would return 'bar. But in a purely functional Scheme implementation, 'y'
would not normally be present in the environment saved in 'env', so the last
line should generate an error.
I still think the R5RS language for INTERACTION-ENVIRONMENT, "this procedure
will return the environment in which the implementation would evaluate
expressions dynamically typed by the user", should be interpreted to allow
for an immutable environment to be returned.
Anton
Scott Miller
> Scott G. Miller wrote:
>
> I'm guessing I may not have given enough context in my post to make clear
> what I meant. Even if the REPL did what you suggest, any saved reference to
> the interaction environment, as in the example that Matthias R. gave, would
> not be updated as the REPL continued looping. The code given was as
> follows:
>
>
>> (define x 'foo)
>> (define env (interaction-environment))
>> (eval 'x env)
>> (define x 'bar)
>> (eval 'x env)
>
>
> After 'env' is defined, subsequent loops of the REPL will have a new
> functionally-updated environment, but that would not affect the value of
> 'env'.
Sorry, I overlooked the assignment to env.
> Unless I'm missing something, to make it work otherwise, any time
> the environment is mutated or extended, you'd also have to update all saved
> references to the environment, to point to the new environment. While that
> *would* simulate the behavior of a single mutable environment, it seems like
> a perverse requirement to me. In the sort of functional interpreter I have
> in mind, you'd simply have to use code like this:
>
> (define x 'foo)
> (eval 'x (interaction-environment))
> (define x 'bar)
> (eval 'x (interaction-environment))
>
> ...if you wanted to perform multiple evals in the same environment.
>
Of course. I was actually thinking of a sequence like this when I wrote
the last message:
(define x 'foo)
(eval 'x (interaction-environment))
(eval '(define x 'bar) (interaction-environment))
(eval 'x (interaction-environment))
(define x 'baz)
The third statement would alter x in the global environment by
functionally altering the environment as in any define statement, by
passing the new environment to a hypothetical repl procedure. As you
point out, this wouldn't work if the env is bound without a bogus env
accounting system.
Scott
Scott Miller
> I wrote:
>
>>Even if the REPL did what you suggest, any saved reference to
>>the interaction environment, as in the example that Matthias R.
>>[actually David R.] gave, would not be updated as the REPL
>>continued looping.
>
>
> ...but Aloe Vera Petrofsky has exposed a flaw in the example being used,
> which is that since the environment is not being extended by (define x 'bar)
> in the example, the mutability, or lack thereof, of the saved environment is
> moot. (Maybe that's what Scott was getting at?)
Sadly, no. I was just trying to point out that an eval supporting
definition could work even in a system with a functional global environment.
> I still think the R5RS language for INTERACTION-ENVIRONMENT, "this procedure
> will return the environment in which the implementation would evaluate
> expressions dynamically typed by the user", should be interpreted to allow
> for an immutable environment to be returned.
There doesn't appear to be anything precluding that interpretation, but
it would directly conflict with the optional eval of definition
behavior, "Implementations may extend `eval' to allow non-expression
programs (definitions) as the first argument ...". Not that it matters,
since its optional.
The real rub is that assignments are expressions, so it would violate
the spirit of eval (imho) to make an exception for assignments.
Unfortunately this is a yet another case where we're having to read into
what the spec doesn't say.
Scott
Anton van Straaten
> Anton van Straaten wrote:
> > I still think the R5RS language for INTERACTION-ENVIRONMENT, "this
procedure
> > will return the environment in which the implementation would evaluate
> > expressions dynamically typed by the user", should be interpreted to
allow
> > for an immutable environment to be returned.
>
> There doesn't appear to be anything precluding that interpretation, but
> it would directly conflict with the optional eval of definition
> behavior, "Implementations may extend `eval' to allow non-expression
> programs (definitions) as the first argument ...". Not that it matters,
> since its optional.
How about this: since definitions have no defined return value, would it be
valid for a definition to return an updated environment? Then, the result
of eval'ing a series of definitions would be an environment containing those
definitions, which could be used in a subsequent eval. OK, I might be
stretching a little here. However, if I'm thinking straight, this would
make it possible to implement a REPL, using eval, in a purely functional
Scheme implementation, which otherwise might be tricky.
Alternatively, I'll fall back to saying maybe that's *why* this is optional,
i.e. to allow purely functional implementations. ;)
> The real rub is that assignments are expressions, so it would violate
> the spirit of eval (imho) to make an exception for assignments.
> Unfortunately this is a yet another case where we're having to read into
> what the spec doesn't say.
I'm not sure what you mean?
Although eval of definitions may be a problem for a purely functional
implementation, assignments should, as Al O'Vera pointed out, work because
they update the current store, not the passed-in environment.
Unrelated to the above, I'll play devil's advocate w.r.t. to my own
position:
The R5RS formal semantics makes no provision for a global environment -
presumably, this is considered to be outside the scope of the formal
semantics. However, a formal description of a Scheme which was implemented
purely functionally would require a global environment parameter to be added
to almost all of the functions in the semantics. Requiring such a change to
the core semantics could imply a violation of R5RS. This interpretation
would preclude a compliant purely functional implementation of Scheme. That
is, unless there's some other purely functional way to implement a global
environment, but I can't think of one - even clever monadic tricks would
require some changes to the core semantics.
Back on the side of the angels, my rebuttal of the above is that the formal
semantics leave out the global environment because, like the semantic
function curly-K, "an accurate definition ... would complicate the semantics
without being very interesting". In addition, real implementations are
certain to implement a single mutating global environment, which is firmly
outside the scope of the formal semantics. Finally, since a global
environment parameter could be added to the semantics without affecting any
other characteristics, it would not in fact violate R5RS. (In support of
this, some of the denotational definitions of Scheme subsets in Lisp in
Small Pieces have a global environment parameter, iirc.)
All in all, though, my best argument is that I think it would be a pity if
it were not possible to create a fully compliant, purely functional
implementation of Scheme.
Anton
P.S. If anyone knows of a good Schemeaholics Anonymous group where I can get
help for my habit, which apparently now includes arguing with myself about
vanishingly fine points of Scheme semantics, please let me know...
ol...@pobox.com
> (define-syntax define-top-level-value
> (syntax-rules ()
> ((_ name value)
> ((eval '(begin (define name #f)
> value))))
> "Unlike the solution Jim posted, which is PLT-specific, the above will
> work in any R5RS-compliant Scheme that support interaction-environment
> and EVALuation of definitions. There are many Schemes that do."
I have reservations about that statement. Support for
interaction-environment and EVALuation of definitions does not imply
that the above technique will work. The code above may have different
results even on the same Scheme system -- depending on whether the
code is compiled or interpreted.
R5RS says:
[[optional procedure]] (interaction-environment)
This procedure returns a specifier for the environment that contains
implementation-defined bindings, typically a superset of those listed
in the report. The intent is that this procedure will return the
environment in which the implementation would evaluate expressions
dynamically typed by the user.
Nothing in that passage says that the environment denoted by the
(interaction-environment) includes all or any of the bindings from the
user code. R5RS leaves it to an implementation to decide which
bindings to include in the interaction environment.
Let us consider the following Bigloo code (please disregard the
(module) expression. It is needed for compilation)
/tmp> cat b.scm
(module aaa)
(define x 1)
(display (eval 'x (interaction-environment)))
(newline)
/tmp> bigloo -i b.scm # interpretation
1
/tmp> bigloo b.scm # compile the code
b.scm:
/tmp> ./a.out
*** ERROR:bigloo:eval:
Unbound variable -- x
Here's a more insidious example:
/tmp> cat b.scm
(module aaa)
(define x 1)
(eval '(define x 2) (interaction-environment))
(display x)
(newline)
(display (eval 'x (interaction-environment)))
(newline)
/tmp> bigloo -i b.scm
File "b.scm", line 3, character 34:
#(eval '(define x 2) (interaction-environment))
# ^
# *** WARNING:bigloo:eval
redefinition of variable -- x
2
2
Now, Bigloo explicitly warns of re-definition.
Let us compile the same code
/tmp> bigloo b.scm
b.scm:
/tmp> ./a.out
1
2
There is no redefinition here. As you see, the binding of x in the
main program and the binding of x in the interaction environment are
completely independent -- in full compliance with R5RS. In Bigloo, if
we want to share a binding between compiled and interpreted code, we
must specifically describe that binding in the module
statement. Furthermore, if we want to mutate that binding in the
interpreted code, we must mention that fact in the module statement as
well (so the compiler will arrange for the appropriate boxing of the
binding). In short, the only sure way of exchanging data in and out of
'eval'-uated code is to use explicit boxing and evaluate only closed
expressions, as has been described in
Michael Sperber
Al> One might as well insist that the "_" should be
Al> "I-am-the-fairest-in-the-land". R5rs explicitly requires in section
Al> 4.3.2 that the name of this identifier be ignored:
Al> The keyword at the beginning of the pattern in a <syntax rule> is
Al> not involved in the matching and is not considered a pattern
Al> variable or literal identifier.
"Ignore" is something different. Check the beginning of 4.3.2:
> The <pattern> in a <syntax rule> is a list <pattern> that begins
> with the keyword of the macro.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Al_ Petrofsky
> >>>>> "Al" == Alcibiades Petrofsky <alcib...@petrofsky.org> writes:
>
> Al> identifier be ignored:
>
> Al> The keyword at the beginning of the pattern in a <syntax
> Al> pattern variable or literal identifier.
>
> "Ignore" is something different. Check the beginning of 4.3.2:
>
> > The <pattern> in a <syntax rule> is a list <pattern> that begins
> > with the keyword of the macro.
Oops! Thank you. Don't know how I've been missing that.
-al
Matthias Radestock
> R5RS says:
> [[optional procedure]] (interaction-environment)
>
> This procedure returns a specifier for the environment that contains
> implementation-defined bindings, typically a superset of those listed
> in the report. The intent is that this procedure will return the
> environment in which the implementation would evaluate expressions
> dynamically typed by the user.
>
>
> Nothing in that passage says that the environment denoted by the
> (interaction-environment) includes all or any of the bindings from the
> user code. R5RS leaves it to an implementation to decide which
> bindings to include in the interaction environment.
The only way user code gets into a pure R5RS system is via LOAD and
READ&EVAL. Looking at the rrrs-authors archive it appears that the
interaction environment is definitely meant to contain LOADed
definitions. You are right that R5RS specifically (and, according to the
rrrs archives, quite intentionally) allows bindings that entered the
system in a non-standard way to be excluded from the interaction
environment. This is yet another qualification that needs to be added to
the solution I posted.
Matthias.