Re: [Chicken-hackers] [PATCH] [5] Aggressively reject definitions in expression contexts (#1309)

[felix . winkelmann]

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

> 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. It certainly
gets very complicated after a while, but we can try our best to make it work.

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

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.

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

That the begin is not handled there is clearly an error. We could simply
allow expand every sequence of definitions in an expression sequence
into a (nesting) letrec, with subsequent non-definition expressions treated
like another body of that letrec form and this is what IIRC was intended with 
the
current behaviour. If this seems to be broken then let's fix it.

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

No, I don't like this. It's a recipe to uglify macro definitions.

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

Your patch is just a sledgehammer approach - sorry, but it's no good.

I'll try to look at this and make a concrete proposal.


felix