Re: RFC 88: What does catch Foo { } do?
Peter Scott wrote:
Tony Olekshy wrote:
Graham Barr wrote:
I am of the opinion that only a class name should follow catch.
If someone wants to catch based on an expression they should use
catch {
if (expr) {
}
else {
# rethrow the error
}
}
Then you will be glad to know that RFC 88, in the not quite ready
version two release, allows you do to just that.
"Allows" isn't the same as "should be the only way" though.
Graham, did you base your opinion on usability, parseability, both,
neither?
And now for a slightly less frisky answer. The nice thing
about the catch expr = block form is not necessarily
that you can say things like
try { ... } catch $@-{severity} =~ /.../ = { ... }
try { ... } catch grep { $_-isa("Foo") } @@ = { ... }
try { ... } catch ref $@ =~ /.../ = { ... }
but that within the scope of an application's code you can make
available utility functions to allow really nice phrasing of
rule-based catches (without having to re-raise), such as
catch not TooSevere = { ... }
catch AnyException("Error::IO") = { ... }
my $test = sub { lines of predicate based on $@ };
catch $test("Foo") = { ... }
catch $test("Bar") = { ... }
ad infinitum
Is there actually a good reason not to allow this functionality?
Yours, c, Tony Olekshy
RFC 88: Possible problem with shared lexical scope.
Non-shared:
my ($p, $q);
try { $p = P-new; $q = Q-new; ... }
finally { $p and $p-Done; }
finally { $q and $q-Done; }
Shared:
try { my $p = P-new; my $q = Q-new; ... }
finally { $p and $p-Done; }
finally { $q and $q-Done; }
If P-new throws, then the second finally is going to test
$q, but it's not "in scope" yet (its my hasn't been seen).
Or is it? If it isn't, I'll take shared lexical scoping out
and put a note about this in ISSUES instead of the current:
If it is not possible to have try, catch, and finally blocks
share lexical scope (due, perhaps, to the vagaries of stack
unwinding), this feature can simply be deleted, and the outer
scope can be shared.
Yours, c, Tony Olekshy
Re: RFC 88: Possible problem with shared lexical scope.
Peter Scott wrote:
Tony Olekshy wrote:
try { fragile(); }
catch { my $caught = 1; }
finally { $caught and ... }
It should work as though each pair of } ... { in between try { and
the end of the last finally or catch block isn't there. Storage
for lexicals is allocated at compile time, assignment happens at
run time.
However, my memory as to what the current perl behavior is was
faulty; continue blocks do *not* share the lexical scope of their
attached loop blocks.
So no, what I'm proposing is not the same as anything currently in
Perl. But I think it's a good reason anyway (and why shouldn't
continue blocks share the same scope? Not so 'lexical', I
suppose. Oh well.)
RFC 88v2d6 now leaves in shared lexical scope and says the following
under ISSUES + Lexical Scope:
If it is not possible to have try, catch, and finally blocks
share lexical scope (due, perhaps, to the vagaries of stack
unwinding), this feature can simply be deleted, and the outer
scope can be shared.
One possible problem is illustrated by this:
try { fragile(); }
catch { my $caught = 1; }
finally { $caught and ... }
If fragile() doesn't throw then finally is going to test
$caught even though the my statement was never exccuted.
These matters will have to be referred to the internals
experts.
Yours, c, Tony Olekshy
Re: RFC 132 (v1) subroutines should be able to return an lvalue
"JV" == Johan Vromans [EMAIL PROTECTED] writes: These two should have different actions. $foo = foo; foo = $foo; Perl needs a value for one, and a reference for the other. JV I'm not sure I understand what you trying to say here. Please explain. The difference between RHS and LHS. RHS, perl is manipulating values. With LHS perl is manipulating locations, storage areas. Where to put those values from the RHS. So RHS are values (even if a reference, it's meaning as a value is of interest) LHS are pointers. Where to save the value from RHS. So an lvalue sub on the RHS should be returning a _value_ an lvalue sub on the LHS should be tell Perl where to shove^w put the value. (Hey, perl, I want that dohickey put into my array at position 42.) JV - make it unfeasable for methods. Why? All methods for the same OO hierarchy should have the same signature. JV Assume class Foo has a method m that returns a scalar lvalue, and JV class Bar has a method m that returns an array lvalue. The following JV code is now perfectly legal (though weird): JV my $o = $some_condition ? Foo::-new() : Bar::-new(); JV $o-m = another_sub(); JV 'another_sub' calls wantarray. What should it return? That's the point. Perl has to examine $o-m 's return to determine what is going on. So $o- has to be called first. And the resulting reference queried about it's type. And then the want() will return the correct context. In the another_sub( lvalue_sub ), lvalue_sub has to be defered until the first time it is called. (Unless Damian thinks that reaccessing it each time will make more sense.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFCs (Re: Ideas that need RFCs?)
On Fri, Aug 18, 2000 at 05:22:17PM -0500, David L. Nicol wrote: RFC: Perl6 is Final. There will Be No Perl7 RFC: Everything is Accessible and Mutable RFC: The perl6 reference implementation, no matter how slow it is, will be written in perl5, in some kind of well defined virtual machine. RFC: It's all exception handling. RFC: Implemnentation: Unified containers are trees of storage nodes, and we do our own memory management with them RFC: Garbage collection: We keep reference counting, with a big node pool, occasionally defragment it if we can, to free the top of it. Almost all of these are internals fodder, not language topics. David, could you re-post this list to -internals and take discussion over there, please? 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: Maximum length input lines
On Sat, Aug 19, 2000 at 05:45:39PM -0700, Peter Scott wrote: At first I thought this was a -io item, but then I realized the -io part is easy; it's the -language part I need to get right :-) Um. The -io sublist is called -language-io for a reason -- it's for language discussions related to IO. Which means it probably *is8 the right list for it. If anyone's unsure as to which list is most appropriate for a discussion, please feel free to email me, or the sublist chairs, personally. 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: Maximum length input lines
Uri Guttman [EMAIL PROTECTED] writes: "PS" == Peter Scott [EMAIL PROTECTED] writes: PS At 08:50 PM 8/19/00 -0400, [EMAIL PROTECTED] wrote: I do believe thbis is one of the reasons sysread is there perldoc -f sysread PS Au contraire; sysread reads exactly the number of characters PS requested; what I want is a way for programs that do FH all over PS the place to be protected if someone throws a gargantuan number of PS characters at FH without a newline. The $/ = ref_to_int feature PS is exactly the kind of feature I was expecting to do this and I PS was disappointed that it didn't. and what happens to the partial line left in the input buffer? does it get read in the next time you call or is it thrown out? the semantics of in line mode is it reads a whole line. leaving the partial line to be read next time is bad. throwing out the leftover text is also bad. If I understand the context of the OP's suggestion, he'd want to flag an error if the maximal line length is exceeded. better to have work as now and the code just truncates the line with substr. This is not practical to the OP. He has an application that is waiting to read a line of data from some (untrusted) source. If the source feeds in 128GB of data with no line termination, Perl will require at least 128GB of swap to read it all in. This is an easy denial of service attack (for large values of "128"). Using substr would not be an option, as the damage is done before substr ever gets to see the "line". A better solution would be a tied-filehandle module which would do its own buffered reading and croak on long lines; presumably it would use sysread internally. -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: Extended Regexs
On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote: There is one significant area of perl that has very little attention here (other than one of my RFCs) that is regexs. Are you volunteering to chair a sublist? *grin* 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
Do we really need eq?
Is eq needed? Can't == be used for either context? $a == 'cat' is readily distinguishable from $a == 2; so the compiler should be able to determine context. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: Do we really need eq?
On Sun, 20 Aug 2000 17:50:20 -0600 (MDT), Nathan Torkington wrote (in part): Nat Ed Mills writes: Is eq needed? Can't == be used for either context? $a == 'cat' is readily distinguishable from $a == 2; so the compiler should be able to determine context. Nat if ($a == $b) Nat Is that string comparison or numeric comparison? Consider that case in particular when $a and $b are each dual-valued (valid as both string and number). -- Spider Boardman (at home) [EMAIL PROTECTED] The management (my cats) made me say this.http://www.ultranet.com/~spiderb PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
RFC 130 (v3) Transaction-enabled variables for Perl6
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs [EMAIL PROTECTED]
Date: 17 Aug 2000
Last Modified: 19 Aug 2000
Version: 3
Mailing List: [EMAIL PROTECTED]
Number: 130
=head1 ABSTRACT
Transactions are quite important in a database-enabled application.
Professional database systems have transaction-handling inside, but there are
only a few laguage out there, what supports transactions in variable level.
=head1 CHANGES
=head2 Version 3
=over 4
=item *
Added a tie interface change request: COMMIT and ROLLBACK, and new global
=item *
Fixed some Formatting error of this pod.
=item *
'use varlock' renamed to 'use transaction'.
=back
=head2 Version 2
=over 4
=item *
Detailed implementation description
=item *
Add a new pragma 'varlock' for controlling the concurrency control.
=back
=head1 DESCRIPTION
In short, we have "local" keyword, which changes a value of a variable for only
the runtime of the current scope. The transaction-enabled variables should
start up like "local", but IF the currenct scope reaches at the end, it then
copied into the global one.
We need to get a new keyword for defining such a variable, I think
"transaction" is too long, we could use "safe" for this.
Preferred syntax:
sub trans { my ($self,@params)=@_;
safe $self-{value}=$new_value;
# ...
die "Error occured" if $some_error;
function_call(...)
# ...
} ;
Meaning (in semi perl5 syntax):
sub {
local $self-{value}=$new_value;
# ...
die "Error occured" if $ome_erre;
function_call(...)
# ...
global $self-{value}=$self-{value};
};
If we want to gain more control and want to maintain easy syntax, we can use
another pragma, which sets up the attributes of locking. I think the
"transaction" pragma could be a good name:
use transaction (mode = 'lock', timeout=6000);
Parameters for transaction:
=over 4
=item mode
can be:
=over 4
=item simple
No blocking, concurrency control. (default).
In a not-threaded environment this causes minimal overhead, and no locking
overhead at all.
=item lock
Explicitly lock the accessed variables. (shared and exclusive locks used).
=item version
This is simlar to the postgres' multi-version concurrency control. It requires
more memory, but has a less chance to get into deadlock.
=back
=item timeout
Timeout in ms until we wait for the lock. 0 means nonblocking. If the timeout
reached, the system throws an exception.
=item isolation
Transaction isolation level. This can be:
=over 4
=item 0
Read uncommitted
=item 1
Read committed (default)
=item 2
Repeatable read
=item 3
Serializable.
=back
PostgreSQL implements only 1 and 3 AFAIK, so I think we could implment only
that level. Then 0 and 2 will be synonim for 1 and 3, but we could keep the
place for a future implementation.
See the postgreSQL documentation for the details.
=back
=head2 TIE INTERFACE
Adding transaction-enabled property of a tied variable is not straightforward.
Imagine you have been tied a hash into a (not transaction-enabled) dbm file.
When you fetch, you need to put a shared lock (or version-control) the dbm file
or key, when you read, you need to put an exclusive lock, and when the
transaction ends, you need to release the lock. For this reason, we can add two
callback: COMMIT and ROLLBACK.
If we don't want to use locking, or want to do an advanced
transaction-management, we can provide a transaction-id to the callbacks. This
can be done with a new package global variable (which is localized in every
call), the name can be $Package::TRANSACTION_ID. A new parameter is not good,
because some of the callbacks (PUSH, POP, UNSHIFT, PRINT, PRINTF, etc) are
expecting LISTs as an attribute, and this can cause unnecessary rewrite of the
tie interface.
Following is the description of the modifications of the tie interface:
=over 4
=item New package global
$Package::TRANSACTION_ID will be a unique identifier of the current transaction
(if any).
=item New Callbacks
Two new callbacks required:
=over 4
=item COMMIT $this
If it is defined, then it is called at the end of a successful transaction.
=item ROLLBACK $this
If it is defined, then it is called at the end of a failed transaction. If NOT
defined, then STORE will be called with the old value of the variable.
=back
=back
=head1 IMPLEMENTATION
=head2 Transaction handling methods
=over 4
=item simple
This is the default method. This needs no magic, implementation is
straightforward:
When you use "safe", then the following will happen:
$save_value=$value;
When you reaches the end of the block you are in, the saved value should be
dropped. If it was an exception that caused the termination of the block, then
the old value must be copied back to the global space:
$value=$save_value;
This solution is tie-safe,
RFC 133 (v1) Alternate Syntax for variable names
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Alternate Syntax for variable names
=head1 VERSION
Maintainer: David Corbin [EMAIL PROTECTED]
Date: 20 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 133
=head1 ABSTRACT
Many new users are confused by the use of $@% to represent context, when it is
also used to declare variables. This is a syntactic change that introduces
a bit more logic to the context/type confusion.
=head1 DESCRIPTION
Context is an essential part of Perl. When evaluating a symbolic expression,
$, @ and % are used to indicate the context of the expression. However, when
variables are declared (using local, my, or simply implicitly as an lvalue)
these same symbols are used. Cmy @array; my %hash; $var=1 To many people,
most notably programmers new to Perl, the $@% is mistakenly believed to be part
of the variable name. This leads to such erroneous attempts to use them as
C@array[0], and C@%hash{key}.
Consider the following syntax:
my var; # declaring a scalar
my array[]; # declaring an array
my hash{};# declaring a hash
Then, when it is necessary to distinguish context explicitly (it often is not),
you can use $@% as before. Consider:
count = array; # scalar context because of assignment to scalar.
alt_array[] = array; # list context
value = hash{key}; #
print $array," ",@array #Context must be clearly designated.
I'm not the linguist that Mr. Wall is, but it strikes me that context should be
derrived automatically as much as possible.
An slightly different alternative would be that arrays and hashes are always
referred to with their trailing indicator ([] or {}). So, from the example
above, you'd have
count=array[];
alt_array[] = array[];
=head1 IMPLEMENTATION
Unknown.
=head1 REFERENCES
RFC 9: Highlander Variable Types
RFC 109: Less linenoise - let's get rid of @%
RFC 134 (v1) Alternative array and hash slicing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Alternative array and hash slicing
=head1 VERSION
Maintainer: Mike Pastore [EMAIL PROTECTED]
Date: 20 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 134
=head1 ABSTRACT
This RFC attempts to address the confusion with regards to
taking a slice of a list or a hash. While most experienced
Perl hackers are on friendly terms with the current slicing
schema, ala:
$animals = [
'dog', 'cat',
'duck', 'cow',
'pig', 'lizard'
];
$sounds = {
dog = 'bark',
cat = 'meow',
duck = 'quack'
};
@domestic = @{$sounds}{@{$animals}[0,1]};
This is still difficult to look at, even for experienced
Perl hackers. While it can be grokked, it takes a good
amount of effort. Novice programmers and programmers coming
in from other languages have enormous difficulty
understanding these constructs.
=head1 DESCRIPTION
Several alternatives (read: OPTIONAL) are being suggested
here as a means of taking a slice of a list (or a hash).
Ideally, one or more of these will be included in the
Perl 6 core as an alternative to the traditional deref-
and-slice syntax.
=head2 Built-in Function Cslice()
Like the current built-in list function Csplice(),
Cslice() would take a list and slice parameters, and
return a slice.
@house_pets = slice(@$animals, [0..1]);
Or, with a bit of Perl Magick, even dropping the redundant
dereference operation.
A major issue with Cslice() is the probable spelling
problem. Alternative function names would be lovely to
hear. :-)
=head2 Quote-like Operator Csl//ah
This may or may not make sense, but definitely looks
like a neat way to DWIM. The flags Ca and Ch indicate
an array or hash slice, respectively. Furthermore, use
of C[] or C{} containers also implies an array or hash
slice and circumvents the use of flags.
@livestock = (@$animals =~ sl/3..4/a);# array slice
@sounds = (values %$sounds =~ sl[1,3]); # this too
Please see ISlicing Extensions for Hashes for more info
regarding hash slicing using this syntax.
=head2 Arrow Notation (the infix dereference operator)
An extension to arrow notation has also been suggested by
a number of people.
@domestic = $sounds-@{$animals-@[0,1]};
Which is equivalent to the Perl 5 construct:
@domestic = @{$sounds}{@{$animals}[0,1]};
As mentioned above. This syntax reads quite nicely from
left to right:
Dereference $sounds, taking the slice found by
dereferencing $animals and taking the slice of the
first two elements.
The biggest problem with this suggestion is the loss of
context. We are not returning one thingy from the
operation, but that is not obvious at first glance. The
eye (and mind) catches the C$ and moves on to the next
line. The plural context C@ is present but lost,
somewhere in the middle of the operation. This is a Bad
Thing. Therefore, the following is suggested, as a
parallel to the current arrow notation to get a single
thingy:
$thingy = $animals-[0]; # evaluates to:
$thingy = ${$animals}[0];
@thingies = @$animals-[0..2]; # evaluates to:
@thingies = @{$animals}[0..2];
Unfortunately, this opens up a whole new can of worms
that has been covered before in p5p and should be covered
again (see REFERENCES). But not in this RFC.
One more alternative: context sensitivity.
$num_thingies = $animals-[1..3];
@thingies = $animals-[1..3];
=head2 Slicing Extensions for Hashes
The ability to take an Iindexed slice of a hash is
desired. This would allow the programmer to pare out
several keys and values from hash A into a new hash B, for
greatest flexibility. Currently, this is only available
through Cmap():
%other = map { $_ = $sounds-{$_} } qw(lizard duck);
Which could be simplified to:
%other = slice(%$sounds, { qw(lizard duck) }); # or,
%other = (%$sounds =~ sl/lizard duck/h); # or,
%other = %$sounds-{'lizard', 'duck'}; # or,
%other = %{$sounds}{ qw(lizard duck) };# trad'l
Furthermore:
%hash = slice(%$sounds, ['dog']); # dies (%+[] usage)
%hash = %$sounds =~ sl[dog]; # same as above
@list = slice(@$animals, {0..1}); # dies (@+{} usage)
@list = @$animals =~ sl{0..1}; # same as above
Which will promote proper coordination between C@ and
C[], and between C% and C{}. This allows for an
easier transition from the built-in Cslice() to the more
traditional approaches.
Finally, flattened indexed slices and hash value slicing.
@foo = %{$sounds}{'dog', 'duck'}; # flatten
@foo = slice(%$sounds, {'dog', 'duck'}); # to list
@bar = @{$sounds}{'dog', 'lizard'};# retrieve
@bar = slice(@$sounds, {'dog', 'lizard'}); # values
@bar = slice(values %$sounds, [0,2]); # only
=head1 SUMMARY
To pull this together, the following should just DWIM:
$foo =
RFC 135 (v1) Require explicit m on matches, even with ?? and // as delimiters.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Require explicit m on matches, even with ?? and // as delimiters. =head1 VERSION Maintainer: Nathan Torkington [EMAIL PROTECTED] Date: August 20, 2000 Version: 1 Mailing List: [EMAIL PROTECTED] Number: 135 =head1 ABSTRACT C?...? and C/.../ are what makes Perl hard to tokenize. Requiring them to be written Cm?...? and Cm/.../ would solve this. =head1 DESCRIPTION Damian Conway's Text::Balanced module does a pretty good job of tokenizing Perl code. However, bare C/.../ and C?...? require semantic analyis to distinguish them from division and the hook (CA?B:C) operator. To remove this hassle, and thus permit programs that analyze the source-code of other programs, I propose requiring that all matches require an explicit Cm. =head1 IMPLEMENTATION Remove the bare C/.../ and C?...? from the grammar :-) When converting perl5 programs to perl6, put the Cm in. =head1 REFERENCES perl6-language message C[EMAIL PROTECTED] by Damian Conway
RFC 130 (v2) Transaction-enabled variables for Perl6
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs [EMAIL PROTECTED]
Date: 17 Aug 2000
Last Modified: 18 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 130
=head1 ABSTRACT
Transactions are quite important in a database-enabled application.
Professional database systems have transaction-handling inside, but
there are only a few laguage out there, what supports transactions
in variable level.
=head1 CHANGES
=over 4
=item *
Detailed implementation description
=item *
Add a new pragma 'varlock' for controlling the concurrency control.
=back 4
=head1 DESCRIPTION
In short, we have "local" keyword, which changes a value of a
variable for only the runtime of the current scope. The
transaction-enabled variables should start up like "local", but IF
the currenct scope reaches at the end, it then copied into the
global one.
We need to get a new keyword for defining such a variable, I think
"transaction" is too long, we could use "safe" for this.
Preferred syntax:
sub trans { my ($self,@params)=@_;
safe $self-{value}=$new_value;
# ...
die "Error occured" if $some_error;
function_call(...)
# ...
} ;
Meaning (in semi perl5 syntax):
sub {
local $self-{value}=$new_value;
# ...
die "Error occured" if $ome_erre;
function_call(...)
# ...
global $self-{value}=$self-{value};
};
If we want to gain more control and want to maintain easy syntax,
we can use another pragma, which sets up the attributes of locking.
I think the "varlock" pragma could be a good name:
use varlock (mode = 'lock', timeout=6000);
Parameters for varlock:
=over 4
=item mode
can be:
=over 4
=item simple
No blocking, concurrency control. (default).
In a not-threaded environment this causes minimal overhead, and no locking overhead at
all.
=item lock
Explicitly lock the accessed variables. (shared and exclusive locks used).
=item version
This is simlar to the postgres' multi-version concurrency control. It requires more
memory, but has a less chance to get into deadlock.
=back 4
=item timeout
Timeout in ms until we wait for the lock. 0 means nonblocking. If the timeout reached,
the system throws an exception.
=item isolation
Transaction isolation level. This can be:
=over 4
=item 0
Read uncommitted
=item 1
Read committed (default)
=item 2
Repeatable read
=item 3
Serializable.
=back 4
PostgreSQL implements only 1 and 3 AFAIK, so I think we could implment only that
level. Then 0 and 2 will be synonim for 1 and 3, but we could keep the place for a
future implementation.
See the postgreSQL documentation for the details.
=back 4
=head1 IMPLEMENTATION
=head2 Transaction handling methods
=over 4
=item simple
This is the default method. This needs no magic, implementation is
straightforward:
When you use "safe", then the following will happen:
$save_value=$value;
When you reaches the end of the block you are in, the saved value
should be dropped. If it was an exception that caused the
termination of the block, then the old value must be copied
back to the global space:
$value=$save_value;
This solution is tie-safe, and this is very important.
=item lock
We need to maintain locks (mutexes) on variables. We assume this will
be used in threaded applications.
When we use "safe", then perl will put a shared lock on the variable.
When we read the variable, we also put a shared lock to that.
When we write the variable, we check if it is already locked, and
if we locked that already or no exclusive locks present, then
write to the value, and lock that with LOCK_EX. If other exclusive
lock present on the variable, then we need to wait for the releasing.
When the "safe" content ends, we frees the shared (or exclusive lock).
If the content ends with a die then we puts the original value back
if we have locked it with exclusive lock.
=item version
It is the mechanism of making multiple versioned copies of the variable
every time somebody access this. This needs tiestamping, and
postgreSQL-like concurrency control. I don't know more details.
=back 4
=head1 REFERENCES
PostgreSQL Multi-version concurrency control
http://www.postgresql.org/docs/postgres/mvcc.htm
RFC 1: Implementation of Threads in Perl
RFC 19: Rename the Clocal operator
RFC 63: Exception handling syntax
RFC 64: New pragma 'scope' to change Perl's default scoping
RFC 80: Exception objects and classes for builtins
RFC 88: Structured Exception Handling Mechanism (Try)
RFC 106: Yet another lexical variable proposal: lexical variables
made default without requiring strict 'vars'
RFC 119: object neutral error handling via exceptions
