libera/#sicl - IRC Chatlog
Search
9:50:58
beach
Tell me whether this idea is flawed: I am working on a library that I call Common Macros, which is supposed to contain definitions of most of the macros used by some typical Common Lisp code. And I want those macros to expand to portable code as much as possible.
9:51:05
beach
But some expansion like those of DEFCLASS and DEFMETHOD contain symbols that are not in the Common Lisp package but in some implementation-specific package that contains MOP code.
9:51:06
beach
So what if my library were to depend on CLOSER-MOP, and I use the CLOSER-MOP package for those symbols?
9:52:00
beach
I would have to load the CLOSER-MOP system with the right *FEATURES* for cross compilation of course.
9:56:54
beach
Alternative idea: I decide on a particular package name that client code will then have to create and fill in with MOP symbols.
10:05:36
pjb
beach: otherwise, imposing your own package name would be OK to, up to the client to set it up as a conduit package to their implementation of the library.
10:50:01
beach
I think I figured it out. Step 1 is to systematically use a package-local nickname. Then client code can set that nickname before loading the system.
10:51:12
beach
Step 2 is to split the system so that a special variable is created in phase 1, so that client code can assign the right package name to that special variable.
10:53:36
JonBoone[m]
beach: Am I understanding correctly that the package-local nickname in step 1 is to refer to the implementation specific MOP package?
10:54:25
JonBoone[m]
And the special variable from step 2 is the destination package for the macro expansion binding?
10:54:29
beach
And I can do that with something like (:local-nicknames #.*package-name*) provided I can make sure *package-name* has a value.
11:15:33
beach
For the longest time, I though the keyword package was the only one that was always available and that you could modify, but there is also COMMON-LISP-USER.
11:16:44
beach
So the client does: (let ((#1=*common-macros-mop-package* <mumble>)) (declare (special #1#)) (asdf:load-system #:common-macros))
11:17:41
beach
And the packages.lisp file contains: (:local-nicknames (#:cmm #.(locally (declare (special #1=*common-macros-mop-package*)) #1#)))
11:19:35
beach
I could go to the trouble to define yet another ASDF system that defines yet another package that contains that symbol, but it is no worse to rely on a particular symbol in the COMMON-LISP-USER package than it is to rely on a particular package name and ASDF system name.
11:21:00
beach
And the local SPECIAL definitions make sure that there is no definition attached to the symbol globally.
11:26:16
beach
I should use this idea to simplify the (now relatively complicated) structure of my systems that can be built either extrinsically or intrinsically.
11:44:31
beach
New topic... I am looking at the (second) definition of ENSURE-METHOD in CLOSER-MOP, and I can't see how it can be correct. It seems to take a lambda expression from a method body, then wrap it with MAKE-METHOD-LAMBDA and finally compiler it. But that won't capture the lexical environment of DEFMETHOD will it?
11:45:28
beach
SICL ENSURE-METHOD assumes that this wrapping has been done and the result turned into a function in the environment of the DEFMETHOD form.
11:50:34
beach
I guess I should just leave it. I think Pascal Costanza will not react well if I bring up a topic related to MAKE-METHOD-LAMBDA.
13:15:28
scymtym
beach: do you think REQUIRED-SECTION, OPTIONAL-SECTION, REST-SECTION, KEYWORD-SECTION and AUX-SECTION node kinds would be the best solution for the lambda list ambiguities?
13:16:27
beach
If such a section appears, then there is a lambda-list keyword (except for required). And then there can be 0 or more parameters.
13:21:25
scymtym
yes. i'm wondering whether handling all sections uniformly or keeping the AST small is more important. this matters for required and to a lesser extend for optional, rest and aux since the "section" adds less information for those
13:22:02
beach
I agree. I would go for uniformity, but that's just me, and I can live with other solutions.
13:23:12
beach
STYLE-WARNING there is an &AUX lambda-list keyword in there but no &AUX "parameters".
13:23:54
scymtym
right. having each section available, even for required parameters, could be good for editing and maybe indentation as well
13:25:00
scymtym
ok, i'm going to try and see how it goes. i don't think i will have to adjust too much client code
13:57:02
scymtym
bike: somebody pointed out the problem of trivial-with-current-source-form being LGPL and at least some of its users, for example esrap, being MIT. i think the only solution is to switch t-w-c-s-f to MIT. since you contributed some code: would you be ok with that change?