chicken-hackers
[Top][All Lists]
Advanced

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

[PATCH] Clean up define-specialization macro, get rid of ##sys#globalize


From: Peter Bex
Subject: [PATCH] Clean up define-specialization macro, get rid of ##sys#globalize
Date: Sun, 11 Apr 2021 12:09:37 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

Hi all,

I've been chipping away at my nemesis, #1131 and while working
on that I stumbled upon ##sys#globalize, a bit of an abnormality
because it's used in two places only.  The first place is the
define-type macro and the other is process-declarations.

There's no real reason these two places should have special
treatment over the other places where names are resolved in core.

The macro was the most obviously weird, because it tries to construct
names from inside the macro.  That's a recipe for disaster because we
might be inside another macro's expansion, which might make looking up
a name globally impossible.  Now this is a very obscure use case and
I didn't bother to write a test for it, but I do think that this points
to a design mistake in that macro.

So I changed the macro to only emit a new core form, which then gets
properly resolved to the correct name inside the compiler, where we
have access to the full syntactic environment.

The process-declarations seems a bit odd too, for instance I saw a few
places where it would call "stripa" on "syms", which is a list of
symbols.  But if you look at how globalize works, it just returns the
given object if it's not a symbol, so this can't have worked in the
first place.  I think what was intended there was a call to
"globalize-all".

If you look at ##sys#globalize, you'll see that it tries to resolve
macro aliases first (which "lookup" does in the compiler) and eventually
checks the syntax environment and if nothing is found uses the alias
global hook to resolve the name.  process-declaration received as its
"se" argument the old value of ##sys#current-environment, so I think
calling "lookup" there instead is a better approach (which looks in the
environment too).

I think this is a nice simplicification and another small but useful
step towards whittling down ##sys#alias-global-hook.

Cheers,
Peter

Attachment: 0001-Do-not-try-to-resolve-names-in-define-specialization.patch
Description: Text Data

Attachment: 0002-Get-rid-of-sys-globalize-and-a-hack-in-core-declare.patch
Description: Text Data

Attachment: signature.asc
Description: PGP signature


reply via email to

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