[Top][All Lists]

[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: Mon, 12 Dec 2016 09:38:17 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

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

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


Attachment: signature.asc
Description: Digital signature

reply via email to

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