Re: Help sought understanding shorthands wrt modules/packages

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

João Távora <joaotavora@gmail.com> writes:

> But even if they are installed, I don't think they negate the need for
> CL packages or make them any harder to implement.

I suspect it could make it harder to achieve backwards-compatibility.  I
can't prove it, though, because I set shorthands out of scope for my
experiement.

Let me try to explain:

The main problem with staying backwards-compatible was the triple of
functions (intern, intern-soft, symbol-name), alone and in combination,
what semantics they currently expect and how that fits with packages.
That's what I found during my experiment.

The simplest example is keywords: (intern ":a") currently makes a
keyword, with the semantics that any symbol whose name starts with a
colon is a keyword, and symbol-name will return a name that includes the
colon.  That doesn't fit well with CL packages, where the colon is
interpreted as part of a qualified symbol name, the symbol-name is "a"
and the empty string in front of the ":" is the (empty) nickname of the
keyword package.

Like I said, that's the super-simple form of the problem.  I guess one
can find every possible variation of that problem somewhere in the wild.

Without taking shorthands into account, one can make an educated guess
what semantics the code expects, and use that to become
backwards-compatible.  I suspected that was the case, which was the
initial reason I started the experimeent.  Yeah, I know, what a nerd
:-).  And it proved true, without shorthands at least.  Experiment done.

With taking shorthands into account, these "guesses" don't really hold
much water.  Or so is my gut feeling ATM.

P.S.

I have an alternative idea how to "guess", but I don't know if it's
practically feasible, works well enough, and yadda yadda.  See
admin/cl-packages.org in the branch.

Just a side note :-).