Larry Wall wrote:
On Fri, Sep 17, 2004 at 07:35:46PM +0100, Richard Proctor wrote:
: Therefore should:
:
: $?os Be which operating system it is being compiled on
: $*os Be which operating system it is being executed on
:
: Some of the other special variables may have a similar dual personality.
Presumably. Which presents an interesting problem, because we
currently have things defined like $*PID, not $*pid. Either we
have to lowercase the $* variables, or uppercase the $? variables,
or decide that it's okay for them to be different. It's probably
important to keep $*PID uppercase because of the way they can leak into
any other namespace as $PID. The same does not hold true for $?line.
On the other hand, people are used to __LINE__ already, so maybe $?LINE
isn't so bad, and lights up better as a weird unit with a rectangular
shape, something you might see as a funny symbol in a macro assembler.
Which is more or less what it is.
I originally made them lowercase because they were $=line variables
and I didn't want them to conflict with POD names that are typically
uppercase, and use of an C<=> secondary sigil for POD is a no-brainer.
But that no longer applies when they have their own ssigil, or sigil2,
or 2igil. I guess that would be pronounce "twidgle".
For that matter, what's wrong with $__ as a sigil, as in $__LINE__, et
al. It combines the "you can use it as a variable" with the "leading
underscores are magic" memes, and doesn't impose any wierd learning curve.
=Austin
Larry
