On Fri, Mar 6, 2009 at 03:31, "Stanisław T. Findeisen"
<sf181...@students.mimuw.edu.pl> wrote:
> Chas. Owens wrote:
>>
>> SOME_CONSTANT is being interpreted as the string "SOME_CONSTANT".
>
> Why is it so? This is crazy.

Because it is nicer to say $hash{key} than $hash{"key"} and Perl is
optimized for the common case.  When you look at any language you find
design choices that are odd.  The constants manufactured by the
constant pragma are really 0-ary functions:

sub SOME_CONSTANT() { return "some value" }

>
>> This is one of the drawbacks to the constant pragma.  Change the code
>> hash keys to one of these and it will work the way you want it to:
>>
>> $hash{+SOME_CONSTANT} #unary plus
>
> What is this unary plus?
snip

Unary plus is the opposite of unary minus: -10, +10.  In Perl 5 unary
plus doesn't do anything to its argument regardless of what type its
arguments has (list, number, string, reference, etc.).  This makes it
useful as an aid to telling Perl's parser you don't mean what it would
normally assume.  For instance, examine this code:

print ("x" x 10), " foo ", ("x" x 10);

It is obvious to a human that we want to print all three items, but
Perl only prints the first.  This is because Perl sees the first set
of parentheses as part of the function call.  With the addition of
unary plus:

print +("x" x 10), " foo ", ("x" x 10);

Perl can see that the first parentheses are not part of the function
call because + is not allowed in the middle of a function call and
unary plus (by definition of the operator) has no affect on ("x" x
10), so the code executes the way want it to.  It is also one of the
characters that is not allowed in a "bareword".  Barewords do not need
to be quoted in hashes and before the fat comma (=>).  This is because
it looks nicer that way and most keys are barewords.


snip
> Thanks. Hmm, they say it is slow
> (http://search.cpan.org/dist/Readonly/Readonly.pm#CONS).
snip

No, they say constant hashes and arrays are slow, scalars are as fast
as normal scalars.  This is because scalars are implemented using
normal Perl scalars with a flag set that sets to raise an error if
anyone tries to modify it.  Hashes and arrays are implemented through
tie and therefore have an extra layer of indirection associated with
each access.

snip
> Why aren't there constants in the language itself?? This is crazy.
> Also: is that true that Perl's specification is its implementation by Larry
> Wall? This is even more crazy. :-/
> A language and its implementation are (should be) 2 different things!
snip

For the same reason the const keyword wasn't part of K&R C: nobody
thought about it at the time.  Later people realized they wanted
constants and created a facility to get them.  You seem to be laboring
under the impression that languages should be designed carefully for
years, then implemented.  Perl 1 was little more than a commandline
utility, people found it useful, but limited, so they started adding
features until we got here.  This means there are lots of blind alleys
in the design.  Constants can be considered one.  The way prototypes
work in Perl is another.  The benefit of this style of development is
that it encouraged experimentation with the language without leading
to multiple incompatible languages.  Find me a non-trivial Common Lisp
program that doesn't rely on one specific implementation of Common
Lisp.  How do I make an non-blocking read of one character in ANSI C?
Specifications tend to be incomplete and slow to evolve.  So
implementers start making custom changes.  And now you have multiple
languages that mostly look like each other but behave differently in
some cases.

Perl 6 is different.  As a community, we have stepped back and are
reexamining the language and attempting to make a clean specification
that retains the flavor of Perl 5 while correcting its defects.  There
are already competing implementations of the incomplete spec (Rakudo,
Pugs, etc.).  Time will tell if having multiple implementations turns
out to be a good or bad thing (my bet is that it will be a mixed bag
of bad and good).

snip
> I'd expect equal hash keys to map to equal values.
> I'm a conservatist. :-)
snip

Ah, but they do, you just didn't hand the hash equal values.


-- 
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/


Reply via email to