John Porter [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Perl's similarity to English is one of the things that makes it Fun.
OTOH, being fun (which I admit it is) is one of the reasons many
people don't want to think Perl is a serious language.
English had the same problem for 100s of
Nathan Wiger [EMAIL PROTECTED] writes:
I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of this change
First off, I think this is a great idea in principle. However, I don't
think it goes nearly far enough in the
Nathan Wiger [EMAIL PROTECTED] writes:
You've taken the wrong approach. If you're writing a big program then
there should be *no* default scope. Any variable access is an error
unless that variable was my()ed or our()ed. That's basically what
'strict' gives us.
Fair enough. I've
Tom Christiansen [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Perl's similarity to English is one of the things that makes it Fun.
OTOH, being fun (which I admit it is) is one of the reasons many
people don't want to think Perl is a serious language.
So what?
Well said.
Damian Conway [EMAIL PROTECTED] writes:
Perl's similarity to English is one of the things that makes it Fun.
OTOH, being fun (which I admit it is) is one of the reasons many
people don't want to think Perl is a serious language.
Not saying we should eliminate all
On Thu, 3 Aug 2000 10:48:17 -0400, John Porter wrote:
OTOH, being fun (which I admit it is) is one of the reasons many
people don't want to think Perl is a serious language.
I don't agree. The problem is somewhere else, namely the problem that
Ilya Z. brought up: the fact that there is no
The descriptions in perlfunc etc. are not 100% complete.
Then send a patch.
There are some features that are still not documented. Therefore, it is
not possible to mathematically prove that a largish program is correct.
Your "therefore" is misplaced or misguided. Formal proof systems
of
Bart Lateur wrote:
On Thu, 3 Aug 2000 10:48:17 -0400, John Porter wrote:
OTOH, being fun (which I admit it is) is one of the reasons many
people don't want to think Perl is a serious language.
I don't agree. The problem is somewhere else, namely the problem that
Ilya Z. brought up: the
[EMAIL PROTECTED] wrote:
Perl's similarity to English is one of the things that makes it Fun.
OTOH, being fun (which I admit it is) is one of the reasons many
people don't want to think Perl is a serious language.
So what?
--tom
Tom Christiansen wrote:
OTOH, being fun (which I admit it is) is one of the reasons many
people don't want to think Perl is a serious language.
So we shouldn't argue for a feature simply because it's fun,
especially when the counterargument includes increased acceptability.
--
John Porter
I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of this change,
meaning that in future Perl documentation (books, manpages, classes (I
hope)) new Perl users will first be presented with variables declared
as lexicals with
I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of this change
First off, I think this is a great idea in principle. However, I don't
think it goes nearly far enough in the implementation. I'd like to
propose something
What lexical scope should $x be _implicitly_ declared in? Maybe, just
maybe, we need a my $x at the top to tell us it is outside the scope of the
first reference. Otherwise we get three different lexical variables, and an
undefined value warning at run time.
You're right, great point.
Nathan Wiger writes:
I argue we should fundamentally shift this thinking in Perl 6. Let's
truly have "lexical variables made default".
Ugh. Baby, bathwater.
If I'm writing a big program, then I want to have to declare all
variables so that Perl can catch errors for me. That's the big
However, I do think there's something to be said for a "quick-and-dirty"
script out of the box that can distinguish between sub{} vars and other
vars ala C:
$user = 'nwiger';
sub whois {
($user) = @_;# different var
# ...
}
Besides, named arguments will solve this (in fewer chars even :-)...
$user = 'nwiger';
sub whois ($user) {
# ...
}
Damian
Great point. I'll "settle" for that (it's what I'm looking for anyways).
:-)
So will these be "automatically-my()ed"? Or will you
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
Anything one chooses potentially conflicts with the user's namespace, but
probably save() or temp() would be better, or even savetemp() or tempsave()
or scopetemp().
How about deliver() or preserve()?
-Scott
--
Jonathan Scott
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
Anything one chooses potentially conflicts with the user's namespace, but
probably save() or temp() would be better, or even savetemp() or tempsave()
or scopetemp().
How about deliver() or preserve()?
I can slightly grok the
On Wed, Aug 02, 2000 at 09:15:38AM -0600, Tom Christiansen wrote:
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
Anything one chooses potentially conflicts with the user's namespace, but
probably save() or temp() would be better, or even savetemp() or tempsave()
or
Scott wrote:
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
Anything one chooses potentially conflicts with the user's
namespace, but probably save() or temp() would be better,
or even savetemp() or tempsave() or scopetemp().
How about deliver() or preserve()?
How
How about contain() or detach() or revalue()?
I might just throw out that the operator "let" does the job in Lisp.
Also, how about renaming my() to local()? Will this be too confusing?
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
--
John Porter
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
What then do you propose? my() and our() were chosen for their brevity.
I might suggest that one look to Python's use of locals() and
globals(). Currently, globals() is something like keys %{ __PACKAGE__
. "::"},
Tom Christiansen wrote:
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
What then do you propose? my() and our() were chosen for their brevity.
Well, "var" is pretty short. And perhaps globals could be declared
with something like "var global". Extra
At 11:57 AM 8/2/00 -0400, John Porter wrote:
Tom Christiansen wrote:
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
What then do you propose? my() and our() were chosen for their brevity.
Well, "var" is pretty short. And perhaps globals could be
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote:
On Tue, 1 Aug 2000 23:43:24 -0500, Jonathan Scott Duff [EMAIL PROTECTED]
wrote:
(I, for one, support renaming local() to Something Better (if only I
know what that was))
Anything one chooses potentially conflicts with
Tad McClellan wrote:
or saveval()# indicates it is about _values_
tempval()
or myval() # my _value_, not my(variable)
or even pushpop() # maybe not :-)
pushval()
--
John Porter
26 matches
Mail list logo
