[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: eval-case and toplevel prohibitions
From: |
Andy Wingo |
Subject: |
Re: eval-case and toplevel prohibitions |
Date: |
Fri, 06 Mar 2009 11:56:39 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
Hi,
On Wed 04 Mar 2009 09:48, address@hidden (Ludovic Courtès) writes:
> Andy Wingo <address@hidden> writes:
>
>> So I was thinking: why do we have this fetish for prohibiting certain
>> forms in a non-toplevel context? I am of a mind to replace eval-case
>> with eval-when, which is actually more expressive, as it allows us to
>> discriminate the different phases in non-toplevel contexts as well.
>
> Could it be because `eval-case' expressions can evaluate to nothing,
> which can be confusing in non-top-level contexts, e.g.,
>
> (define (nothing)
> (let ((foo (eval-case ((never-true) 'foo))))
> foo))
>
> Actually, this yields #<unspecified> in Guile-VM and #f in `master'.
> The definition of `toplevel-env?' in there in quite sloppy...
I would suspect this depends on whether this code is being compiled or
interpreted too, as the toplevel-env? check pokes the env arg to a
mmacro...
Here's a reason, maybe:
(define (foo)
(define-public (bar) 10)
...)
That will expand to (define (bar 10)) (export bar), but bar does not
have a variable in the current module.
OTOH... `define-public' is a bit silly, and it and the `export'
interface seem to be to be a part of the first-class module interface,
which is a sharp tool -- it's assumed that you know what you're doing.
Or, we could make define-public expand to something else that actually
makes sense, like (module-define! (current-module) 'bar (lambda ()
...)), then export that definition.
My take: let's relax prohibitions, and try to produce intuitive behavior
in more circumstances.
Andy
--
http://wingolog.org/