Common Lisp style: multiple packages in same repo

[Daniel Pezely]

On 2018-08-25 06:35 PM, Faré wrote:
> [...] keep your
> code well-organized: each file by construction can only refer to
> symbols from files that it depends on, you have think of your
> dependencies clearly. [...]

I generally strive for a similar discipline but on the package level 
rather than granularity of individual files.

An observation supporting these approaches: Use of fully qualified 
symbol names makes it easier for other people to navigate and reason 
able unfamiliar code.  Package nicknames in CL help with otherwise 
cumbersome names, so there's little reason not to do this in my experience.

> As for LIL, it also uses packages for punning: there are distinct but
> related symbols stateful:insert pure:insert classy:insert and
> posh:insert for inserting a key / value pair in a map in all
> combinations of stateful interface-passing-style, pure
> interface-passing-style, classic imperative object oriented style, and
> purely functional object oriented style — with macros that can
> automatically wrap one into the others. [...]

Yes, for me, something similar justified two systems, two packages in 
one repo.  The higher level package shadows some CL names like OPEN for 
capitalizing upon one's existing knowledge of CL:OPEN's parameters and 
behaviours.

Understandably, some people avoid shadowing of CL functions, so this 
contributed to splitting into two packages-- beyond higher versus lower 
level interfaces.


Faré, you bring up many interesting points for possible further 
discussion, and thank you for mentioning LIL.  I had forgotten about LIL 
long since glancing at ILC'12 proceedings all those years ago. I'll 
definitely explore techniques you mentioned for other packages I intend 
to release in future.


Regarding questions from the original post, the Common Lisp community at 
large seems far from attaining a quorum, let alone consensus.

Perhaps this presents an opportunity for maintainers of Quicklisp 
(perhaps in collaboration with Quickdocs) to introduce a style guide for 
making their lives easier.  Maybe after gaining more experience with 
Rust's (Cargo's) workspaces [1] for synchronizing versions across a 
family of subsystems, I'll propose something to Quicklisp maintainers.  
I'm sure Rust didn't invent that mechanism, so if others possess that 
knowledge already, please suggest such a model!

[1] 
https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

Thanks,
   -Daniel