Prev: ECL 10.3.1
Next: Utility to swap Caps Lock as Control key, or swap Control with Alt
From: Zach Beane on 14 Mar 2010 11:42
Duane Rettig <duane(a)franz.com> writes:

> On Mar 13, 6:15 pm, Zach Beane <x...(a)xach.com> wrote:
>> Duane Rettig <du...(a)franz.com> writes:
>> > On Mar 13, 11:12 am, Zach Beane <x...(a)xach.com> wrote:
>> >> p...(a)informatimago.com (Pascal J. Bourguignon) writes:
>>
>> >> > Rainer Joswig <jos...(a)lisp.de> writes:
>> >> >> 19.3.1.1.7
>>
>> >> >> When parsing words and wildcard-words,
>> >> >> lowercase letters are translated to uppercase.
>>
>> >> > All right.  So logical pathnames are case insensitive.  Good to know.
>> >> > Thanks.
>>
>> >> Last time I checked, Allegro CL gets this wrong.
>>
>> > This may be the case (pun intended :-). It is hard to get the :local
>> > mappings of pathnames correct for the various styles of filenames
>> > (e.g. case sensitive on Unix, and case-insensitive-preserving-original
>> > on Mac and Windows).
>>
>> It seems like this is a problem only if you want some translations to be
>> automagic. If you are explicit with every translation, you don't have to
>> worry local case conventions, right?
>
> The "automagic" part is precisely what should be intended in the
> spirit of logical pathnames. Otherwise, why would you need logical
> pathnames over just pathnames?

My impression is that they're to provide an application with a (ahem)
logical virtual filesystem that is independent of the physical pathnames
actually involved, and the primary benefit is to be able to rearrange or
override the physical layout by changing the translations rather than
the pathname-using code.

> You could just name all of your pathnames using regular pathnames, and
> do all of the translations to account for operating system differences
> programmatically.

You also use logical pathnames and generate translations
programmatically.

>> >  However:
>>
>> >> In fact, their
>> >> documentation on logical pathnames reeks of "this part of the standard
>> >> seemed stupid so we made it easy to make incompatible use of them." It
>> >> dismays me.
>>
>> > Please show me such documentation - I'd like to see where you find
>> > this attitude anywhere in our docs.  There are certainly places where
>> > we allow extensions to logical pathname parsing; for example, the spec
>> > doesn't allow the inclusion of underscores in a logical pathname, and
>> > so we allow an extension, if a variable is set, which allows a
>> > namestring with an underscore in it to be parsed as a logical
>> > pathname.  But in reading that documentation I get no sense of "the
>> > standard seemed stupid" - it does seem very restrictive to disallow
>> > one character that occurs quite often in Unix and C names, but if we
>> > allow users to set a variable and use that character, do you consider
>> > that thumbing our nose at the spec?
>>
>> I do. It defeats the purpose of a precise and complete specification of
>> the syntax of logical pathnames. If a character appears in a physical
>> pathname that isn't allowed in a logical pathname, it seems to me that
>> the right reaction is to create a translation, not allow non-standard
>> implementation-specific syntax to creep into the pathname literals in
>> the source.
>
> It may seem that way to you, but many of our customers that use
> logical pathnames don't like that restriction at all, and do indeed
> use such a feature, to avoid having to mess with such translations.
>
>>   Many have found this restriction onerous. Because actual work is
>>   typically done on just a few platforms, forbidding characters such as
>>   an underscore (_), which in fact causes no problems on any popular
>>   platform, contributes nothing to actual portability and adds
>>   additional development rules whose purpose (to non-Lisp programmers
>>   and to many Lisp programmers) is obscure.
>>
>> In particular, I find "contributes nothing to actual portability"
>> extremely obnoxious, as breaking this restriction introduces real
>> problems with actual portability to implementations that choose to take
>> the spec at face value and implement it as written.
>
> Why should that be the case?

Because people use features specific to Allegro LPNs without realizing
it.

> If you want to be portable between CL implementations, don't use
> underscores, and don't turn on the feature that allows the nonportable
> code.

That would work if I was the original author.

> It is exactly like any other extension to a CL implementation.

It would be a little like Allegro's CL:STRING-CAPITALIZE returning
"Don't" when passed "don't", and having someone rely on that reasonable
behavior without realizing it's contrary to the specification.

> If your argument is that a user who takes advantage of this extension
> is tied to one lisp, then that's the same kind of decision that a user
> must make about any other such extension. If you think the extension
> is a crock (and that's perfectly OK) then don't use it.

People use it without realizing the portability issue.

Zach
From: Zach Beane on 14 Mar 2010 21:31
Zach Beane <xach(a)xach.com> writes:


>>> In particular, I find "contributes nothing to actual portability"
>>> extremely obnoxious, as breaking this restriction introduces real
>>> problems with actual portability to implementations that choose to take
>>> the spec at face value and implement it as written.
>>
>> Why should that be the case?
>
> Because people use features specific to Allegro LPNs without realizing
> it.

On rereading the documentation, I see I mixed up the mixed-case issue
with the additional-allowed-characters issue, and I can see now someone
would be quite unlikely to use forbidden-by-the-standard characters
accidentally. And the mixed case issue can be easily solved with
exhaustive translations. Sorry for the noise.

Zach
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: ECL 10.3.1
Next: Utility to swap Caps Lock as Control key, or swap Control with Alt