Outlaw to declare a lexical twice in the same scope
Hello, perhaps I've missed a discussion about it, but I can't find a reason for a (IMHO infelicitous) specification. In S04 is said: "If you declare a lexical twice in the same scope, it is the same lexical" I would argue for: If you declare a lexical twice in the same scope, it is an error! Well, this error happens most likely due to my tiredness and I want the compiler to wake me up. This can be important because I would expect that C< my $x = 7;> does not change/overwrite the value of an existing $x. If I want to change the defined $x, I don't declare it again. Does anybody agree? Regards Stefan - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2ยข/min or less.
Remember: Outlaw to declare a lexical twice in the same scope
Hi @larry, I want to remember to my proposal from september 2006. It targets on changing S04. The discussion is summarized on: http://www.oreillynet.com/onlamp/blog/2006/09/weekly_perl_6_mailing_list_sum_3.html So, please change S04 as discussed. Thanks Stefan - Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta.
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.
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.
Relief for rw/ro
Recently $larry asked for ideas for better naming
the several states of write access.
There are some tentative thoughts, I like to offer.
Larry Wall wrote:
> 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.
My approach is:
In terms of writeability a variable/reference can be
(1) a variable, (2) a constant or (3) a "final"
(Don't wonder if you never heard of that "final", just my proposal)
That means it can be writeable (1),
not writeable since compile time (2) or
not writeable since that moment in runtime when it gets "final" (3).
This approach could work with an optional second declarator.
In the usual case the second declarator, that would be 'variable',
is simply omitted and nobody feels a difference.
- snip
my $number = 3; # OK, of course
my variable $number = 3; # The same, not really useful, -> warning?
# context variables default to readonly,
# so the 'variable' declaration has an effect
my variable @heredoc_stubs is context = (); # Writeable context!
# Compile time constant with local scope:
my constant $pi = 3.14;
# Package scoped constants can be useful!
say $Math::euler; # Prints constant value from package Math
# This data from database has to be 'readonly':
my final $temperature = db_temperature_of( $date_time_loc);
# But this is possible as well:
my $temperature = db_temperature_of( $date_time_loc);
if is_fine($temperature) {
final $temperature;
}
else {
$temperature = db_default_temperature();
final $temperature;
}
- /snip
I think this approach is quite expressive, readable and orthogonal
to everything else. In particular it is orthogonal to the scope.
Whenever you see the 'variable' declarator, you should think:
Attention, it is really variable.
With the "final" declarator you can lock a variable at
initialization and with the "final" build-in multi sub, you can
lock it at any time.
There may be better words than "final". I just thought, it matches
the meaning to some extend, its short and it can be used as a
verb and as a noun.
The approach is even extensible. I could imagine an otional
declarator for predeclared variables that requires that this
variables will really become defined.
Kind Regards
Stefan
-
Need a quick answer? Get one in minutes from people who know. Ask your question
on Yahoo! Answers.
Re: Relief for rw/ro
PS: In between, I think 'variable' is too long, so: $code =~ s/variable/vari/g; IMHO C is better than C because C doesn't look like a special thing, but it is. I feel that the most usual cases for read/write would be better readable with that approach. Instead of C<$res=funcy($foo is rw);> it would be C<$res=funcy(vari $foo);> And instead of C it would be C The question is probably if the writeability is a trait like other traits and should therefore be written in the C form or is it so special, that a second delararator is appropriate. The second declararator has the advantage that the very important information of exceptional write-protection or exceptional write-access stands on the left side, as it should be. Kind Regards Stefan - Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta.
Re: for ... else
I vote against this proposal.
More exceptional rules in a language are bad in itself.
Those exceptions force people to more to learn more stuff
and lead to confusion for those who don't know every detail
of this language. So, there should be an important reason
for that or it's a silly idea.
I think your proposal is conflicting with the common meaning
of 'else' and I fear that this would discourage many
professional programmers that are used to other languages,
to give perl6 a try. In other words: Features are good but
breaking conventions is bad.
On the other hand, there is no important reason for it because C<
for @rray -> $el {}
if ! @rray {}
>
should work. It's short and easy to understand.
So, I think there is no problem at all with the
currently specced syntax.
Kind Regards
Stefan
-
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
Re: Converting a Perl 5 "pseudo-continuation" to Perl 6
Hello,
I'd vote for the OO-style.
My reason is that the major criteria should be the reader perspective.
It should be as clear as possible what's going on in the main code
even if the reader doesn't know the hottest p6 tricks!
What you are doing here is: two operations on the same thing (the pidfile).
So the code should point out that it works twice on the same thing.
I think it's best to have an object to show this
whereas returning the sub/closure feels a bit confusing.
Your right, this style is busy work, but it's not pointless.
I would suggest a locally visible class to bring out the
local, one time usage of that class. Btw. what is the best way to do so?
Kind regards
Stefan
--- On Thu, 1/1/09, Geoffrey Broadwell wrote:
From: Geoffrey Broadwell
Subject: Converting a Perl 5 "pseudo-continuation" to Perl 6
To: perl6-us...@perl.org, perl6-langu...@perl.org
Date: Thursday, January 1, 2009, 3:34 PM
In the below Perl 5 code, I refactored to pull the two halves of the PID
file handling out of init_server(), but to do so, I had to return a sub
from pid_file_handler() that acted as a "continuation". The syntax
is a
bit ugly, though. Is there a cleaner way to this in Perl 6?
##
sub init_server {
my %options = @_;
# ...
# Do top (pre-daemonize) portion of PID file handling.
my $handler = pid_file_handler($options{pid_file});
# Detach from parent session and get to clean state.
become_daemon();
# Do bottom (post-daemonize) portion of PID file handling.
$handler->();
# ...
}
sub pid_file_handler {
# Do top half (pre-daemonize) PID file handling ...
my $filename = shift;
my $basename = lc $BRAND;
my $PID_FILE = $filename || "$PID_FILE_DIR/$basename.pid";
my $pid_file = open_pid_file($PID_FILE);
# ... and return a "continuation" on the bottom half
(post-daemonize).
return sub {
$MASTER_PID = $$;
print $pid_file $$;
close $pid_file;
};
}
##
When I asked this question on #perl6, pmurias suggested using
gather/take syntax, but that didn't feel right to me either -- it's
contrived in a similar way to using a one-off closure.
pmichaud offered several possibilities (I've converted some of his
suggestions expressed as prose into code, so the errors there are mine):
1. Take advantage of Perl 6 syntax reduction to turn 'return sub {...}'
into 'return {...}' (or even just fall of the end with
'{...}', I
suppose). This is visually slightly better, but still leaves the
bottom half inside a block that merely exists to satisfy Perl, not
actually representing anything intrinsic about the problem.
2. Throw a resumable exception in the middle:
sub init_server {
# ...
pid_file_handler($options{pid_file});
become_daemon();
pid_file_handler();
# ...
}
sub pid_file_handler {
# ... top half ...
throw ResumableException;
# ... bottom half ...
}
He also suggested a variant syntax with an adverb on return:
sub pid_file_handler {
# ... top half ...
return :resumable;
# ... bottom half ...
}
I suggested a naked yield syntax:
sub pid_file_handler {
# ... top half ...
yield;
# ... bottom half ...
}
These all desugar to the same thing, of course.
3. Make become_daemon a part of pid_file_handler, or vice-versa.
I rejected both of these on the basis of separating different
things into different subs. The two tasks are only tangentially
related, and neither really seems like a subordinate op of the
other.
4. In order to keep the sub separate, but still not split the
pid_file_handler call, I came up with a variation of #3 in which
pid_file_handler takes a callback parameter:
sub init_server {
# ...
pid_file_handler($options{pid_file}, &become_daemon);
# ...
}
sub pid_file_handler($pid_file, &callback) {
# ... top half ...
callback();
# ... bottom half ...
}
That seems like a silly contortion to hide the problem, and
doesn't represent my intent well -- the pid file handler doesn't
need to send a message, it needs to yield control while waiting
for something else to happen.
5. Make a new PidHandler class and address the problem in OO fashion:
sub init_server {
# ...
my $pid_handler = PidHandler.new(file => $options{pid_file});
$pid_handler.top();
become_daemon();
$pid_handler.bottom();
#...
}
This is certainly workable, but again feels like a contrived
workaround in the same way that gather/take and return {...} do.
Plus, writing a new class and using OO/method call syntax just to
allow a sub to be "split" seems like pointless busy work. Not
as bad in Perl 6 as in Perl 5, but still.
In the end, I think I like the 'naked yield' idea best of the ones we
have so far. Any comments or other ideas? [1]
-'f
[1] Other than that
