9:19:33beachThough, looking at the lambda-list destructuring code in Concrete-Syntax-Tree makes me think it would not be too hard to write a CST version of PARSE-MACRO.
9:36:53beachBut we need a backquote-like facility that builds CSTs rather than expressions. :)
10:04:08makomojackdaniel: what does "a variable <class> assigned to find-class on it" mean?
10:05:29makomoand <foo> here is a metavariable, or did you literally include the characters "<" and ">" within your names (you said "class names are always in <>" so it confused me)?
10:05:57jackdanielI literally include <> in names, like *foo* for specials
10:06:59makomoah ok. tricky notation to get across :-)
10:10:13makomoyeah, because the characters "<" and ">" are usually used to denote metavariables. i.e. "<foo>" usually doesn't mean "literally the character sequence '<foo>'" but "an instance of something that follows the rule 'foo'" (sometimes even coupled with "all occurences of that <foo> must be identical")
10:10:51beachmakomo: As I recall, Dylan introduced that convention for classes.
10:11:04beachIt is not an established Common Lisp convention, though.
10:11:19shka__LIL is using same thing for interfaces
18:01:50Bikei found... maybe a bug, in how reconstruct works.
18:02:26Bikeif you have a cst for e.g. (cond (a b)), which macroexpands to (if a b nil) or so, if you reconstruct the latter you'll find that the nil has no source info, even if you reconstructed with :default-source
18:02:56Bikebecause reconstruct finds the list-ending NIL in the original cst, which has no source because of how the cst reader works, and uses that