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 imp
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 10
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
>I've heard "internal consistency" bandied about a lot. I think
>auto-my()ing variables in these sub declarations is a bad idea.
>What if you DON'T want them to be my()'ed? Do we have to add a global()
>keyword?
That's what Python requires. Keeping in mind that Python isn't
truly block-scoped,
Johan Vromans wrote:
>
> What would be the semantics if 'my' were left out? Would it be
> equivalent to:
>
> sub whois ($) {
> local($user) = @_;
> }
No. I'd say it should inherit the default global scope. This is
*consistent* within Perl. Here's the choices as I see it:
1.
Please take this thread to perl6-language-strict. The indundated masses
thank you for your co-operation.
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949
>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 cor
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 comp
Tom Christiansen said:
> >This doesn't fix the problem of:
> >{
> > $somevar = 0;
> > $someVar++; # oops, wrong case!
> >}
> >Forcing 'my' by default allows these errors to be caught.
>
> How so?
>
If the default is to force 'my' to create a lexical, rather than providing a
default lexical scope
>This doesn't fix the problem of:
>{
> $somevar = 0;
> $someVar++; # oops, wrong case!
>}
>Forcing 'my' by default allows these errors to be caught.
How so?
--tom
Nathan Wiger <[EMAIL PROTECTED]> writes:
> So will these be "automatically-my()ed"? Or will you have to say:
>
>sub whois (my $user) {
># ...
>}
>
> This seems more consistent (but there's that dang my() again!) :-)
What would be the semantics if 'my' were left out? Would it be
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
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 s
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 enou
Tom Christiansen wrote:
>
> > 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 va
Nathan Wiger wrote:
>
> > 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.
> 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 wil
> 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
># ...
>}
> 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 heard several good analyses against my idea,
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
benef
Nathan Wiger said:
> > 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.
>
> 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. T
The problem with lexical variables being made default, in earnest, is
simple, and error-prone:
code;
if ( condition )
{ more code;
$x = 'did then'';
} else
{ more code;
$x = 'did else';
}
print $x;
What lexical scope should $x be _implicitly_ declared in? Maybe, just
maybe, we need a my $x
> 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 rad
> 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
John Tobey wrote:
>
> "J. David Blackstone" <[EMAIL PROTECTED]> wrote:
> > Thanks for the feedback, everyone. I now believe that what we
> > really want is what so many have suggested, i.e., making strict 'vars'
> > the default (in essence, at least).
>
> Sorry if this was mentioned already.
On Fri, Aug 04, 2000 at 05:27:59AM +1000, Damian Conway 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.
>>
>>
"J. David Blackstone" <[EMAIL PROTECTED]> wrote:
> Thanks for the feedback, everyone. I now believe that what we
> really want is what so many have suggested, i.e., making strict 'vars'
> the default (in essence, at least).
Sorry if this was mentioned already. If this change is adopted, I
wou
Thanks for the feedback, everyone. I now believe that what we
really want is what so many have suggested, i.e., making strict 'vars'
the default (in essence, at least).
I have retained the title of "Lexical variables made default,"
because I still feel that that is the primary purpose of thi
--snip--
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
>[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?
--sinp
> > 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 the fun; but keeping something
> on t
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
On Thu, Aug 03, 2000 at 10:48:17AM -0400, John Porter wrote:
> Not saying we should eliminate all the fun; but keeping something
> on the merit of it's being fun is probably at odds with the goal
> of make Perl more widely acceptable.
Contrary to popular belief, people like having fun.
--
IBM
>[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
[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.
Not saying we should eliminate all the fun; but keeping something
on the merit o
On Wed, Aug 02, 2000 at 11:57:21AM -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
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
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 con
Peter Scott wrote:
> Argh, you're giving me Pascal flashbacks.
Nothing inherently wrong with that.
> Keep 'em short.
I think Keep Them Meaningful/Mnemonic should take precedence over
Keep Them Short.
> So you'd need something like use strict
> 'declarations' which would require all variable
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 coul
Tom Christiansen wrote:
>
> >Well, "var" is pretty short. And perhaps globals could be declared
> >with something like "var global". Extra verbosity required for globals
> >might be A Good Thing.
>
> But "var" is redundant: that's what the $ is for.
They're not semantically identical. "var"
>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".
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
>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__
. "::"},
On Wed, 2 Aug 2000, Ala Qumsieh wrote:
> Also, how about renaming my() to local()? Will this be too confusing?
Yes, that would be too confusing.
-sam
> 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
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
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()
> >
>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 gro
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 Sco
>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))
>how about clone()?
I imagine that that name will be taken by something else, such as
cloned interpreters.
Anythi
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))
how about clone()?
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))
save() as been suggested a number of times.
/L/e/k/t/u
On Tue, Aug 01, 2000 at 11:02:01PM -0500, J. David Blackstone wrote:
> The C operator should be retained due to its usefulness for
> dynamic scoping, but should be renamed to avoid confusion. I'm
> currently suggesting a name of C. More euphonious
> suggestions are requested.
This should probab
The following RFC reflects an assumption I've been making about
where Perl6 will go. Feel free to shoot it down, if I'm the only who
feels this way. :)
=head1 TITLE
Lexical variables made default
=head1 VERSION
Maintainer: J. David Blackstone <[EMAIL PROTECTED]>
Date: 1 August 2000
Versi
55 matches
Mail list logo
