my $temperature is ro
# Hello @all,
# I want to suggest readonly or 'is ro' declaration for variables. See:
readonly $temperature = db_temperature_of( $date_time_loc);
...
## much later
# It is *ensured* that $temperature is the original value from database!
my $result = important_decision( $temperature);
#{
It can be very useful to ensure that a variable/container cannot be
modified after setting an initial value at *runtime*. Probably this will
become pretty popular if there is a easy way to do so. For example,
fetching data from database for analizing and reporting purposes only is
a very common task. It should be possible to protect the fetched data
actively. I think its a key feature to achieve higher security and reliability.
Even global variables lose most of its harm when they are readlonly.
Usual ways to keep the "original value" are not reliable.
In most cases (I assume) its: Just don't modify it! If it is important that
the value keeps unmodified: uppercase the name of the variable.
Well, sometimes the majority of my variables are considered to stay
unmodified. To uppercase them all is ugly but still not reliable.
Advanced technique: Use CPAN-Module Readonly. I use it, it's great!
But, whats missing is the capabilitiy to detect violations of the readonly
trait at compile time. Because of that, a program could fail to late.
The Synopses mentions a C trait and also C but its use
seems to be limited to code object like subroutines and subroutine
parameters. I have also recognized in S12 that there are ways to deal with
a VAR macro, but I dont feel that this fits my needs.
A declaration is better in many aspects. It tells the parser not to accept
any assignments in the source code after initialization on variables that
are declared 'readonly'. In other words, the total count of assignments in
the source code is one or none. (The latter could cause a warning.)
A binding of the variable inherits the readonly restriction. Hence it is
forbidden to use a readonly variable as a subroutine argument, when
the according parameter C.
Thinking of the form, I see three ways:
(1) The best readable form is probably:
readonly $temperature; # lexical scope
(2) But this fits better in perl6 conventions:
my $temperature is ro; # lexical scope
our $weather is ro; # package scope
$*global_weather is ro; # global scope
(3) For those who work a lot with readonly semantics, this could be best:
readonly $-temperature; # lexical scope, twigil prevents all attempts!
I think form (2) should be possible for variables. And form (1)
C
should become syntactical sugar for
C
What do you think? Does anybody agree?
Kind Regards
Stefan
#}
-
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
Get your Google SoC thinking caps on...
Time to start thinking what might make a good Google Summer of Code project. What would be fun to get paid to work on for 3 months? Or, what would be useful to encourage someone smart and keen work on for you? The linked-to page says We won't start accepting applications until March, which suggest that the timing is going to be different this year. Nicholas Clark - Forwarded message from LH <[EMAIL PROTECTED]> - From: "LH" <[EMAIL PROTECTED]> To: "Summer-Admin-Announce-2006" <[EMAIL PROTECTED]> Subject: GSoC 2007 is ON!!! Date: Fri, 16 Feb 2007 04:04:19 - User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1) Gecko/20061016 Camino/1.1a1,gzip(gfe),gzip(gfe) Hello everyone, http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html Cheers, LH --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Summer-Admin-Announce-2006" group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/summer-admin-announce-2006?hl=en -~--~~~~--~~--~--~--- - End forwarded message -
Re: my $temperature is ro
HaloO, Steve Lukas wrote: Thinking of the form, I see three ways: (1) The best readable form is probably: readonly $temperature; # lexical scope The current spec has got constant $temperature = getValue(); Hope that helps, TSa. --
Re: my $temperature is ro
On Fri, Feb 16, 2007 at 04:44:21PM +0100, TSa wrote: : HaloO, : : Steve Lukas wrote: : >Thinking of the form, I see three ways: : >(1) The best readable form is probably: : >readonly $temperature; # lexical scope : : The current spec has got : :constant $temperature = getValue(); No, that evaluates getValue() at compile time. He really just wants the already specced form: my $temperature is readonly = getValue(); Or maybe what he really wants is a pragma: no mutators; Larry
Re: my $temperature is ro
Steve Lukas writes: > (1) The best readable form is probably: > readonly $temperature; # lexical scope > > (2) But this fits better in perl6 conventions: > my $temperature is ro; # lexical scope > > I think form (2) should be possible for variables. As Larry's pointed out, it pretty much already is. > And form (1) C should become syntactical sugar > for C Why? What does hiding the fact that is a lexical variable declared with C get us? Isn't your form 2 sufficient? > (3) For those who work a lot with readonly semantics, this could be > best: readonly $-temperature; # lexical scope, twigil prevents all > attempts! I don't fully understand. In what way are you proposing: readonly $-temperature = value(); would differ from: readonly $temperature = value(); ? Are you envisaging that both forms would be permitted, such that a program could have some read-only variables with minus signs and some without them? Would the form with the minus sign require the minus sign every time the variable is referred to (that is, it is part of its name)? If so, do you really think that C<$-temperature> looks 'more' read-only than C<$TEMPERATURE> does? Would you also be able to declare a separate (presumably read-write) variable, C<$temperature> in the same scope as C<$-temperature>? Smylers
Re: Re: my $temperature is ro
Hello Thomas, thanks for answering. I fear the C declaration is not suitable for the purposes I'm thinking of, since it sets the value at compile time. And at compile time it can't contact a database, unfortunately. So, we need the assignment at runtime, but the sanity check *latest* at compile time, I think. What I suggest is almost or completely a capability of the parser, rather than a feature of the compiler. (Ehm, that was not a statement of a compiler expert! I hope its not foolish) The parser could prevent a second use of an assignment operator on this explicitly readonly declared variables. Its valuable to ensure the integrity of data till the end of (run) time, and we could get it by declaration. Come on, its a good idea, isn't it? Kind Regards Stefan - Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta.
Re: my $temperature is ro
Oops, that was a timing problem. I didn't see that there were answers, sorry. Kind Regards Stefan - No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started.
Re: my $temperature is ro
Larry, Smylers, now I've read your answers. Larry, thanks for telling me that it is already specced. I have overlooked it, sorry. Hello Smylers, thanks for your answer, too. I'm not stucked on the form C<$-name>. I am happy to get the runtime readonly or the pragma. Have a nice day Stefan - Don't get soaked. Take a quick peak at the forecast with theYahoo! Search weather shortcut.
Re: my $temperature is ro
On Fri, Feb 16, 2007 at 12:07:43PM -0800, Steve Lukas wrote: : Larry, Smylers, now I've read your answers. : Larry, thanks for telling me that it is already specced. : I have overlooked it, sorry. : Hello Smylers, thanks for your answer, too. I'm not stucked on : the form C<$-name>. I am happy to get the runtime readonly : or the pragma. The "is readonly" is part of the declaration, and can therefore give you compile-time diagnostics as well as run-time. The run-time check is merely a fail-safe for situations where the compiler can't determine that you're attempting to modify something. That being said, in writing the Perl 6 grammar I keep running into the need for rw context variables. I'm getting tired of writing things like: my @heredoc_stubs is context is rw = () so maybe there's some general syntactic relief for rw/ro that is orthogonal to everything else. But that means it wouldn't be a trait, a type, a sigil, or a twigil, if it's really orthogonal. I don't just want to go with bare rw and ro markers because I think they're too easy to confuse. It's more like we want an initializer that says "lock this after I change it". If used on the initializer of a declaration it would have the force of a readonly declaration. Some variant on or near the =, in other words, that could also be a variant on normal assignment. But maybe it also has to stand alone to declare it as a "write once" variable, I expect. Currently "is readonly" only works on the declaration, and only on items that are initialized by the declaration. Maybe that's good enough for most purposes. This isn't quite what context variables want though. They tend to want to be writeable in the current scope and then either ro or rw in sub-scopes. So I've been wondering whether we should split the "is context" declarator into two, one of which is for passing immutable info downward like environment variables, and one of which is for passing data upward to a mutable target, kinda like the implicit target of a gather. Don't know what the syntax for that should be though. Unfortunately the opposite of "context" is not "pretext", though that's kind of a funny pun--set this variable up ahead of time to gather text. And "protext" isn't a word, that I know of... I guess I need to visit the thesaurus for all the words that mean disseminate and assemble... Other ideas will be gladly entertained before being rejected. :-) Larry
[svn:perl6-synopsis] r13588 - doc/trunk/design/syn
Author: larry
Date: Fri Feb 16 17:59:34 2007
New Revision: 13588
Modified:
doc/trunk/design/syn/S13.pod
Log:
Clarification of coercion declarations and semantics.
Modified: doc/trunk/design/syn/S13.pod
==
--- doc/trunk/design/syn/S13.pod(original)
+++ doc/trunk/design/syn/S13.podFri Feb 16 17:59:34 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 2 Nov 2004
- Last Modified: 17 Jan 2007
+ Last Modified: 16 Feb 2007
Number: 13
- Version: 6
+ Version: 7
=head1 Overview
@@ -143,15 +143,39 @@
=head1 Type Casting
-A class can use the C<< *infix: >> submethod to declare that its objects
-can be cast to some other class:
+A class may define methods that allow it to respond as if it were a
+routine, array, or hash. The long forms are as follows:
-multi submethod *infix: (IO) { $*OUT }
-multi submethod *infix: (Int) { 1 }
-multi submethod *infix: (Str) { "Hello" }
+method postcircumfix:<( )> (|$capture) {...}
+method postcircumfix:<[ ]> (|$capture) {...}
+method postcircumfix:<{ }> (|$capture) {...}
-With the above declaration, C<$obj as "foo"> is equivalent to C<$obj as Str>,
-because the multi dispatch cares only about the class.
+Those are a bit unwieldy, so you may also use these short forms:
+
+method &.( |$capture ) {...}
+method @.[ *@@slices ] {...}
+method %.{ *@@slices } {...}
+
+The actual sigil used doesn't matter as long as it's followed by a dot
+and the bracket pair containing the signature. (Note that the angle
+bracket subscripting form C<< . >> automatically translates
+itself into a call to C< .{'a','b','c'} >, so defining methods for
+angles is basically useless.)
+
+The expected semantics of C<&.()> is that of a type coercion which may
+or may not create a new object. So if you say:
+
+$fido = Dog.new($spot)
+
+it certainly creates a new C object. But if you say:
+
+$fido = Dog($spot)
+
+it might call C, or it might pull a C with Spot's
+identity from the dog cache, or it might do absolutely nothing if
+C<$spot> already knows how to be a C. As a fallback, if no
+method responds to C<&.()>, the class will be asked to attempt to
+do C instead.
=cut
Re: my $temperature is ro
From: Larry Wall <[EMAIL PROTECTED]> Date: Fri, 16 Feb 2007 12:42:27 -0800 . . . so maybe there's some general syntactic relief for rw/ro that is orthogonal to everything else. But that means it wouldn't be a trait, a type, a sigil, or a twigil, if it's really orthogonal. I don't just want to go with bare rw and ro markers because I think they're too easy to confuse. It's more like we want an initializer that says "lock this after I change it". If used on the initializer of a declaration it would have the force of a readonly declaration. Some variant on or near the =, in other words, that could also be a variant on normal assignment . . . Sounds like you want a way to specify single assignment. Maybe use ":=" or something similar to say that the assignment is really a definition. Though probably that doesn't address the "is context is rw" issue. And it's not clear to me what it would mean without something like "my" that introduces a new scope . . . -- Bob Rogers http://rgrjr.dyndns.org/
[svn:perl6-synopsis] r13589 - doc/trunk/design/syn
Author: larry Date: Fri Feb 16 18:29:45 2007 New Revision: 13589 Modified: doc/trunk/design/syn/S06.pod Log: Clarification on what may be returned from, requested by rhr++ Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podFri Feb 16 18:29:45 2007 @@ -13,9 +13,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 21 Mar 2003 - Last Modified: 12 Feb 2007 + Last Modified: 16 Feb 2007 Number: 6 - Version: 70 + Version: 71 This document summarizes Apocalypse 6, which covers subroutines and the @@ -1732,15 +1732,23 @@ =head2 The C function As mentioned above, a C call causes the innermost surrounding -subroutine, method, rule, token, regex (as a keyword) or macro to -return. Only declarations with an explicit keyword such as "sub" -may be returned from. You may not use C to return from loops, -bare blocks, pointy blocks, or quotelike operators such as C. - -To return from these types of code structures, the C method -is used instead. (It can be taken to mean either "go away from" or -"bequeath to your successor" as appropriate.) -The object specifies the scope to exit, +subroutine, method, rule, token, regex (as a keyword) or macro +to return. Only declarations with an explicit declarator keyword +(C, C, C, C, C, C, and +C) may be returned from. Statement prefixes such a C and +C do not fall into that category. You may not use C to +return from loops, bare blocks, pointy blocks, or quotelike operators +such as C; a C within one of those constructs will +continue searching outward for a "proper" routine to return from. +Nor may you return from property blocks such as C or C +(though blocks executing within the lexical and dynamic scope of a +routine can of course return from that outer routine, which means +you can always return from a C or a C, but never from +a C or C.) + +To return from blocks that aren't routines, the C method is used +instead. (It can be taken to mean either "go away from" or "bequeath +to your successor" as appropriate.) The object specifies the scope to exit, and the method's arguments specify the return value. If the object is omitted (by use of the function or listop forms), the innermost block is exited. Otherwise you must use something like C
