[armedbear-devel] #P serialization across Windows/non-Windows (was Re: r12666 breaks ASDF compilation on Linux)

[Alessio Stalla]

On Thu, Jun 17, 2010 at 8:11 AM, Mark Evenson <evenson at panix.com> wrote:
> On 6/15/10 2:05 PM, Alessio Stalla wrote:
>
> […]
>
>> Eliminating the problem in the general case is harder and we'd better
>> discuss the possible solutions. Here's my take at it:
>>
>> 1) don't fix it. State clearly that literal pathnames in source are
>> OS-dependent.
>>
>> 2) keep, for each pathname constructed via #P or parse-namestring, the
>> string passed by the user, until the pathname is destructively
>> modified. When dumping it, use that string if available, else warn and
>> use a calculated string.
>
> I still don't understand how this approach solves the problem with ASDF.
>  Wouldn't we still have the failure on non-Windows when "\foo\bar" is
> passed to the #P reader?  Namely, that it would be interpreted as:
>
>    {
>      directory: nil,
>      name: "\foo\bar"
>    }
>
> What is the point of the "destructively modified" condition?
>
>> 3) dump-object for pathnames outputs a MAKE-PATHNAME form that
>> reconstructs the pathname component by component.
>
> I was thinking about
>
> 4)  Code a heuristic in the Pathname.init(String) that attempts to
> interpret a Pathname from the other platform by converting all '\' to
> '/'.  Add something
>
> a)  If the Pathname begins with '\\'
>     i) if win interpret as UNC server
>     ii) non-win signal a CONDITION
>
> b)  convert all '\' to '/'
>
> c)  run the rest of the current init()
>
> On win, the init() code (line 403++) will convert the '\' back to '/'.
>
> A problem arises for non-win Pathnames that contain true '\' characters
> in a directory/file name, which then will have no pathname<-->namestring
> roundtripping.  It should still be possible to construct such shaggy
> monsters via MAKE-PATHNAME.
>
> As for load forms, I think simply marking the namestring as "transient"
> (i.e. not persisting it) will do the right thing as on first access it
> will be re-computed to the proper local conventions.
>
> This still doesn't completely address the presence of win-specific
> Pathname components (HOST with a UNC server, DEVICE with a single
> character string [A-Z]) in non-win.   Signal a CONDITION when this is
> detected?
>
> N.B.  All the above written without benefit of testing with ABCL, as my
> wrist still precludes heavy use of Emacs.

Yesterday Erik and I discussed this on IRC and we came up with a
possible solution.

Fact 1: the problem is only related to how pathnames are
printed/serialized. Find a way to print them in a platform independent
way (one which ABCL can read back, of course) and the problem is
solved.

Fact 2: the string representation of pathnames is completely
implementation-dependent.

Fact 3: pathnames already can (and sometimes do) print themselves as a
property list enumerating the components, for example #P(:name "foo"
:directory (:absolute "bar" "baz")) - which is not ANSI compatible, by
the way.

Proposed solution: let's invent an ABCL-specific way to print
arbitrary pathnames. I proposed #P"abcl:(make-pathname ...)" which is
ANSI-compatible and similar enough to what the current code in
Pathname.writeToString can produce. Let's use that to print
pathnames[1]. Reading them back is as simple as (eval
(read-from-string ...)), and no other code needs to be modified.

What do you think?

[1] if not always, at least with dump-form, and when *print-readably*
is T and the namestring can't be used. In the latter case currently
the #P(...) syntax is used. Btw, probably dump-form *should* bind
*print-readably* to T...

Alessio