Re: eval-case and toplevel prohibitions

[Andy Wingo <wingo@pobox.com>]

Hi,

On Wed 04 Mar 2009 09:48, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> 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/