Re: C or SH like string cat proposal

2001-04-26 Thread Michael G Schwern

On Wed, Apr 25, 2001 at 12:10:10AM -0500, David L. Nicol wrote:
 That means, if you have a long list of scalars rou want to cat
   together and it will run over the edge of your line
   you can do this:
 
   $onethroughten = $one$two$three$four$five
   $six$seven$eight$nine$ten;

I think the proper phrase here is ick.  To my non-C, non-Shell
programming eyes, that's just a confused jumble.  It'll also play hell
with trying to mix strings in there.  I could live my entire life
without seeing:

$foo = $one$two'three'$fourfive$six

 Will someone please explain to me the indirect object syntax
 which this allegedly steps on?

(The hellish abomination of ;) indirect object syntax works like this:

$obj = new Some::Module @args;

to mean

$obj = Some::Module-new(@args);

Any proposal which tries to use whitespace as a concatination operator
runs into its territory, but I don't think yours would cause problems
(except for the rash of patients admitted to local hospitals with
bleeding eyes).


-- 

Michael G. Schwern   [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED]   Kwalitee Is Job One
Let me check my notes...



Re: Curious: - vs .

2001-04-26 Thread Bart Lateur

On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:

the idea of a dereference operator dumbfounds lots
of folks. What's an object got to do with a reference, much less a
pointer? A p5 object is very confusing to others for this reason, and so
is the syntax.

So you want a method invocation syntax that doesn't remind people of
references. OK. But why does it have to be the dot? It is already taken.
Sorry. Use an operator that doesn't exist yet in Perl. For example, old
style VB used ! to connect objects and their properties:

label1!caption = Hi!

is the same as

label1.caption = Hi!


So why not

$object!method(foo, bar);

-- 
Bart.



Re: a modest proposal Re: s/./~/g

2001-04-26 Thread Bart Lateur

On Wed, 25 Apr 2001 18:19:40 GMT, Fred Heutte wrote:

Yes, I know ~ is the bitwise negation operator.  Have you EVER used it?

Yes. A lot.

But there is no conflict. ~ is currently just an unary operator, while
your use would be as a binary operator (are those the correct terms?).
For example, in

-3.4

and in

2-3.4

the - sign is a *different* kind of operator. No conflict.

-- 
Bart.



Re: Dot can DWIM without whitespace

2001-04-26 Thread Michael G Schwern

On Wed, Apr 25, 2001 at 08:33:33AM -0400, Stephen P. Potter wrote:
 How about symbolic refs to function names?
 
 $a = $x ? hop : skip;
 $b = $y ? scotch : soda;
 
 $a.$b;# call one of hop.scotch, skip.scotch, hop.soda, skip.soda

5.005_03 and under required parens after the method reference

$obj-$meth_name();

5.6.0 appears to have removed that requirement, but I don't see why
that couldn't be required again in Perl 6 to disambiguate if needed.


 | Alternately, we can overload . to do a deref on (blessed?) references, and
 | concat otherwise.
 
 I think this would lead to hard to find bugs when someone mispelled
 something.

I think it would also throw Dan into convusive fits.  Additionally, it
would make finding method calls lexically near impossible.  I'd like
to keep Perl 6 refactorable as much as possible.


-- 

Michael G. Schwern   [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED]   Kwalitee Is Job One
BOFH excuse #356:

the daemons! the daemons! the terrible daemons!



Re: Dot can DWIM without whitespace

2001-04-26 Thread Michael G Schwern

On Wed, Apr 25, 2001 at 07:23:47PM -0700, Edward Peschko wrote:
 On Thu, Apr 26, 2001 at 03:16:46AM +0100, Simon Cozens wrote:
  SPACE SENSITIVE and SOME OF US HAVE TO TEACH IT. Do you understand yet?

Just for the record, I'm totally with Simon here.  Having . do triple
duty (decimals, method calls and string concat) will be hard enough to
teach.  Throw obscure whitespace rules in there and you'll spend all
day trying to explain it.


 The problem already comes up... '4. 5' is not the same as '4.5'. '.' 
 is *already* doing double duty as decimal mark. The fact that you
 don't see this very often shows exactly how rare the mistake arises.

Most people, by around first grade, understand that 4.5 is a number.
4. 5 is (thank goodness) a syntax error, so any confusion is
resolved immediately.  '4 .5' for some reason is not, but as Casey
pointed out that's probably a parsing hiccup.

Additionally, its pretty damn rare for anyone to want to concatenate
two bare numbers.


 I think the 'tutorial' will come from experience. When the error
 that you get from $a.$b comes up (and it should be a syntax error)
 you'll see exactly what is wrong. If $a. $b, again, syntax
 error. Only $a . $b should be allowed.

 The only point of contention would be if someone said $a . b, when they meant
 $a.b. And how often will that occur?

Very often, because I'd expect $a.$b to work and be very surprised
when it fails!  Very little else in Perl is white-space sensitive
without very good, fairly obvious reasons (as with decimal numbers
above), let's avoid it here.


-- 

Michael G. Schwern   [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED]   Kwalitee Is Job One
They just don't make any good porn music anymore, do they?
- WXDX DJ refering to More, More, More



Re: a modest proposal Re: s/./~/g

2001-04-26 Thread Fred Heutte

Bart Lateur's response summarizes well what I've heard so far
from responses both to the list and privately:

(1) Yes,  ~  *is* somewhat used in its current role as the bitwise
negation (complement) operator.

(2) No, that doesn't appear to overlap my proposal for its use
as a successor to  -  as now used.

Another cheer for the principle of least disturbance from the
Laziness SIG...




Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-26 Thread Bart Lateur

On Wed, 25 Apr 2001 06:09:56 -0700 (PDT), Larry Wall wrote:

Bart Lateur writes:
: Er... hip hip hurray?!?!
: 
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs.

: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?

$foo{THERE} always means the hashref in $foo.  %foo{THERE} always means
the hashref in %foo.  %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref.  foo by itself in
a scalar context means a coderef.  It's gonna be pretty consistent.

Yeah. But no cheers then. The problem still remains: you can access a
hash in the normal way in plain code, but inside a sub, you can mainly
only access a passed hash through a reference.

It's annoying to basically having two ways of doing something, and one
of them can't be used half of the time.

Even though @foo and %foo may be two different structures, a scalar $foo
can only reference one of them at a time.

Are you going to provide a simpler aliasing mechanism to turn a hash
reference, for example as passed to a sub as an argument, back into the
full-blown hash? Simpler (and safer) than the much frowned upon
assignment to a tyeglob, that is.

-- 
Bart.



Re: Dot can DWIM without whitespace

2001-04-26 Thread Dan Sugalski

At 09:16 AM 4/26/2001 +0100, Michael G Schwern wrote:
On Wed, Apr 25, 2001 at 08:33:33AM -0400, Stephen P. Potter wrote:
  | Alternately, we can overload . to do a deref on (blessed?) references,
  | and
  | concat otherwise.
 
  I think this would lead to hard to find bugs when someone mispelled
  something.

I think it would also throw Dan into convusive fits.

Nah. Not convulsive ones, at least. (I'll work from the example Jon Orwant 
set instead... :)

Additionally, it
would make finding method calls lexically near impossible.  I'd like
to keep Perl 6 refactorable as much as possible.

While it doesn't argue for or against the current period issue, figuring 
out what code really does is more the provence of the parser rather than 
analysis code. ('Specially since a single use could potentially throw 
things subtly out of whack)

Which means we really ought to have hooks into the parser, or a tool to 
analyze the unoptimized bytecode from the parser, to do this sort of thing. 
B::Deparse for perl 6, say.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk




Re: Curious: - vs .

2001-04-26 Thread Dan Brian

 the idea of a dereference operator dumbfounds lots
 of folks. What's an object got to do with a reference, much less a
 pointer? A p5 object is very confusing to others for this reason, and so
 is the syntax.
 
 So you want a method invocation syntax that doesn't remind people of
 references. OK. But why does it have to be the dot? It is already taken.
 Sorry. Use an operator that doesn't exist yet in Perl. For example, old
 style VB used ! to connect objects and their properties:
 
   $object!method(foo, bar);

It doesn't have to be the dot. But the plain fact is that the dot is
generally recognized in this way; why is making Perl syntax more
recognized a bad thing? If what we're after is making Perl better, then
one of the primary improvements should be making objects more readable for
the multi-language programmer. I'm really not against '-', but then
again, I *like* that
an-object-is-a-reference-which-means-I-can-poke-and-prod-it-and-embed-it-etc.
Even so, I recognize that it doesn't make Perl more readable, especially
when glob syntax is used to manipulate the reference table.

A traditionally negating symbol ('!') is the last character I would want
to see. As for VB  ;)




Re: s/./~/g

2001-04-26 Thread Jon Ericson

Fred Heutte [EMAIL PROTECTED] writes:

 A vote against the proposed switches, for an unbearably lazy (ok,
 selfish) reason.  Having to use the shift key with any non-alphanumeric
 keypress always feels like a lot of extra work.  This is why I have long
 avoided underscores in variable names.  (This is the same reason
 I avoid = which not only adds another keystroke beyond , but also has
 the dreaded punctuation-key-shift.  I'm not arguing this is *better*,
 just more convenient for me personally.  Or maybe it's just that I prefer
 not to hang around too much with shifty characters.)  

The 'fat-comma' actually saves keystrokes and looks good for creating
paired data.  From perlop:

  The = digraph is mostly just a synonym for the comma
  operator.  It's useful for documenting arguments that come
  in pairs.  As of release 5.001, it also forces any word to
  the left of it to be interpreted as a string.
 
 Having used . for string concats for 10 years, I could adjust to ~
 but good golly is that annoying.  Also it does detract from readability
 a little.
 
 $a = my . $strings . join(@together) ;
 
 $a = my ~ $strings ~ join(@together) ;

Actually using a period to mean push these things together rather
than full-stop always seemed odd to me.  I use the concat operator
very rarely.  I would write the above:

  $a = my $strings @together;

(You weren't careful about spaces, but you need to be when using
concat.  String interpolation is easier to get right the first time.
Also I don't think your join is what you want.)

If I had to choose between . and ~, I'd take the tilde.  I wouldn't
mind if it went away altogether, however -- I only use it to simulate
function interpolation:

  $prompt = scalar(getpwuid $) . \n\$ ;

I'd rather write:

  $prompt = scalar(getpwuid $)\n\$ ;

 I don't mind ~ as the binding operator.  It makes me go slower and
 think, aha! drive carefully:
 
 $throttle =~ s/regex ahead/downshift brain/ ;

Jon




Re: Flexible parsing (was Tying Overloading)

2001-04-26 Thread Larry Wall

Eric Roode writes:
: John Porter wrote:
: IIUC, this ability is precisely what Larry was saying Perl6 would have.
: 
: I may have my history wrong here, but didn't Ada try that?

Not at all.  The syntax of Ada was nailed down tighter that almost any
language that ever existed.

: Super-flexible, redefinable syntax? And wasn't the result that nobody could
: read anybody else's code, so Standards Committees were set up to 
: define Legal Styles that basically reduced the syntaxes that you could
: use to just the One Standard Style?

Gee, you must be thinking of KR C.  :-)

In any event, I'm not worried about it, as long as people predeclare
exactly which variant they're using.  And I'm also not worried that
we'll have any lack of style police trying to enforce Standard Perl 6.

Larry



Re: Flexible parsing (was Tying Overloading)

2001-04-26 Thread Larry Wall

Dan Sugalski writes:
: And on the other hand you have things like Forth where every program 
: essentially defines its own variant of the language, and that works out 
: reasonably well. (Granted it's more of a niche language, especially today, 
: but that's probably more due to its RPN syntax)

Perhaps.  I would also attribute Forth's lack of success in part to its
lack of standardization, but only in conjunction with its lack of
standardization, if you take my meaning.  The core distribution was
too small to establish a common culture.  Despite the fact that we're
trying to pare down the actual core core of Perl, I don't think the
standard distribution is going to fall into the error of providing
too little guidance on cultural matters, if for no other reason than
we must minimally provide for translated Perl 5 programs.

I would also argue that Forth's diversity was driven in part by its
lack of support for other programming paradigms.  I don't see Perl
falling into that trap any time soon either...

Larry



Re: Flexible parsing (was Tying Overloading)

2001-04-26 Thread Jarkko Hietaniemi

On Thu, Apr 26, 2001 at 04:13:30PM -0700, Larry Wall wrote:
 Eric Roode writes:
 : John Porter wrote:
 : IIUC, this ability is precisely what Larry was saying Perl6 would have.
 : 
 : I may have my history wrong here, but didn't Ada try that?
 
 Not at all.  The syntax of Ada was nailed down tighter that almost any
 language that ever existed.

In a sick way I kinda liked how compilers were able to give out error
messages not unlike:

foo.ada: line 231: Violation of sections 7.8.3, 9.11.5b and 10.0.16: see the LRM.

(LRM being the Language Reference Manual.)  Truly coding by the book.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen



Re: a modest proposal Re: s/./~/g

2001-04-26 Thread Larry Wall

Nathan Wiger writes:
: Now, it may be that all the We should use . people are just keeping
: quiet, or think it's obvious why this is a benefit, but I'm unconvinced.
: Again, I'm open-minded, but the only argument I've really heard is to
: make Perl more Java/Python-like. This doesn't sway me at all. Are there
: other reasons?

Yes, there are, but I don't really want to write Apocalypse 12 before
I finish Apocalypse 2.  However, I can tell you that object attributes
will likely be declared as special variables within a class like this:

my $.foo;
my @.bar;
my %.baz;

and henceforth be usable as either methods or as data values (but the
latter only within the object methods of the class).  It is also a
distinct possibility that unary . will be used to indicate methods called
on the current object.  This would avoid both the problems of trying
to come up with an agreed-upon name for $self/$this/self/me/whatever,
but also avoid the problem of C++ where a method call is not visually
distinguished from a function call.

Anyway, I wish you folks would stop arguing about heroic measures to
rescue the . operator for concatenation.  It's not going to happen.
I want people to associate .foo with the idea of methods and attributes
about the way they associate $foo with scalars currently.  This won't
happen if we overload it, and I'm pretty picky when it comes to the
psychology of the thing.

And I'm tired of hearing the argument that Perl programmers can't get
used to a different operator for concatenation.  I know better--after
all, Perl is probably what got them used to . in the first place.  If
you can teach dogs to salivate at a bell, you can probably teach them
to salivate at a dog biscuit.  :-)

Larry



Re: YAYAYA string concat proposal

2001-04-26 Thread Fred Heutte

I have a different suggestion:

replace  -   with   ~

~  is already Perlish for glues to something related.

That's a different construct than concatenates.

Fred






Re: Curious: - vs .

2001-04-26 Thread Piers Cawley

Buddha Buck [EMAIL PROTECTED] writes:

 Bart Lateur [EMAIL PROTECTED] writes:
 
  On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:
  So why not
  
  $object!method(foo, bar);
 
 In my opinion, because it doesn't provide sufficient visual
 distinction between $object and method().  At a glance, especially on
 a crowded page, it's similar in appearance to $objectImethod, for
 instance.  $object.method() has a visual separator (although I'd
 prefer $object-method()).
 
 How about borrowing from Objective C?
 
[$object method(foo, bar)];

How do you create an anonymous list now then? Not that I object to
borrowing from Objective C you realise.

-- 
Piers Cawley
www.iterative-software.com




Re: Flexible parsing (was Tying Overloading)

2001-04-26 Thread Simon Cozens

On Thu, Apr 26, 2001 at 06:25:03PM -0500, Jarkko Hietaniemi wrote:
 In a sick way I kinda liked how compilers were able to give out error
 messages not unlike:
 
 foo.ada: line 231: Violation of sections 7.8.3, 9.11.5b and 10.0.16: see the LRM.

Ever used the Mac C compiler?
-- 
Language shapes the way we think, and determines what we can think about.
-- B. L. Whorf



Re: Curious: - vs .

2001-04-26 Thread Buddha Buck

Piers Cawley [EMAIL PROTECTED] writes:

 Buddha Buck [EMAIL PROTECTED] writes:
 
  Bart Lateur [EMAIL PROTECTED] writes:
  
   On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:
   So why not
   
 $object!method(foo, bar);
  
  In my opinion, because it doesn't provide sufficient visual
  distinction between $object and method().  At a glance, especially on
  a crowded page, it's similar in appearance to $objectImethod, for
  instance.  $object.method() has a visual separator (although I'd
  prefer $object-method()).
  
  How about borrowing from Objective C?
  
 [$object method(foo, bar)];
 
 How do you create an anonymous list now then? Not that I object to
 borrowing from Objective C you realise.

I thought ($one, $two, $three) was an anonymous list.

Seriously, I hadn't considered that their may be a problem with the
syntax I gave.

How would you, under Perl5, interpret the expression I used.  To me,
it looks like a syntax error.  '$object method(foo,bar)' isn't a
valid method call, so it can't be a ref to an anonymous list of one
value.

Other than severe dependence on the comma, is there any reason why we
couldn't have the following?


$foo  = [$one];   # array ref
$baz  = [$obj,funcall()  ];   # array ref
$quux = [$one,$two,$three];   # array ref
$bar  = [$obj method()   ];   # method call
$bat  = [$one $two $three];   # syntax error



 
 -- 
 Piers Cawley
 www.iterative-software.com



string concatenation operator - please stop.

2001-04-26 Thread Ask Bjoern Hansen


To me this whole thing looks like bike shedding at it's worst at
this point. Please stop and read this

http://www.freebsd.org/doc/en_US.ISO_8859-1/books/faq/misc.html#BIKESHED-PAINTING

and possibly this

 
http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers

before writing more on the subject, huh?


 - ask

-- 
ask bjoern hansen, http://ask.netcetera.dk/   !try; do();




RE: Curious: - vs .

2001-04-26 Thread Sterin, Ilya

$foo = [$one, $two, $three]; # creates an anonymous list.

$foo = [$object method(foo, bar)];
This would interpret as 

$foo[0] == $object, etc...

Ilya



-Original Message-
From: Buddha Buck [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 11:20 PM
To: Piers Cawley
Cc: Bart Lateur; [EMAIL PROTECTED]
Subject: Re: Curious: - vs .


Piers Cawley [EMAIL PROTECTED] writes:

 Buddha Buck [EMAIL PROTECTED] writes:
 
  Bart Lateur [EMAIL PROTECTED] writes:
  
   On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:
   So why not
   
 $object!method(foo, bar);
  
  In my opinion, because it doesn't provide sufficient visual
  distinction between $object and method().  At a glance, especially on
  a crowded page, it's similar in appearance to $objectImethod, for
  instance.  $object.method() has a visual separator (although I'd
  prefer $object-method()).
  
  How about borrowing from Objective C?
  
 [$object method(foo, bar)];
 
 How do you create an anonymous list now then? Not that I object to
 borrowing from Objective C you realise.

I thought ($one, $two, $three) was an anonymous list.

Seriously, I hadn't considered that their may be a problem with the
syntax I gave.

How would you, under Perl5, interpret the expression I used.  To me,
it looks like a syntax error.  '$object method(foo,bar)' isn't a
valid method call, so it can't be a ref to an anonymous list of one
value.

Other than severe dependence on the comma, is there any reason why we
couldn't have the following?


$foo  = [$one];   # array ref
$baz  = [$obj,funcall()  ];   # array ref
$quux = [$one,$two,$three];   # array ref
$bar  = [$obj method()   ];   # method call
$bat  = [$one $two $three];   # syntax error



 
 -- 
 Piers Cawley
 www.iterative-software.com



Re: Flexible parsing (was Tying Overloading)

2001-04-26 Thread Jarkko Hietaniemi

On Fri, Apr 27, 2001 at 02:28:58AM +0100, Simon Cozens wrote:
 On Thu, Apr 26, 2001 at 06:25:03PM -0500, Jarkko Hietaniemi wrote:
  In a sick way I kinda liked how compilers were able to give out error
  messages not unlike:
  
  foo.ada: line 231: Violation of sections 7.8.3, 9.11.5b and 10.0.16: see the LRM.
 
 Ever used the Mac C compiler?

Yes...?

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen



Re: a modest proposal Re: s/./~/g

2001-04-26 Thread Graham Barr

On Thu, Apr 26, 2001 at 03:35:24AM +, Fred Heutte wrote:
 Bart Lateur's response summarizes well what I've heard so far
 from responses both to the list and privately:
 
 (1) Yes,  ~  *is* somewhat used in its current role as the bitwise
 negation (complement) operator.
 
 (2) No, that doesn't appear to overlap my proposal for its use
 as a successor to  -  as now used.

You don't get it.

We are not looking for a single char to replace -

We WANT to use .

Graham.



Re: s/./~/g

2001-04-26 Thread Fred Heutte

A vote against the proposed switches, for an unbearably lazy (ok,
selfish) reason.  Having to use the shift key with any non-alphanumeric
keypress always feels like a lot of extra work.  This is why I have long
avoided underscores in variable names.  (This is the same reason
I avoid = which not only adds another keystroke beyond , but also has
the dreaded punctuation-key-shift.  I'm not arguing this is *better*,
just more convenient for me personally.  Or maybe it's just that I prefer
not to hang around too much with shifty characters.)

Having used . for string concats for 10 years, I could adjust to ~
but good golly is that annoying.  Also it does detract from readability
a little.

$a = my . $strings . join(@together) ;

$a = my ~ $strings ~ join(@together) ;


I don't mind ~ as the binding operator.  It makes me go slower and
think, aha! drive carefully:

$throttle =~ s/regex ahead/downshift brain/ ;


Fred




Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-26 Thread Larry Wall

Bart Lateur writes:
: Yeah. But no cheers then. The problem still remains: you can access a
: hash in the normal way in plain code, but inside a sub, you can mainly
: only access a passed hash through a reference.

Won't be a problem.

: It's annoying to basically having two ways of doing something, and one
: of them can't be used half of the time.
: 
: Even though @foo and %foo may be two different structures, a scalar $foo
: can only reference one of them at a time.
: 
: Are you going to provide a simpler aliasing mechanism to turn a hash
: reference, for example as passed to a sub as an argument, back into the
: full-blown hash? Simpler (and safer) than the much frowned upon
: assignment to a tyeglob, that is.

Yes.  In fact, a %hash prototype will provide a scalar context, forcing
a %foo arg to return a reference, and that ref will be aliased to %hash.
You will be required to do something explicit to declare an argument
that supplies list context and slurps the rest of the args.  (There
will also be an explicit way to slurp a list of items but supply
scalar context.)

Larry



Re: a modest proposal Re: s/./~/g

2001-04-26 Thread Nathan Wiger

Graham Barr wrote:
 You don't get it.
 
 We are not looking for a single char to replace -
 
 We WANT to use .

With complete respect here, I'm still not convinced this is true.
Specifically, what the value of we is. It hardly sounds like
everyone's united on this point. In fact, I've counted more postings of
the tone Why would we change - ?! than the other way around.

Now, it may be that all the We should use . people are just keeping
quiet, or think it's obvious why this is a benefit, but I'm unconvinced.
Again, I'm open-minded, but the only argument I've really heard is to
make Perl more Java/Python-like. This doesn't sway me at all. Are there
other reasons?

-Nate