syntax-control
73budden .
budden73 at gmail.com
Sat Oct 14 19:25:44 UTC 2017
Hi! My 2 cents (a draft for a proposal).
1. As I said, there should be a way to set up tracing and maybe
assertable preconditions that should hold before loading the system.
This way we can _diagnose_ what happens. This technique should be
supplied not for newer versions only, but for some old versions too,
so that one can compare the state before and after the change, and all
should be documented. I believe trace and CLOS should suffice to avoid
patching asdf sources for old versions, but if not, patches can also
go.
2. By default, bind readtable to (copy-readtable *shared-readtable*)
or (copy-readtable nil) before loading each system (I hope that
systems are loaded continuously, that is, components of one system are
not intermitted by components of another, otherwise we would do that
at a component granularity). Obviously, it would break some setups.
3. If system wants to do something special, that special must be
declared. Obvious special behavior is not to copy current readtable
before loading system - in this case all changes would affect global
readtable. One can think that another option is to use some named
readtable, but we don't need that: one can specify readtable on a
per-file basis (in fact, currently there should be no more than one
readtable per package).
4. For any additional declarations and settings, there should be a way
to declare them either in system definition itself, or in some another
place which is read before system is loaded (some per-site asd
configuration). This is for inserting declarations into unmaintained
3-d party systems.
Does that work? I guess no due to some reason, but I'm not an ASDF
expert, so I can be optimistic :)
5 (offtopic) there is a perfect solution for macro-character conflict,
which is a plain (non breaking) extension of CL. It is named
symbol-readmacros. I use them for several (maybe 7) years already, and
they just work. No pain anymore :) The idea is that macro reader is
associated to symbol, not to character. This way issue of conflicting
characters is reduced to that of conflicting symbols. We all know that
issue of conflicting symbols is resolved by package prefixes, import,
use-package and so on, so many implementations of custom this-lib:{
and that-lib:{ can coexist peacefully in the same image. Of course,
any client code should be modified to take the advantage of this, so I
usually add couple of lines for every library I use that wants to
extend syntax.
I'm not sure it can be implemented in a portable way or even w/o
changes to the implementation, but I have the implementation for SBCL
and at some time in the past I had one for LW.
I believe this symbol-readmacros is the only right thing here. There
are thousands of libraries and only dozens of characters which can be
used. So when using macro-characters, conflicts are absolutely
inevitable.
2017-10-13 23:31 GMT+03:00, Faré <fahree at gmail.com>:
> Due to the readtable bug in ASDF 3.3.0 I updated the "syntax-control"
> branch that for the last three years was supposed to solve all
> readtable bugs when building with ASDF.
>
> I merged 3.3.0.1 into the branch, but the branch itself is not ready
> for merging into master:
> it does either too much or too little, and must be either completed or
> simplified.
> I think it stands a better chance of bieng merged soon if it is simplified,
> so I re-read and re-wrote the documentation for what this branch
> should be doing,
> and detailed a "Proposal 1" for minimal changes to ASDF that would go
> a long way towards bringing sanity in builds of software that modify
> the syntax.
>
> I sollicit your feedback:
> https://gitlab.common-lisp.net/asdf/asdf/blob/syntax-control/doc/syntax-control.md
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
> http://fare.tunes.org
> Problem of the day: finding suction cups that don't suck.
>
>
More information about the asdf-devel
mailing list