chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] [5] Aggressively reject definitions in exp


From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] [5] Aggressively reject definitions in expression contexts (#1309)
Date: Sun, 11 Dec 2016 23:18:20 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Sun, Dec 11, 2016 at 10:58:50PM +0100, address@hidden wrote:
> I don't know, but reading what you wrote in the ticket ("... this will
> require quite a bit of rework and hardcoding all defining forms into the
> compiler (which we have to do already anyway, to make internal defines
> work)...") makes me cringe.

I don't like it much either, but when I looked at other Scheme systems,
this is exactly what they do.  The whole "internal defines are rewritten
to letrec" idea is whack.  It could be taken to mean that "lambda" and
all the "let" variants need to (unhygienically?) redefine all the defining
forms inside their body to work differently, but I think that's even
nastier.

> It's the responsibility of the defining forms to expand into something
> that results in proper local (or nonlocal) definitions, not a matter of
> the compiler, and it is up to the user to use them in a proper
> context.

So (+ 1 (define x 2)) is acceptable and we should allow it?  It makes no
sense, so it's better to error out.  On the other hand, we can't catch
every single mistake a user makes.

> So I think this patch doesn't really solve the problem, just avoids it by
> enforcing overly strict behaviour that shouldn't be necessary. What should
> be solved is properly handling the inner "begin" in a body, which is clearly
> broken and indicated in the ticket.

I think the "begin" is a red herring and happens to trigger the error.
There will be other situations where this error occurs.

> Note that some defining forms always have toplevel semantics
> ("define-constant",
>  "define-external"), regardless of context. The same applies to
>  "define-inline"
> (it might be interesting to allow this locally, but we don't have the
> machinery in the compiler for this.)

This is another thing that "at-toplevel?" makes easy to detect, and
those forms can error out.

If you have a concrete proposal to improve the situation, I'd be happy
to discuss it.  Of course, if this patch were applied, we can always
switch to that any new approach later.  I think at-toplevel? could
still be useful for some user macros.

Cheers,
Peter

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]