libera/#sicl - IRC Chatlog
Search
5:41:53
beach
In a library that I created recently ("Declare", for manipulating declarations in code), I abstracted out the operations for creating and taking apart expressions, like FIRST, REST, ATOM, CONS, so that they make an indirect call through an instance of a standard class. That way, client code can manipulate expressions in the same way, whether they are represented as S-expressions or as CSTs. I am thinking of doing two things. Number
5:41:53
beach
one would be to extract those operations to a separate library, and adding lots of useful operations to it, like MAPCAR, DESTRUCTURING-BIND, etc. Number two would be to use this library in the version of CST-to-AST (which would have to be given a different name) to make it representation neutral. While number two might sound painful, it is greatly simplified by the fact that the s-expression-syntax library is already representation
5:41:53
beach
neutral. For Second Climacs, we could then add a WAD representation to the new library. And perhaps, the s-expression-syntax library (or perhaps rather the parser.packrat library) could use the new library.
5:44:18
beach
Of course, my recent experience is that, when I have some idea like this, usually scymtym has already implemented it.
5:57:39
beach
So I guess before I start such a library, I'll wait for scymtym to tell me whether he has already done it.
6:12:35
beach
Oh, this is wonderfully circular. The s-expression-syntax library has a parser for DESTRUCTURING-BIND which can be used in this (new?) library I am thinking of, but the s-expression-syntax library would typically also (indirectly) use the library.
8:08:04
beach
Hmm. I have a class SPECIALIZED-PARAMETER-AST and a method (defined right below the class in the same file) CHILDREN that has this class as a specializer. Yet (SB-MOP:SPECIALIZER-DIRECT-GENERIC-FUNCTIONS ...) does not include the CHILDREN function.
8:12:22
beach
Oh, the problem seems to have been caused by an incorrect method qualifier on a different method. Strange stuff.
8:23:34
beach
SBCL didn't complain about adding a method with incorrect method qualifiers to the generic function. :(
11:37:08
scymtym
beach: the s-expression-syntax library contains a protocol that is somewhat like the one you describe but tailored to the s-expression parsing use case: https://github.com/scymtym/s-expression-syntax/blob/builder-protocol/code/expression-grammar/protocol.lisp
11:45:01
scymtym
i have thought about it briefly in the past but i try to not enlarge my web of interdependent experimental libraries unless there is a very good reason
11:45:24
scymtym
for the use case of declaration canonicalization, i still think it might be easier to handle that on the builder level since then the s-expression-syntax library can handle the input representation. now, if more use cases come up, the conclusion may be different
11:46:29
beach
Especially in the latter. Then the code would be independent of the representation of the input.
11:53:17
yitzi
scymtym: I should have some time later in the week and possibly next week to work on dpans if there is remaining work to be done. My school term just started so I've been a bit busy.
11:54:13
scymtym
beach: right. switching the s-expression-syntax library to a similar protocol provided by different library shouldn't be a problem. will probably take some effort to iron out the edge cases and implicit assumptions of the current implementation
11:54:46
scymtym
yitzi: great. i'm currently busy as well. but i managed to work on the converter a little bit
11:55:24
scymtym
one thing i wanted to point out is that masinter has apparently found the missing issues (one that CLHS has but we don't)
11:57:02
scymtym
yeah. i have only looked briefly so far. but i did find some mails containing issues that i haven't been able to find anywhere else