[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)
Sat, 25 Feb 2017 18:13:48 +0100
On Sat, Feb 11, 2017 at 03:37:35PM +0100, Peter Bex wrote:
> On Mon, Dec 12, 2016 at 09:38:17AM +0100, Peter Bex wrote:
> > I'll ponder this some more as well.
> Here's a very patch which _doesn't_ require macros to know they're
> being evaluated at toplevel or not.
Here's an update with this patch plus two related patches which fix
an occurrance of a "define" in an invalid context in CHICKEN core
which you'll see when you try to recompile CHICKEN with itself after
having applied the first patch.
This originally worked because the define would be a global one, which
is quite broken! I think erroring out early is a nice benefit.
Finally, the third patch here fixes a bug that we inadvertently
introduced when we made chicken.expand into a module: because these
internal definitions like chicken.expand#define-definition weren't
exported, and they're not set! inside the module, the compiler assumed
it would never be set, so it would inline the values, which means the
definitions would always be compared with #<unspecified>.
However, I figured out that the real cause of #1309 is much, much deeper
and has to do with a nasty bug in ##sys#canonicalize-body: it invokes
"fini" as soon as it sees a non-pair. However, fini doesn't handle
expansions the same way as the body. For example:
(let () 1 (begin (define blabla 3)) blabla)
This will define blabla globally (or trigger an error in CHICKEN 5 with
the patch), because the "1" stops the begin from being expanded properly.
I fear that this requires a pretty invasive rewrite of
##sys#canonicalize-body. I'll get back to y'all on that.
Description: Digital signature