On Tue, Jun 15, 2010 at 3:21 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi,
On Tue, Jun 15, 2010 at 2:05 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Mon, Jun 14, 2010 at 2:10 PM, Mark Evenson evenson.not.org@gmail.com wrote:
[Ticket #100 filed to track this issue][1].
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:
- don't fix it. State clearly that literal pathnames in source are
OS-dependent.
- 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.
- 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