For now, I have been hoping for/focused on ASDF 3.4 which would be
backwards-compatible, but add new capabilities, so would not be
forwards-compatible.
Wondering if it will just languish unused is a strong disincentive to
invest my unpaid hours in ASDF. There are other things I can work on
that are more fun.
Cheers,
R
On 24 Feb 2024, at 9:57, Stelian Ionescu wrote:
Yes, Faré reminds me that CCL's default readtable is *not* the
standard readtable, but a customized one. That means that defaulting
to standard readtable would cause breakage in CCL programs. This is
the problem that he alludes to below.
Defaulting to the standard readtable *might* cause breakage, but it
would be good for portability.
Given that Quicklisp and SBCL *already* refuse to update their
bundled ASDF versions, because of warnings about deprecated behavior,
I'm reluctant to donate any of my unpaid time to fixing this: it's a
strong disincentive to making any improvements to ASDF, as opposed to
just fixing bugs around the edges.
Is it time for ASDF 4 ? There's tons of stuff I'd like to delete or
change.
On 22 Feb 2024, at 10:16, Faré wrote:
In the past, to introduce changes a fraction as
compatibility-breaking (e.g. making utf-8 the default, or changing
the internals of OPERATION), I would write up an explanation why the
change is desired that anyone can read, discuss on the mailing list,
write the code but keep it unmerged or disabled, make an
announcement for the intended future breaking change, go over all of
Quicklisp with Anton Vodonosov's cl-test-grid, locate all the
offenders there, and send patches to each and everyone, wait a year
if the old behavior used to be officially documented and supported,
only a few weeks if it was a forbidden internals dependency, run the
test again, give a last warning to those who didn't merge the
patches, sometimes fork the systems left unmaintained to a new home,
then finally make the change and announce it. And be ready to handle
all the angry authors of proprietary code not in Quicklisp that you
failed to previously contact.
For syntax-control (see my branch, that needs much love merging with
3.3.7), we never reached that point, if only because we were never
satisfied with the complexity of the code (speaking for myself at
least, I suspect for RPG also to a point, but he can opine otherwise
if needed). There are many special variables beside *readtable* that
control syntax (e.g. some systems try to make double-float the
default—with "interesting" side effects to other systems compiled
later, more subtle than the big obvious breakage when the readtable
is wrong or corrupted). And users define more such variables as they
extend the language. So now you want to maintain a dynamic list of
symbols, some in packages not yet defined, that you want to track,
save and restore. Next your users will want to bind the values of
some of these variables around some systems, modules or components.
The code is big and messy, and it isn't even obviously "the right
thing" overall, though a lot of elements of it are, and every piece
is needed somehow.
There's also the question of whether the default readtable should be
THE "standard" readtable (immutable on some implementations, not on
others), or some shared mutable readtable copied from it (will break
many CCL extensions), or from the magic initial readtable that is
not standard and that some will mutate (the most backward compatible
option, so probably the one ASDF should pick, though it's ugly,
unless you want to wrestle some more with the community).
Should we merge the whole messy thing that solves the entire
problem? Only the small and clean part that is obviously right but
clearly insufficient? Each time we make such a change, we have to
pay a lot to overcome a big incompatibility hurdle. If the solution
isn't fully satisfactory, then we are setting ourselves up for yet
another round (or several) of such costly change(s).
I'm out of the Common Lisp community (moved to Gerbil Scheme), but
whoever wants to tackle this challenge for good better makes sure
they (and the community!) are ready to pay the price for the
transition, and multiple times so if they don't get it right on the
first try. Oh, and once you take on the job, you'll be hated by some
part of the community whether you subsequently make the change or
don't.
Good luck!
On Thu, Feb 22, 2024, 10:15 Robert Goldman <rpgold...@sift.info>
wrote:
I think this is still true, but... we cannot be discussing ASDF
3.2.1 here. It was released almost 7 years ago, and for whatever
reason Zach refuses to update. The current version is 3.3.7
Please get a more recent ASDF and try again. I *believe* that this
behavior is still in place: Faré proposed the "syntax control"
patch to fix this, but we decided we had no easy path to
introducing it, because it would break other code (admittedly not
of good style) that relies on the old behavior of having the
readtable setting leak out of one file into another. See
https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/86
Any non-backwards compatible modification to ASDF -- even to the
extent of raising a deprecation warning -- has led to
temper-tantrums in the CL community...
On 21 Feb 2024, at 22:14, sc...@sympoiesis.com wrote:
Hi all! I just ran into something surprising. This is with ASDF
3.2.1, packaged with Quicklisp. I am using Named-Readtables. I had
'*readtable*' set to a nonstandard readtable, then did quickload
of a system unrelated to the one that defines and uses that
readtable. The compilation failed; after I did '(in-readtable
:common-lisp)' and tried again, it succeeded.
A quick glance at the ASDF source code shows that it binds
'*readtable*' to a standard readtable in some cases, such as to
read a '.asd' file, but not in 'uiop/lisp-build/compile-file*',
nor in 'asdf/lisp-action:perform-lisp-compilation'. Wouldn't it
make sense to do that?
-- Scott
--
Stelian Ionescu
