eval-case and toplevel prohibitions

eval-case and toplevel prohibitions

[Andy Wingo]

Hi all,

I've been hacking at the compiler in recent days, separating out
expansion from compilation (currently they are intertwingled, which
produces some bugs), and making GHIL a more simple language, more
amenable to optimization.

I've grown to really like syncase in its psyntax.scm incarnation. (I
have something of a Dybvig adoration complex.) It has in it an eval-when
construct, but eval-when doesn't have separate rules for toplevel and
nontoplevel, just '(eval compile load):

  http://www.scheme.com/csug7/system.html#g91 (see the section on eval-when)

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.

Cheers,

Andy
-- 
http://wingolog.org/

Re: eval-case and toplevel prohibitions

[Neil Jerram]

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.

I recall that Marius added the checks, but unfortunately not why.
Sorry!  Does googling help?

        Neil

Re: eval-case and toplevel prohibitions

[Ludovic Courtès]

Hello!

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...

Thanks,
Ludo'.

Re: eval-case and toplevel prohibitions

[Andy Wingo]

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/