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
