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

[Alessio Stalla]

On Tue, Jun 15, 2010 at 3:21 PM, Erik Huelsmann <ehuels at gmail.com> wrote:
> Hi,
>
> On Tue, Jun 15, 2010 at 2:05 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
>> On Mon, Jun 14, 2010 at 2:10 PM, Mark Evenson <evenson.not.org at gmail.com> wrote:
>>> [Ticket #100 filed to track this issue][1].
>>>
>>> [1]: http://trac.common-lisp.net/armedbear/ticket/100
>>
>> Thanks for officially tracking the problem. I think that "fixing" it
>> only for asdf is simple: just emit (parse-namestring "...") instead of
>> #P"...". That would allow to re-release 0.20 quickly. I can send a
>> patch tonight for that.
>>
>> 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.
>>
>> 3) dump-object for pathnames outputs a MAKE-PATHNAME form that
>> reconstructs the pathname component by component.
>
> I would definitely prefer (3), but that doesn't fix the general
> problem: what about objects which have pathnames as part of the
> serialization done by their MAKE-LOAD-FORM? [Or would dump-form also
> fix that?]

MAKE-LOAD-FORM returns a form, not a string. How that form is
translated to a string is another matter. I haven't looked at the
compiler, but I see no obvious reason for not combining MAKE-LOAD-FORM
with DUMP-FORM, if it's not already like that. Of course, the user -
as opposed to ABCL itself - will need to be informed that simply
PRINTing the load-form and later READing it on another OS might not
work.

Bye,
Alessio