I've written the article about the bug of
datum->syntax. Now I think I've got an idea to resolve without doing O(n^2) identifier rewriting thing during showering. It's always good to let it sit for couple of days (can be weeks or even months).The problem is that if a renamed identifier is a local variable however variable look up can't find it properly because it's comparing somewhat awkwardly. The reason why it's doing weirdly is more like historical reason (mostly my ignorance of hygienic macro). It might be cleaner if it can refer just comparing environment frame however because of the lack of knowledge, it's now a huge spaghetti even I don't understand why it's like that. Currently identifiers can hold one set of compile time environment frames. The structure of env frame is like this:
(type . ((var val) ...))type indicates if this is a local variable frame or a pattern variable frame. To look up proper variables from this, it required (or not) somewhat very complicated pile of shit. It basically tries to find proper frames of given identifiers. However because macro expander doesn't rename all identifiers, some frames are the same in identifiers that should be different variables.
The idea came up during showering is making identifiers can contain multiple sets of env frames. The frames should be used from the latest to oldest and macro expander should always rename with prepended env frames. This seems identifier can hold proper environment where it's defined no matter how many it's got renamed. The issues I can see are:
- Cache file explosion
- Memory consumption
I'm not totally sure if this works or not yet but sounds like a plan. Need to consider a bit more before start doing this.
No comments:
Post a Comment