libera/#climacs - IRC Chatlog
Search
12:51:46
beach
On the other hand, if you think I am on the right track, then I would appreciate ideas on what operations to include.
12:54:26
scymtym_
for the s-expression-syntax library, i added operations as needed. the result is https://github.com/scymtym/s-expression-syntax/blob/builder-protocol/code/expression-grammar/protocol.lisp . to convert the s-expression-syntax to clearcut, those operations would be required. then again, providing a subset in clearcut and extensions in s-expression-syntax could also work
13:00:41
scymtym
it has been manageable but needs some cleanup. the names are bad and the "natural" concept needs more thought
13:05:44
scymtym
this is the editing library in a little text-based testbed: https://techfak.de/~jmoringe/editing-library-1.ogv (sorry for the flickering. i thought i jumped through the hoops to get rid of it)
13:16:58
beach
Speaking of which, what is a good way of creating an extension for a library like Clearcut. I know what I did for Clostrum. I :USEd it in a new package, reexported all operations, and then the new package because the extended library to use with the client.
13:17:44
beach
Speaking of which, what is a good way of creating an extension for a library like Clearcut. I know what I did for Clostrum? I :USEd it in a new package, reexported all operations, and then the new package became the extended library to use with the client.
13:19:45
beach
Actually, that's not quite what I did, but the effect is sort of the same. I also wanted to avoid some Clostrum symbols, so I imported the lot minus some exceptions.
13:21:29
beach
The issue here is that I don't want to add symbols to an external library, and I don't want client code to distinguish between library-provided symbols and symbols provided by the extension.
13:25:14
splittist
Why don't you want client code to distinguish between the base library and the extension library? (What if there are two orthogonal extensions?)
13:27:05
beach
My intuition is that I want to create a coherent protocol, using a single package. But if the library does not provide everything I need, perhaps because it is outside the scope, I think it is ugly to use two different package prefixes for what client code should think of as a single protocol.
13:28:06
beach
For Clostrum, the issue was that SICL needs stuff from a global environment protocol that not all Clostrum clients need.
13:29:07
splittist
It doesn't seem very future proof. Or perhaps it is. Things can move between the base and extension as long as they are the 'same' thing.
13:30:38
beach
Another way of seeing it, is that I did not want to litter client code with Clostrum-specific details, so I created a SICL-specific "module", except that I cheat by having that module secretly use Clostrum functionality for most of its operation.