You could specify an extension to Common Lisp that allows users to request read-only readtables, submit this as a CDR, and hope that CL implementations are willing to implement such an extension of the language, and then rely on that.
Pascal On 20 Feb 2013, at 22:44, Faré <[email protected]> wrote: > In 2.29.9, I pushed a change whereby ASDF keeps passing around whichever value > the two syntax tables are globally bound to, leaving on the user the > onus to not mutate > them in too destructive a way, yet without precluding a change. > > Allocation is for (copy-readtable nil) and (copy-pprint-dispatch nil) is > 1648 and 2192 bytes respectively on CCL 1.9 x86-64, and > more like 5300 and 10300 bytes on SBCL 1.1.3 x86-64. > rme suggests that 15KiB per .asd file is no big deal and we should > just bite the bullet. > > Others suggest that we should let users fail and keep out of the business > of binding syntax variables altogether. I'd agree if I didn't want to > eventually move > towards "pure" .asd files in a restricted standardized syntax as per > https://bugs.launchpad.net/asdf/+bug/541562 > > If only Common Lisp allowed to portably specify read-only tables, > I would just use that, and let users fail when they try to mutate them. > Unhappily, it doesn't, and therefore when some user mutates a global table, > it will end up causing pain for another user, not himself. > Or I could rely on SBCL being used a whole lot and indeed having > immutable such default syntax tables with understandable messages > to blame whoever tries to mutate those tables without rebinding them first, > and push for all implementations to similarly make them read-only. > > The jury is still out. Please voice your opinion. > > —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org > Statism is the secular version of salvation through faith: it doesn't > matter what bureaucrats do, only that they do it with good intentions. > > > On Wed, Feb 20, 2013 at 3:44 PM, Faré <[email protected]> wrote: >> Dear Common Lisp hackers, >> >> Inspecting with Anton Vodonosov the latest batch of cl-test-grid issues >> when running with asdf 2.29.x, we found an interesting case >> that mirrors the previous failure of iolib 0.7.3 with 2.29. >> >> In the hope of making the semantics of asd files more deterministic, >> with an eye on eventually making .asd files a strict subset of Lisp, >> I had put in 2.27 a with-standard-io-syntax around the loading of a .asd >> file. >> However, this is specified to bind *readtable* and *print-pprint-dispatch* >> to standard tables that are notionally read-only, >> though this immutability is NOT enforced on most implementations, >> instead there being unspecified bad consequences if you do mutate. >> >> So, I could conceivably (copy-readtable nil) and (copy-pprint-dispatch nil) >> every time, but that could be expensive on some implementations. >> Or I could say "it's the programmer's responsibility to ensure a proper >> table has been setup before he modifies it", >> but that would be harsh and a notable backward incompatibility >> (and there's no equivalent of named-readtables for pprint-dispatch). >> Or I could preserve the current semantics of a global table >> that everyone modifies causing "interesting" issues, by rebinding >> *print-pprint-dispatch* as well as *readtable* within the w-s-i-s, >> only ensuring that the other syntax variables are standard. >> Or I could remove the with-standard-io-syntax altogether, and say >> "yes, if you're doing any global modification, you suck and you're >> going to break something for someone, but that's none of my business". >> >> Anton leans for the latter. >> >> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• >> http://fare.tunes.org >> One can be so anxious to put his "best foot forward" that he doesn't even >> notice that it isn't his own foot. — Harry Browne (HIFFIAUW) > > _______________________________________________ > asdf-devel mailing list > [email protected] > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel -- Pascal Costanza _______________________________________________ asdf-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
