[asdf-devel] source file encoding

[Faré]

On Thu, Mar 22, 2012 at 10:31, Robert Goldman <rpgoldman at sift.info> wrote:
> Sorry --- I am catching up on this discussion after a long time doing
> other things.  Looking things over, I was left with some questions (I
> hope these haven't been thoroughly discussed and I missed the answers):
>
It's all a slow thing, anyway.

Note that I already merged Orivej's patch (with modifications) into 2.20.2.

NB: we need to add tests to the test suite before release —
and not just for SBCL and CLISP.

> Is there some reason why we must put the external-format into the
> property list instead of just giving it a slot in the component class
> definition?
>
Indeed that bugged me a little bit. At first, I thought the idea was
to use :properties (:external-format :iso-8859-1) or some such,
and let .asd files be backwards compatible with older versions of asdf.
If the idea is to use :external-format :iso-8859-1 instead directly
in the component form and require users of given systems
to upgrade to asdf 2.21 or later
(e.g. using :defsystem-depends-on ((:version :asdf "2.21")))
then it doesn't make sense to use properties, and instead we should
use a slot just like for :around-compile
(which has the same inheritance mechanism).

> Also, what sort of an entity are the external format values?  Is it
> always a keyword symbol?  Can we say that it should always be a keyword
> and that we will massage it to something else, if necessary, for the
> benefit of the implementation when reading a file?
>
Yes, making it a symbol sounds like a good idea, especially since
(1) defsystem forms are wholly read before any defsystem-depends-on
 is evaluated and is given the chance to create another package,
 much less define functions to use in #.
(2) defsystem forms are directly processed by the do-defsystem function,
 which doesn't itself include any mechanism for macroexpansion
 or programmability.

Of course, every implementation has its own variants for accepted keywords
(or not a keyword, in the case of clisp), and we do NOT want to pull all
a (big, and possibly ever changing) external-format library into ASDF.
Therefore, what we want is:
(1) provide a sensible default. Probably :default, or :utf-8.
(2) provide a hook onto which a library that is defsystem-depends-on'ed
 can define a translation layer between some standard keyword interface
 e.g. one or many of :latin1, :latin-1 or :iso-8859-1, and
 whatever the implementation actually wants, e.g.
 #+sbcl :latin1 #+clisp charset:iso-8859-1 ...

I'd say we're not ready for release 2.21 until we have
(1) a coherent interface, either through properties or its own slot.
(2) a good story on backwards-compatibility or lack thereof
 (so when there's breakage, error messages will clearly direct the user
 onto which component needs to be updated.)
(3) a sane default. I believe :utf-8 it should be on all modern platforms
 and whatever doesn't break too bad on legacy systems
 (genera, gcl, cormanlisp, mcl)
(4) tests that exercise said functionality and pass on all systems.
(5) a hook to allow for portable extension
 of the set of defined external-formats, by, e.g. babel.
(6) tests for this extension.

Note: I believe we should create a new test suite alongside the current one;
the new test suite would use a master process and slaves processes
(using inferior-shell), and hopefully a test tool that's portable to all our
target platforms (at least all those covered by the current test suite).

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Classical liberalism is not an economic doctrine. It is a theory of Law.