[Asdf-devel] syntax-control branch

[Faré]

On Sat, Jun 7, 2014 at 8:03 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
> I'm still groping after a clear statement of exactly what class of bugs
> it is that we are proposing to fix.  The existing design document is
> still too vague, proposing to fix
>
> "uncontrolled, unintentional leaking of readtable side effects to
> systems that depend on such effects not happening,"
>
> I think we need a clear example of a bug (ideally from a real system,
> although it's fine if that bug has since been fixed) that would be fixed
> by the change.
>
I probably should create test cases.

Scenario A: dealing with *readtable* being bound to a new value
1- setup the test environment
2- save current packages
3- load fare-quasiquote (or anything that has its own readtable)
4- while in-readtable fare-quasiquote, load-system :force t
   something that uses normal quote,
   and see it corrupt its fasl with fare-quasiquote annotations.
5- delete all new packages since 2
6- repeat 3, 4 — and see whether it breaks [used to]

Scenario B: dealing with the *readtable* object being modified
1- setup the test environment
2- load and compile x1, that define #^
3- load and compile x2, that uses #^ as per x1
4- load and compile x3, that defines a different #^
3- load and compile x4, that uses #^ as per x3
4- force recompilation of x2 — it will use the definition from x4 — oops
5- force recompilation of x1 and x4 — it will use the definition from
x2 — oops again

> Also, we need an argument for why this must be fixed in ASDF.
>
Because ASDF must be safe when called from a different readtable.
And using ASDF safely in presence of

> Here's the devil's advocate argument:
>
> "OK, you have a crummy library that leaks state unintentionally, and
> happens to do that in the readtable.  Why is it ASDF's job to make that
> library suddenly work *without modification*?  Why shouldn't we just
> tell the maintainer of that library to stop leaking state unintentionally?"
>
It's not *that library*. It's all the innocent libraries
that know nothing about readtables, and that will be compiled
into calls to functions from systems they don't depend on,
which will pollute the build.

> E.g., if I had a library that was annoyingly causing the printer to
> display integers in hex, why wouldn't I just fix that in the library,
> instead of trying to hack ASDF to prevent it from happening?  The
> GBBopen library, which makes a sort of expert system shell, was borking
> my environment in all sorts of ways, but I j
>
Because you can't. You can't control what readtable is used at the REPL.
You don't control which of your dependencies will or won't be forced
recompiled by some change.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
No one has the right to a position;
everyone has the right to positions being well filled.     — Ernest Renan






















ust stomped on it until it
> stopped doing that.
>
> A further development of the devil's advocate position:
>
> It's not hard to fix unintentional readtable leakage.  You just make
> your library export a variable holding its readtable and a function that
> will set the readtable to the one you're exporting.  You make sure you
> don't touch the default readtable.
>
> On the flipside, if you have a library that is intentionally leaking
> readtable state, it's likely to be an intricately balanced, teetering
> and delicate edifice, because CL doesn't provide good tools to deal with
> readtables (as we have discussed, packages have names, so are easy to
> deal with; readtables don't and are correspondingly fussy). So if we go
> in there using ASDF as a blunt instrument, we are very likely to mess
> things up in complex and difficult to debug ways.
>
> So it seems to me that we are making a complex extension to ASDF to fix
> problems that are easy for library maintainers to debug, and can have
> side effects that will be difficult to debug.  That doesn't seem like a
> good cost/benefit tradeoff.
>
> I'm willing to be persuaded, but I need an "elevator pitch" that
> addresses these issues head on.
> * What exactly are we fixing? and
> * Why is ASDF the right place to fix this? with the correlate
>  * Isn't an ASDF fix more complicated than just making libraries that Do
> The Right Thing?
>
> Again, I'm not dead set against this, but I just don't Get It yet.
>
> thanks,
> r
>