Re: Perl Peeves

"PJH" == Peter J Holzer <hjp-usenet2@xxxxxx> writes:

>> Original C compilers had an easy way of doing conditionals; they would
>> assign a variable to a register and then branch on the Z flag.

PJH> This may have been true on the PDP-11, although I doubt it. It certainly
PJH> wasn't a common feature of CPUs at the time. Most only set the flags as
PJH> the result of some computation, not a simple MOV. (There is a special
PJH> TST instruction to set the status flags depending on the contents of a
PJH> register)

as someone who did tons of pdp-11 assembler work, let me clarify some
things (as well as my faulty ancient ram can do). the 11 had registers
but could directly access any ram location for any major op (of which
there weren't that many :). you didn't have to load into a reg to do a
test/branch (unlike risc designs or old 8 bitters). and yes, it did have
the Z bit so you could test for zero or not zero (along with negative
and overflow). the coolest thing was to do a test (or look at the
results of an op that set the flag bits) and do more than one branch on
the results. such as decrementing towards zero. branch on zero first to
handle a counted down (e.g. a timer) value. then branch on negative to
handle a overcounted value (i would set a timer value to 0 so the next
tick down to a negative would disable it). then fall through to handle
the positive case (not finished counting down).

MOV didn't set the flags since it didn't do any real operation. there
was a TST op just to set the flags based on a single value with no op
being done.

and yes, the ++/-- ops and c's early handling of 0/not-0 were inherited
from the 11. and so perl can claim inheritance from the pdp-11 and dec's
genius in designing its instruction set. still my fave of all time. not
the most powerful, but the most elegant given its goals and

PJH> If (-2 > 0) is true that's pretty broken by any measure. If a
PJH> compiler produces a different result than the C specification
PJH> says it should, it is still broken.

that would be very nasty. it implies using the SUB op for GT/LT
comparisons which is not cool at any level. i know it was done in
assembler but the Z flag was checked for comparisons, not the negative
flag. if some compiler decided to use the actual result for the boolean
value and it was used in an expression, you already said it gets nasty.

>> Perl does not treat scalars as integers and so it's conditionals are
>> more complex (and yes hacky) than C. Especially the one you don't
>> like, which is defining the behavior of a string being used in a
>> condition.

PJH> Who said I don't like it? I never said such a thing. I don't even think
PJH> it is very complex. The number 0, the strings '' and '0' and the undef
PJH> value are false, all other scalars are true.

i agree this is a simple and clear rule. why people fuss over it, i
don't know. let perl be perl. forcing a specific value to be the one
'true' false (sic :) is a waste of time and anal. it is like normalizing
for no reason and it bloats the code. even the concept of using the
result of a boolean test for its numeric or string value bothers me. a
boolean test value (of any kind in any lang) should only be used in a
boolean context. anything else is a slippery shortcut that makes the
code more complex and harder to read. saving a boolean and loading it
again is fine but the serialized format shouldn't matter. we are not
talking config files with a boolean entry here - that is another story.

PJH> day (in this case, why is the false value documented? The ''/0 mixture
PJH> is rather bizarre and it seems much more likely that one would like to
PJH> change that in some future revision of the language), or whether it is
PJH> simply undocumented because it's the same as in C and "people know that
PJH> anyway, so we don't have to write it down". (Perl documentation has
PJH> become more self-sufficient over the years, but originally it assumed a
PJH> lot of general Unix knowledge and there are still spots which are only
PJH> comprehensible if you have a background as a Unix/C programmer - this
PJH> might be one of them)

perl has the magic false of 0 and '' so it will DWIM and coerce as you
would expect given a numeric or string context. it is well defined and
bahaves cleanly. not much more to be said but you two can keep fighting.


Uri Guttman ------ uri@xxxxxxxxxxxxxxx -------- --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- ---------
--------- Gourmet Hot Cocoa Mix ---- ---------

Relevant Pages

  • Re: FAQ 4.3 Why isnt my octal data interpreted correctly?
    ... >> The perl documentation has little to say about numbers. ... PJH> As a sort of postscriptum to this thread: ... the only uses of that cpu it seems were ...
  • Re: Autovivification
    ... PJH> We may use a different definition of "lvalue". ... the lang in question is perl. ... autoviv at work. ...
  • Re: Perl Performance Tuning
    ... PJH> Uri Guttman wrote: ... o> This should be required reading for all Perl hackers, ... PJH> I agree with most of what you wrote but I have to comment on this: ... PJH> That's an excellent reason to use bit flags. ...
  • Re: Perl Performance Tuning
    ... PJH> Uri Guttman wrote: ... o> This should be required reading for all Perl hackers, ... PJH> I agree with most of what you wrote but I have to comment on this: ... PJH> That's an excellent reason to use bit flags. ...