In Perl5, the meaning of the undef value is overloaded. It can mean
either the value an uninitialized variable or it may indeed mean a
genuine undefined value. Perl5 is biased toward the first meaning: in
string context, the value behaves as an empty string; In integer
and float context, it respe
Please, let us agree to use the traditional name of "environment variables" in
the docs, and not re-introduce its bastardized cousin, which hurts my ears.
Thanks.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
http://www.stonehenge.com/merlyn/>
Perl/Unix/security
On Sat, Apr 29, 2006 at 07:50:02AM -0700, Randal L. Schwartz wrote:
> Please, let us agree to use the traditional name of "environment variables" in
> the docs, and not re-introduce its bastardized cousin, which hurts my ears.
> Thanks.
I think they are different things. An "environment variable"
> "james" == james <[EMAIL PROTECTED]> writes:
james> I think they are different things. An "environment variable" is
james> something in %*ENV. An "environmental variable" is a variable which
james> was declared with env $foo, and which can be seen by callers.
If they both have "env"-ish
> 16:50 < audreyt> Juerd: write to p6l and explain the ".." conflict,
The current long dot consists of a dot, then whitespace, and then
another dot. The whitespace is mandatory, which makes the construct at
least three characters long. Tripling the length of an operator, just to
make it alignable,
Author: autrijus
Date: Sat Apr 29 08:27:29 2006
New Revision: 9004
Modified:
doc/trunk/design/syn/S02.pod
Log:
* S02: Change the section headings "Atoms" and "Molecules" to the more
descriptive "Lexical Conventions" and "Whitespace and Comments".
Reported by: Wassercrats
Modified: doc/tru
I get a message like this for every message that I send to this list.
Trying to contact [EMAIL PROTECTED] did not result in response or change.
Any ideas?
- Forwarded message from sbc sbc <[EMAIL PROTECTED]> -
From: sbc sbc <[EMAIL PROTECTED]>
Date: Sat, 29 Apr 2006 08:31:24 -0700 (PDT)
On Sat, Apr 29, 2006 at 05:59:37PM +0200, Juerd wrote:
> I get a message like this for every message that I send to this list.
> Trying to contact [EMAIL PROTECTED] did not result in response or change.
>
> Any ideas?
Forward that message (with full headers) to [EMAIL PROTECTED]
who will then app
Juerd wrote:
Audrey cleverly suggested that changing the second character would also
work, and that has many more glyphs available. So she came up with
and propose ".:" as a solution
$xyzzy.:foo();
$fooz. :foo();
$foo. :foo();
This would make the enormous semantic difference
On Sun, Apr 30, 2006 at 10:49:45 +1000, Damian Conway wrote:
> This would make the enormous semantic difference between:
>
>foo. :bar()
>
> and:
>
>foo :bar()
>
> depend on a visual difference of about four pixels. :-(
You're not counting the space around the dot, which counts
On Sat, Apr 29, 2006 at 18:12:34 +0100, Nicholas Clark wrote:
> On Sat, Apr 29, 2006 at 05:59:37PM +0200, Juerd wrote:
> > I get a message like this for every message that I send to this list.
> > Trying to contact [EMAIL PROTECTED] did not result in response or change.
> >
> > Any ideas?
>
> For
On Saturday 29 April 2006 16:58, Yuval Kogman wrote:
> On Sun, Apr 30, 2006 at 10:49:45 +1000, Damian Conway wrote:
> > This would make the enormous semantic difference between:
> >
> >foo. :bar()
> >
> > and:
> >
> >foo :bar()
> >
> > depend on a visual difference of about four
On Sat, Apr 29, 2006 at 19:03:28 -0700, chromatic wrote:
> Two invisible things look completely different to you?
If dots looked like this:
then they would be invisible.
--
Yuval Kogman <[EMAIL PROTECTED]>
http://nothingmuch.woobling.org 0xEBD27418
pgplPt8CiApME.pgp
Description: PGP si
Damian Conway wrote:
Juerd wrote:
> Audrey cleverly suggested that changing the second character would also
> work, and that has many more glyphs available. So she came up with
>
>> and propose ".:" as a solution
> $xyzzy.:foo();
> $fooz. :foo();
> $foo. :foo();
This would make the
On Saturday 29 April 2006 18:29, Yuval Kogman wrote:
> If dots looked like this:
>
>
>
> then they would be invisible.
Use a laptop with a speck of dust in the wrong place in slightly wrong
lighting and the wrong four pixels might as well be invisible.
Precious few of @Larry deserve the nicknam
Damian Conway wrote:
> Juerd wrote:
>>> and propose ".:" as a solution
>
>> $xyzzy.:foo();
>> $fooz. :foo();
>> $foo. :foo();
>
> This would make the enormous semantic difference between:
>
>foo. :bar()
>
> and:
>
>foo :bar()
>
> depend on a visual difference of
Audrey Tang wrote:
>Damian Conway wrote:
>
>
>>Juerd wrote:
>>
>>
and propose ".:" as a solution
>>>$xyzzy.:foo();
>>>$fooz. :foo();
>>>$foo. :foo();
>>>
>>>
>>This would make the enormous semantic difference between:
>>
>> foo. :bar()
>>
>>and:
Good (and floating) point.
Boom boom! ;-)
How about this:
$antler.bar;
$xyzzy.:bar;
$blah. .bar;
$foo. .bar;
That is, introduce only the non-space-filled .: variant, and retain the
space-filled long dot.
But do we really need *three* distinct forms of method call, in addition to
the (eas
Author: autrijus
Date: Sat Apr 29 23:39:39 2006
New Revision: 9029
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: aufrank++ pointed out the quicksort example was still
using the (?$foo) form in Sigs instead of ($foo?).
Modified: doc/trunk/design/syn/S06.pod
=
19 matches
Mail list logo
