Re: [Sbcl-devel] Pathnames on MS windows

[Marco A. <ma...@cs...>]

Just making a shameless plug...  Did you have a look at NAMES-AND-PATHS on common-lisp.net (it points elsewhere, but it is there...)

Cheers
--
Marco





On Aug 24, 2011, at 21:10 , Anton Kovalenko wrote:

> Nikodemus Siivola <nik...@ra...> writes:
> 
>>> I will miss host objects, unless there will be some official way to hook
>>> into name-parsing process without a "hard" function redefinition.
>>> (physical host object provided me with this facility as a "backdoor").
>> 
>> I don't really object to host objects, but to PATHNAME-HOST returning
>> a host object.
> 
> (Object-oriented English becomes hard to parse, even if no objection is
> raised :\)\)\))
> 
>> I think I'd prefer there to be a
>> 
>> (define-pathname-host <name> ...)
>> 
>> thing, after which (find-pathname-host <name>) would return the host
>> object, or something along those lines. I don't mind storing a pointer
>> to the host object in the pathname either.
> 
> While there is certainly nothing wrong with it from an abstract point of
> view, and nothing non-conforming either, the option of not touching this
> area has an important practical merit (official SBCL team is probably
> just too humble to notice it).
> 
> People adapt to existing CL implementations, especially when given
> enough time, and especially to widely known implementations with a huge
> impact, like SBCL (or its ancestor CMUCL). Are there really /any/
> developer, among those who care about portability at all, who doesn't
> have SBCL in his top-3 potentially supported targets? 
> 
> Hence it's not unreasonable to expect that a lot of people adapted to
> the current behavior of SBCL and its pathnames; their internals and the
> PATHNAME-HOST behavior is definitely "subject to change without notice",
> but I'd wait for some more compelling reason for it. Breaking actual
> portability for the sake of a theoretical future portability
> improvements doesn't look like a right thing.
> 
> It's not a random conjecture from my side; I'd be glad to bring good
> news (like, "no one is interested in physical hosts or relies on their
> presence"), but SBCL installations that I'm using /do/ a couple of
> things with physical hosts (e.g. I change customary case at startup by
> modifying *win32-host* for /most/ of my SBCL installations on Windows).
> 
> Of course, I won't be hurt by your proposed changes, and I will
> immediately begin to use a new exported interface if it allows to do
> what I'm doing now without poking into internals. However, if I'm not
> alone in making use of physical hosts, leaving the current details
> intact may be beneficial.
> 
> (I have once read an interesting essay on some reformational and
> revolutionary attempts at teaching math to children, with a conclusion
> that an ongoing flux of reforms has a chance to be worse than just /any/
> fixed curriculum, be it modern and post-revolutional /or/ ancient and
> classical; any /decided/ way to teach the math will eventually result in
> accomodation, with pupils /children / teachers /schools / parents / etc
> gradually adapting to it over time. Even a really mad way of teaching
> would become less harmful over time; the only thing that remains
> *reliably* harmful is an incessant stream of revolutions.
> 
> The same reasoning may be appropriate for parts of SBCL that are neither
> remarkably bad nor remarkably important).
> 
> -- 
> Regards, Anton Kovalenko
> +7(916)345-34-02 | Elektrostal' MO, Russia
> 
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management 
> Up to 160% more powerful than alternatives and 25% more efficient. 
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Sbcl-devel mailing list
> Sbc...@li...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel

--
Marco Antoniotti