Re: Static Values and Variable Bindings [was RE: Perl 6 -Cheerleader s?]
Brent Dax [EMAIL PROTECTED] writes:
Garrett Goebel:
# my int ($pre, $in, $post) is constant = (0..2);
#
# Means that you are asking for compile time optimizations, and
# agreeing not
# to bless references to, or ascribe run-time properties to
# those scalars. So
# we've already got variables with constant values.
#
# I guess my question is, does the compile time optimization
# for the above
# case imply that you can't later do:
#
# $pre := $post;
#
# If it doesn't then I'll cease and desist... If it does, then wouldn't:
#
# my scalar $foo is constant = 'bar';
#
# be the 'type' general way to make both a scalar variable
# binding and its
# value constant?
Could you do C%MY::{'$pre'} is constant to lock the symbol table
entry?
Ooh... I like that thought. Maybe C%MY::{'$pre'} is final?
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Static Values and Variable Bindings [was RE: Perl 6 - Cheerleader s?]
On Thu, Nov 01, 2001 at 10:13:22PM -0500, Ken Fox wrote: On the other hand, people live with C's preprocessor and its #undef/#define of constants. If C programmers don't mind having different parts of a program compiled with different values for the same constant, then why should Perl programmers? ;) I'm a C programmer and I *do* mind such use of cpp. But, as you, I'm learning to cope. As long as I can create closures and their lexicals can't be magically or otherwise mucked with, I'm happy ;-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: Static Values and Variable Bindings [was RE: Perl 6 - Cheerleader s?]
From: Ken Fox [mailto:[EMAIL PROTECTED]] Here in the 10-step Perl 6 program we don't talk about resolution. We just learn to cope with change. ;) ;) I'm still working to grok the changes. I thought I was getting generally clued in after reading the Apocalypses/Exegesises... but discussions on the list have steadily been eroding that sense of understanding. there will probably be pragmas to disable run-time mucking with lexicals. Same thing for compilation. I at some point possibly: s/will probably/will/ Right now it looks like Perl6 will make it harder to encapsulate things in the sense of data-hiding. Re-defining constants is a simliar thing and I have similar reservations. It might make reading programs harder. It will definitely hurt compilation. The trouble will be that the compiler can't inline a constant. my int $foo is constant = 'bar'; Just does compile-time typing for $foo? Not inlining the constant? Exegesis 2 says you can't bless a reference to my int $foo, or ascribe run-time properties to it. Doesn't this imply that the compiler would be able to inline it? I was thinking lowercase typed variables couldn't be rebound, because they were compile-time optimized... Can they? Or are we back to the selective use of yet to be named pragmas?
Re: Static Values and Variable Bindings [was RE: Perl 6 - Cheerleader s?]
On Thu, 1 Nov 2001, Garrett Goebel wrote:
On Wed, 31 Oct 2001, David Nesting wrote:
On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote:
: Yep, but in Perl5, this was never very clean or obvious to the
: casual programmer. Constants have been coming of age in Perl,
: and they're kind of scary if they're not constant.
On one hand, one might say that a developer changing a constant's
binding in order to change its value is probably doing so because he
knows what he's doing. As I understand things, constants are really
just read-only variables. Do we necessarily want to make a special
case out of them and make the variable read-only as well as locking
down the symbol itself against re-binding?
One can always turn that argument around, and say that the developer
may want to lock down both the variable's binding and the bound
value... because he wants to depend on it (always) doing what he wants
it to do. What are we going to have for variable bindings?
A developer shouldn't need to lock down that binding at least for
lexically scoped vars, because what matters is the value in this case.
And as for global constants, what about:
sub MY_CONSTANT () { 1234; }
Using variables for constants in this sense seems weird to me. :-)
- D
[EMAIL PROTECTED]
RE: Static Values and Variable Bindings [was RE: Perl 6 - Cheerleader s?]
From: David M. Lloyd [mailto:[EMAIL PROTECTED]]
On Thu, 1 Nov 2001, Garrett Goebel wrote:
On Wed, 31 Oct 2001, David Nesting wrote:
On Tue, Oct 30, 2001, Aaron Sherman wrote:
: Yep, but in Perl5, this was never very clean or obvious
: to the casual programmer. Constants have been coming of
: age in Perl, and they're kind of scary if they're not
: constant.
On one hand, one might say that a developer changing a
constant's binding in order to change its value is probably
doing so because he knows what he's doing. As I understand
things, constants are really just read-only variables. Do
we necessarily want to make a special case out of them and
make the variable read-only as well as locking down the
symbol itself against re-binding?
One can always turn that argument around, and say that the
developer may want to lock down both the variable's binding
and the bound value... because he wants to depend on it
(always) doing what he wants it to do. What are we going to
have for variable bindings?
A developer shouldn't need to lock down that binding at least
for lexically scoped vars, because what matters is the value
in this case. And as for global constants, what about:
Except that in Perl6, I'll be able to easily mess with lexically scoped vars
in your modules if I want to. Remember Damian's discussion about injecting
and accessing lexicals in a caller's scope in the context of Aspect Oriented
Programming (AOP)?
Perhaps you want to nail some things down that you want to be able to depend
on? Maybe someone'll even put modules out on CPAN that mess with other core
modules' lexical vars? Then core module authors'll start getting bug reports
because someone abused their code in a manner they wish'd they could have
explicitly forbidden.
Isn't this basically a subset of the same topic that drove Ken Fox into
shock and dismay not that long ago? Though I believe KENFOX, was more
worried about the loss of data-hiding with Perl6's lexicals. Was that ever
resolved? Will there be a way in Perl6 to explicitly state that my $foo is
inaccessible outside its scope?
I know Perl isn't commonly associated with Bondage and Discipline... but
can't Perl make it possible for the BnD Perl programmers out there have it
if they want it? A lot of people think we're sadomasochists for programming
in Perl anyway ;) What's the addition of a little semantics to up the
dominatrix of unsafe constructs?
sub MY_CONSTANT () { 1234; }
Using variables for constants in this sense seems weird to me. :-)
Put that way, I'd kind of agree. Constant variables? variable constants? Its
a pretty ugly oxymoron. But that doesn't matter if it's already writ in
stone for Perl6...
Exegesis 2 did say that:
my int ($pre, $in, $post) is constant = (0..2);
Means that you are asking for compile time optimizations, and agreeing not
to bless references to, or ascribe run-time properties to those scalars. So
we've already got variables with constant values.
I guess my question is, does the compile time optimization for the above
case imply that you can't later do:
$pre := $post;
If it doesn't then I'll cease and desist... If it does, then wouldn't:
my scalar $foo is constant = 'bar';
be the 'type' general way to make both a scalar variable binding and its
value constant?
RE: Static Values and Variable Bindings [was RE: Perl 6 - Cheerleader s?]
Garrett Goebel:
# my int ($pre, $in, $post) is constant = (0..2);
#
# Means that you are asking for compile time optimizations, and
# agreeing not
# to bless references to, or ascribe run-time properties to
# those scalars. So
# we've already got variables with constant values.
#
# I guess my question is, does the compile time optimization
# for the above
# case imply that you can't later do:
#
# $pre := $post;
#
# If it doesn't then I'll cease and desist... If it does, then wouldn't:
#
# my scalar $foo is constant = 'bar';
#
# be the 'type' general way to make both a scalar variable
# binding and its
# value constant?
Could you do C%MY::{'$pre'} is constant to lock the symbol table
entry?
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, Im not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
--Dubya
Re: Static Values and Variable Bindings [was RE: Perl 6 - Cheerleader s?]
Garrett Goebel wrote: worried about the loss of data-hiding with Perl6's lexicals. Was that ever resolved? Here in the 10-step Perl 6 program we don't talk about resolution. We just learn to cope with change. ;) There were two issues I had. As a Perl 6 user I felt uncomfortable that Perl 6 is encouraging people to violate lexical scoping. The other was that it seemed impossible to compile any code if a caller at run-time can yank the lexical carpet out from underneath a sub. Happily I've learned to cope with both. I think in serious code people won't do it -- there will probably be pragmas to disable run-time mucking with lexicals. Same thing for compilation. Some Perl 6 features just might not work when compiled to JVM or .Net or native code. (I think Java Python is proof that this isn't a huge problem in practice.) Re-defining constants is a simliar thing and I have similar reservations. It might make reading programs harder. It will definitely hurt compilation. The trouble will be that the compiler can't inline a constant. If it can't inline the constant, then it won't be able to do constant folding, dead code elimination and a whole bunch of other cool stuff. On the other hand, people live with C's preprocessor and its #undef/#define of constants. If C programmers don't mind having different parts of a program compiled with different values for the same constant, then why should Perl programmers? ;) - Ken
