Front page | perl.perl5.porters |
Postings from November 1999
Cc'd to: ilya@math.ohio-state.edu
In article <199911210756.CAA02439@monk.mps.ohio-state.edu>,
Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
>Yitzchak Scott-Thoennes writes:
>> I realise that this behavior is perfectly in accord with perlop/"Gory
>> details"/"Finding the end". That doesn't mean it's not a bug. It
>> just means that if it is a code bug it is also a doc bug.
>>
>> IMO, it also contradicts the beginning of perlop/"Gory details":
>> > When presented with something which may have several
>> > different interpretations, Perl uses the principle DWIM
>> > (expanded to Do What I Mean - not what I wrote) to pick up
>> > the most probable interpretation of the source.
>
>This is taken out of context.
I disagree. This reads to me like a "mission statement" for Perl
parsing. If one of the many detailed parsing rules that follow
violate this statement, then that is an indication that a modification
may be necessary.
>> A: "\c\"
>> B: "\c\"more string here"
>>
>> The question is, is the current incomprehesible behavior of string B
>> more important to maintain than following DWIM for "string" A?
>
>Perl uses a very simple rule to find an end of a quoted construct.
>All one needs to do is to learn it.
>
>Hope this help,
>Ilya
Thanks, I thought I already said I understand the docs and behavior
for finding the end of a quoted construct are in agreement.
But application of these rules of finding the end, left-to-right
parse, etc. leaves the \c\ construct without a clear meaning.
One of the following should be true in all cases:
1. \c\ produces a fatal exception
2. the second \ is a escape character and the following character is
the 'argument' to \c
3. the \ is the 'argument' to \c and the following character is unaffected
4. the behavior is undefined and a warning is given
Currently none of these is true.
The behavior is pretty close to number 3 except for a couple of odd cases:
[D:\]perl -wlne "print map {length,':',map {;' ',ord} split //} eval"
"\c\\"
2: 28 92
"\c\""
1: 98
exit
In the first case, the string seems to contain two characters: \c\ and \.
The anomaly is that the trailing backslash doesn't escape the ".
In the second case, the string should IMO end with the 2nd ". Instead,
the 2nd \ of \c\ escapes it, contrary to \c\ behavior elsewhere. Thus
the string becomes \c" -> chr((ord('"')-64) & 127) -> b.
Thread Previous
|
Thread Next