Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

my $temperature is ro

8 views
Skip to first unread message

Steve Lukas

unread,
Feb 16, 2007, 8:46:57 AM2/16/07
to perl6-l...@perl.org
# 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<readonly> trait and also C<is ro> 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<is rw>.

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<readonly $temperature;>
should become syntactical sugar for
C<my $temperature is ro;>

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.

TSa

unread,
Feb 16, 2007, 10:44:21 AM2/16/07
to perl6-l...@perl.org
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.
--

Larry Wall

unread,
Feb 16, 2007, 12:47:32 PM2/16/07
to perl6-l...@perl.org
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

Smylers

unread,
Feb 16, 2007, 2:42:34 PM2/16/07
to perl6-l...@perl.org
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<readonly $temperature;> should become syntactical sugar
> for C<my $temperature is ro;>

Why? What does hiding the fact that is a lexical variable declared with
C<my> 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

Steve Lukas

unread,
Feb 16, 2007, 2:44:53 PM2/16/07
to perl6-l...@perl.org
Hello Thomas,
thanks for answering.

I fear the C<constant> 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.

Steve Lukas

unread,
Feb 16, 2007, 2:49:08 PM2/16/07
to perl6-language
Oops, that was a timing problem.
I didn't see that there were answers, sorry.

Kind Regards
Stefan

Steve Lukas

unread,
Feb 16, 2007, 3:07:43 PM2/16/07
to perl6-language
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.

Larry Wall

unread,
Feb 16, 2007, 3:42:27 PM2/16/07
to perl6-language
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

Bob Rogers

unread,
Feb 16, 2007, 8:24:08 PM2/16/07
to Larry Wall, perl6-language
From: Larry Wall <la...@wall.org>
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/

0 new messages