Re: CL packages landed

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

Philip Kaludercic <philipk@posteo.net> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> I've pushed the branch "pkg" which implements CL packages for Emacs.
>>
>> Before Someone (tm) gets the idea of blowing up something like Internet
>> cables instead of pipelines, or we have blackouts here, or whatever, I
>> thought I'd better make this accessible.
>
> I am very glad to see this!  Could you comment on what larger influence
> with might have on Emacs Lisp as a language.

I can say something about what my goal is. If this ever lands in master
is a different story, I haven't heard something like that being said.
But packages are now there, and won't disappear :-).

So, my goal:

- Be backwards-compatible for users and developers.

- Provide the benefits of packages to developers, mainly.  Where users
  writing their own stuff would be developers as well, who use currently
  "my-" prefixes for own functions etc.
  
  Some of the benefits: The ability to export only a subset of
  functions/variables, while being able to use unobstrusive names.  It
  would no longer be neccessary to use prefixes like or "xyz-", or
  "xyz--".  You could define a package "xyz", and reference definitionsi
  with something like "xyz:..." or "xyz::..." (use only if you must
  access internals).  Or use no prefix at all by importing symbols or
  packages.

  Emacs itself could hide tons of internal definitions like that, and
  export only what is in the public interface.

  And so on, you get the idea.

And one could think of extensions, which are currently not in scope for
me, like hierarchical packages (think Java, x.y.z.collections) that
could be added on top, to structure the package namespace.  CMUCL and
Allegro CL have something like that.

> E.g. in bug#57907 there was a discussion how adding keyword support
> for cl-loop was not necessary for Emacs Lisp, but now that symbol
> packages might become a thing, would that have to change?

I remember that.  The implementation of cl-loop would have to be changed
to work like it does in Common Lisp, that is, it would accept something
like 'for' regardless of for's package.  That's not hard.

> How would the support look like from a backwards compatibility
> perspective?  I am assuming all old code would be loaded into the
> default packages, right?

Right, and that's already the case in feature/pkg, and it seems to work
well, except that Gnus doesn't start for me.  I couldn't figure that one
out yet.  Gnus is large, and tedious to debug if one doesn't know its
internals.

Other than that, what I use (Magit, Helm, Lsp, ...) seems to work just
fine, and meanwhile the existing tests also succeed.  That looks like
good news in the compatibility department so far.

Performance seems to be more or less the same, unsurprisingly, a full
build is a tad faster in pkg.  No difference noticeable interactively.