[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH]  Aggressively reject definitions in exp
Re: [Chicken-hackers] [PATCH]  Aggressively reject definitions in expression contexts (#1309)
Mon, 12 Dec 2016 09:38:17 +0100
On Sun, Dec 11, 2016 at 11:32:59PM +0100, address@hidden wrote:
> > 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.
> So what...
I'm pretty sure they must have considered alternative approaches and
chosen to do it this way for a reason. That doesn't mean we have to
blindly copy it, but it does mean that we need to carefully consider
the pros and cons.
> > 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.
> Sorry, but blame whoever came up with this in the standard.
I know, I wasn't criticising our implementation of this, but the
> > 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.
> I would change absolutely nothing here. As you say, we can't protect the
> user from every stupidity he or she may may come up with. And, yes, I would
> allow the case above and treat it as a toplevel definition.
That's fine by me. But it also means that we need to think hard about
the meaning of something like (lambda () (print (define x 2))).
It would be very confusing if that actually caused a global "x" to be
defined. On the other hand, I don't know how this can be rewritten in
terms of a letrec that makes any sense. So this might need to raise an
error after all (but maybe only inside a body).
Perhaps we can somehow temporarily shadow the core defining forms
while expanding a body? We'd have to take care to also shadow any
renamed references that another macro might have captured, and I'm
not sure that's possible at the moment. And a module form needs to
be able to undo this shadowing (that might be easy, it needs to start
with a fresh environment anyway).
> Your patch is just a sledgehammer approach - sorry, but it's no good.
Point taken. Let's try to come up with a cleaner alternative!
> I'll try to look at this and make a concrete proposal.
Thank you! I'll ponder this some more as well.
Description: Digital signature