libera/#sicl - IRC Chatlog
Search
14:36:24
beach
scymtym: What if we started a separate repository with an extracted version of the package system from SICL? Could such a system serve as the "model" that you use for your IDE experiments?
14:37:42
beach
As usual, we would then create an "intrinsic" and an "extrinsic" version, and the extrinsic version could then serve that purpose.
14:45:35
scymtym
beach: i think a separate repository for a portable implementation of the package system would be useful in general. however, the IDE use case could require things that might not fit too well into the general architecture. but then again, maybe a few additional protocol generic functions and a client parameter would be enough
14:46:56
scymtym
at least for me, this question is not urgent since the simple package system "model" that i am using at the moment is sufficient for the work i'm doing
14:48:30
whereiseveryone
having both an intrinsic and extrinsic version of sicl sounds like a good idea given what I've learned about it so far. Sounds like having only one or the other would be limiting for certain user's use cases
15:20:28
beach
It is an interesting exercise to extract something like this. One has to think differently compared to when the system is an intrinsic part of a specific Common Lisp implementation.
15:21:02
beach
For example, FIND-PACKAGE is not a function that can be defined in the system, because it really isn't a package function, but an environment function.
15:36:21
beach
So here is the plan: Parcl will use the s-expression-syntax library, in particular for the DEFPACKAGE macro. So I won't use it immediately in SICL because that library may evolve. There will be separate documentation and a separate test suite.
15:37:32
beach
It would also be interesting to optimize for performance, like the COMMON-LISP package could have a special representation for the symbols to make lookup faster.