Re: RFC: Rename local() operator

2000-08-07 Thread Piers Cawley

Nathan Wiger [EMAIL PROTECTED] writes:

   But it isn't "here" that's the problem.  If we just wanted to change
   the value "here", we could use my().  The problem is that local()
   changes the value for somewhere else as well as here.
  
  Well, as has been pointed out, special^Wlocalized variables are
  scoped in time, not space, so:
  
  now $/ = "\n";
 
 Personally, I like this alot, actually. It emphasizes what's going on
 really well. And it's short!
 
 As for the "need a verb" argument, my() and our() aren't verbs either.

$/ = "\n" now;

feels more English somehow. Would almost certainly be a bugger for
perl to parse though.

As for the 'need a verb' argument, it doesn't apply here because the
assignment is the verb.

-- 
Piers




Re: RFC: Rename local() operator

2000-08-06 Thread Nathan Wiger

 shadow $/ = "\n";
 
 seems to have the right implications to me.

Personally, I like this by far out of all the suggestions I've heard.
"save" seems to say "save THIS value" (the one you're setting, not the
global one you can't see). "hide" is a little too general (hide what in
what?). But I like "shadow the global variable with THIS one".

-Nate



Re: RFC: Rename local() operator

2000-08-06 Thread Buddha Buck

  What about Chide ?
 
 Here's yet another one - how about "here"?
 
{
   here $/ = "\n";   # what it is in here
 
}
 
 Not really any confusion on this - $/ is "\n" 'in here', but maybe
 something else outside.
 
 Unlike "hide" or others, this doesn't connote it's necessarily any
 different from somewhere else - just that it's this value inside the
 current block (which is what we're after, I think).

But it isn't "here" that's the problem.  If we just wanted to change 
the value "here", we could use my().  The problem is that local() 
changes the value for somewhere else as well as here.  Other names 
suggested (like "shadow", or "mask") convey that idea better than 
"here".

 
 ?
 
 -Nate

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice





Re: RFC: Rename local() operator

2000-08-06 Thread Peter Scott

At 12:50 AM 8/7/00 -0500, Jonathan Scott Duff wrote:
On Sun, Aug 06, 2000 at 08:03:51PM -0700, Nathan Wiger wrote:
   What about Chide ?
 
  Here's yet another one - how about "here"?

Doesn't this have a list of its own yet?

Well, "here" isn't a verb and I think we need a verb er ... here.
Granted, "local" isn't a verb either, but that's probably part of it's
problem.

Dang, just make it a pragma and let the user pick the word they want:

use thingy (qw(save hide shadow here there plugh hold cut rinse 
plonk))[rand 10];


:-)
--
Peter Scott
Pacific Systems Design Technologies




Re: RFC: Rename local() operator

2000-08-05 Thread Bart Lateur

On Fri, 4 Aug 2000 10:54:16 -0500, Jonathan Scott Duff wrote:

 Csave

If I had my druthers, save() would be it.

I'm against it. Why? Because it suggests that all it does is save the
value for later retrieval. It does not: the value is cleared as well. It
masks the previous global value, as if it didn't exist before.

save $/ = "\n";

That doesn't quite say it, does it?

In PostScript, for example, there's a gsave and grestore, the "g"
standing for graphics state. It allows you to save the current state of
the graphics output device, on a stack, but it doesn't modify it. You
can continue from there. It's a different concept.

The name "local" is wrong, because it suggests a private value scoped in
space. It is not, that's lexical values. It is scoped in time. I think
it's name should refelect that. "temporary"?

temporary $/ = "\n";

It's a mouthful. But it's going where I'd want it to go.

-- 
Bart.



Re: RFC: Rename local() operator

2000-08-05 Thread Jonathan Scott Duff

On Sat, Aug 05, 2000 at 12:04:30PM +0200, Bart Lateur wrote:
 On Fri, 4 Aug 2000 10:54:16 -0500, Jonathan Scott Duff wrote:
 
  Csave
 
 If I had my druthers, save() would be it.
 
 I'm against it. Why? Because it suggests that all it does is save the
 value for later retrieval. It does not: the value is cleared as well. It
 masks the previous global value, as if it didn't exist before.
 
   save $/ = "\n";
 
 That doesn't quite say it, does it?

You're right of course, but I don't know of any one word that
concisely and succintly means "save the current value of this
variable, clear it, and restore on exit of the current scope"

More words:

store() # put away for the duration of the scope
tuck()  # Now I lay me down to sleep
hide()  # I kinda like this one :-)
shelve()# probably too loaded
stow()  # Just sit right back and you'll hear a tale ...
bury()  # Oh my god!  They've killed Kenny!


I've changed my mind; my personal favorite is now "hide"

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]



Re: RFC: Rename local() operator

2000-08-05 Thread Russ Allbery

Nick Ing-Simmons [EMAIL PROTECTED] writes:

 What about Chide ?

 I think Cproxy or Cdeputy has merit - "while I am out contact ...".

 But I still think Csave is the essence of what it does.

I like either Chide or Csave too, but just to throw out the other idea
that occurred to me, what's being done here is in other languages often
called shadowing.  What about Cshadow?

shadow $/ = "\n";

seems to have the right implications to me.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/



Re: RFC: Rename local() operator

2000-08-05 Thread Chaim Frenkel


guard
protect

Hmm, 'guard' is just as long as 'local'.

chaim

 "JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes:

JSD More words:

JSDstore() # put away for the duration of the scope
JSDtuck()  # Now I lay me down to sleep
JSDhide()  # I kinda like this one :-)
JSDshelve()# probably too loaded
JSDstow()  # Just sit right back and you'll hear a tale ...
JSDbury()  # Oh my god!  They've killed Kenny!


JSD I've changed my mind; my personal favorite is now "hide"

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183



RFC: Rename local() operator

2000-08-04 Thread J. David Blackstone

  Since no one else has taken this up, I'll start an initial draft.

=head1 TITLE

Rename the Clocal operator

=head1 VERSION

  Maintainer: J. David Blackstone [EMAIL PROTECTED]
  Date: 4 Aug 2000
  Version: 1
  Mailing List: [EMAIL PROTECTED]
  Number: not yet assigned

=head1 ABSTRACT

The Clocal operator of Perl5 and earlier does not do what it claims
to and should be renamed.

=head1 DESCRIPTION

New Perl programmers are often confused by the behavior of the
Clocal operator, especially since a great deal of old educational
material exists showing the obsolete practice of using Clocal to
create subroutine arguments and local variables.

Clocal does not provide variables that are local to the enclosing
scope.  Instead it permits what is known as dynamic assignment, the
ability to temporarily assign a value to a variable such that the
variable's original value will be restored when the current scope is
exited.  Relying on this mechanism to provide what most people think
of as local variables (lexical scoping) can sometimes fail.

Clocal is useful in many cases and should be retained but renamed to
reflect its action.

=head1 IMPLEMENTATION

Many replacement names have been proposed for local on the
perl6-language list, and I am sure there are others that were proposed
on p5p in earlier days.  My current favorite name is Cdynassign to
reflect that a variable will undergo dynamic assignment.  I am certain
that better alternatives exist and that very few people will like that suggestion.

A list of other proposed replacement names includes (but is not
limited to, since I certainly have forgotten some):

Cpushpop (to reflect the fact that the variable's old value is
pushed onto a stack and popped off when the scope containing the use
of the operator is exited)

Cdynsave

Csave

Cclone (not a good idea, in my opinion.  I think that means making
an exact copy of an object.)

Ctemp

Csavetemp

Ctempsave

Cscopetemp

Cdeliver

Cpreserve

Csaveval

Ctempval

Csaverestore

Cmyval

Cpushval

Ccontain

Cdetach

Crevalue

Clet  (I'm not sure this was a proposal)

None of these completely satisfies me, at the moment, and there does
not appear to be any consensus among the group.

=head1 REFERENCES

The perlfunc manpage

=cut


J. David




-
On the flip side, we need to be Very Careful not to get our egos
irrevocably tied to our proposals.  I have a particular distaste for
the sort of argument that goes, "If I can't have it my way, I'm going
to take all my marbles and go home."
  -- Larry Wall



Re: RFC: Rename local() operator

2000-08-04 Thread skud

Please do not send your RFCs to both perl6-rfc and perl6-$working_group.
The RFC librarian will automatically forward your RFC with a number on
it, which is kinda neater.

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  Fax: +61 3 9614 0948  Mobile: +61 410 664 994



Re: RFC: Rename local() operator

2000-08-04 Thread Jonathan Scott Duff

On Fri, Aug 04, 2000 at 01:37:09AM -0500, J. David Blackstone wrote:
 =head1 IMPLEMENTATION
 
 Csave

If I had my druthers, save() would be it.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]