Re: RFC 83 (v1) Make constants look like variables
On Mon, Aug 14, 2000 at 06:28:23PM -0700, Nathan Wiger wrote: Well, just to counter argue, I feel exactly the opposite way. I'd like the keyword to be "constant" instead of "const". I've always thought "const" was a needless save of 3 characters. Constants should be obvious to pick out. The inventors of UNIX, when asked "What was your biggest mistake?" replied "Spelling creat() without the 'e'". Ditto here, IMO. Amen. Which is the easiest for anyone to tell what's going on? my num $PI : constant = 3.1415926; my num $PI : const = 3.1415926; my num $PI =| 3.1415926; Admittedly, "const" is pretty darn close to "constant", so tolerable. But =| is way too obscure, I think. Not only obscure but backwards IMHO. Rather than using some weird assignment operator to modify the attributes of a scalar (after all, constancy is a property of the scalar), better the attributes should be verbose and explicit. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 83 (v1) Make constants look like variables
Jonathan Scott Duff wrote: On Mon, Aug 14, 2000 at 06:28:23PM -0700, Nathan Wiger wrote: Well, just to counter argue, I feel exactly the opposite way. I'd like the keyword to be "constant" instead of "const". I've always thought "const" was a needless save of 3 characters. Constants should be obvious to pick out. The inventors of UNIX, when asked "What was your biggest mistake?" replied "Spelling creat() without the 'e'". Ditto here, IMO. Amen. Which is the easiest for anyone to tell what's going on? my num $PI : constant = 3.1415926; my num $PI : const = 3.1415926; my num $PI =| 3.1415926; Admittedly, "const" is pretty darn close to "constant", so tolerable. But =| is way too obscure, I think. Not only obscure but backwards IMHO. Rather than using some weird assignment operator to modify the attributes of a scalar (after all, constancy is a property of the scalar), better the attributes should be verbose and explicit. Yes, I agree too. I'm going to submit a v2 of this RFC shortly, which will clarify a few points about the use of const with lists and hashes and make the change to attribute notation, but otherwise will be pretty much the same. Since there hasn't really been concensus on this issue, those interested in alternative notation, or a wider array of scenarios where constant can be used, should submit a counter-RFC.
Re: RFC 83 (v1) Make constants look like variables
On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote:
Please, please, please, PLEASE, let us not replicate the debacle that is
C++'s const modifier!
It doesn't feel like a debacle to me, it feels like it put the control
in the programmers hands. Yes, the syntax is often unweildy -- but IMHO
that's because when one marries the idea of constants to complex data
structures and references, the world becomes an unweildy place.
On the other hand, many of the uses of constants are better-satisfied
by having hidden or inaccessible members. If constants were limited
to `core' perl data types (scalars, lists, arrays and hashes) and
*completely* freezing the data element, that'd be enough for me. I lust
to be able to do things like
if ( $HOME =~ /indiana/ ) {
local $::PI : const = 3; do_trig();
} else {
local $::PI : const = 3.14159...; do_trig();
}
(I'm from Indiana and claim right to use that joke without being
insulting). Constants are good, and I'm damned tired of fixing code like
if ( $PI = 3 ) {
# We're not in Kansas any more, Toto.
}
Constants have a place, and belong in perl.
Now, one may argue that my suggestion was too flexible or too broad.
But the initial proposal left an awful lot of gray areas. If my proposal
is felt to be too unweildy, I don't have a problem with that. Let's
either
o decide where to draw the line, define it cleanly, and say
that more complex usage is better done with objects; or
o permit both complex constants and object-based manipulations
on the practice that TMTOWTDI.
I lean towards the latter (complex constants) myself, but wouldn't
go off and storm the barricades to get it. On the other hand, I
*would* campaign strongly for constant scalars, lists, arrays, hashes
and refs. If the only way to get them meant `completely constant',
ie, no addition or removal or members, no re-orderings, etc, that's
fine -- composition of complex constants with complex vars would let
one do most of what was suggested in my longer posting, and I'd be
happy to say the odder features should be done via object methods.
Re: RFC 83 (v1) Make constants look like variables
I agree that constants deserve a prominent place in Perl, as they offer
constaint which can be beneficial to programmers. Sometimes its nice to know
that I mistakenly tried to treat a static variable as dynamic.
I disagree with "const" as it's verbose; I'd rather see something like
$pi=|3.14128 or something similar.
I've noted a few messages here with statements like "it looks like C++" and
"I hated that in Pascal" and so on. If we restricted ourselves to constructs
not found in other languages, there would be no Perl as we know it today.
Larry freely admits he borrowed constructs and techniques from many
languages.
There are many logical reasons for and against the RFC's here, but saying
"it looks like c so it doesn't make it for me" is a weak argument at best.
-WQ
From: Steve Simmons [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], Steve Simmons [EMAIL PROTECTED],Larry Wall
[EMAIL PROTECTED], Mike Pastore [EMAIL PROTECTED],Jeremy
Howard [EMAIL PROTECTED]
Subject: Re: RFC 83 (v1) Make constants look like variables
Date: Mon, 14 Aug 2000 12:57:14 -0400
On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote:
Please, please, please, PLEASE, let us not replicate the debacle that is
C++'s const modifier!
It doesn't feel like a debacle to me, it feels like it put the control
in the programmers hands. Yes, the syntax is often unweildy -- but IMHO
that's because when one marries the idea of constants to complex data
structures and references, the world becomes an unweildy place.
On the other hand, many of the uses of constants are better-satisfied
by having hidden or inaccessible members. If constants were limited
to `core' perl data types (scalars, lists, arrays and hashes) and
*completely* freezing the data element, that'd be enough for me. I lust
to be able to do things like
if ( $HOME =~ /indiana/ ) {
local $::PI : const = 3; do_trig();
} else {
local $::PI : const = 3.14159...; do_trig();
}
(I'm from Indiana and claim right to use that joke without being
insulting). Constants are good, and I'm damned tired of fixing code like
if ( $PI = 3 ) {
# We're not in Kansas any more, Toto.
}
Constants have a place, and belong in perl.
Now, one may argue that my suggestion was too flexible or too broad.
But the initial proposal left an awful lot of gray areas. If my proposal
is felt to be too unweildy, I don't have a problem with that. Let's
either
o decide where to draw the line, define it cleanly, and say
that more complex usage is better done with objects; or
o permit both complex constants and object-based manipulations
on the practice that TMTOWTDI.
I lean towards the latter (complex constants) myself, but wouldn't
go off and storm the barricades to get it. On the other hand, I
*would* campaign strongly for constant scalars, lists, arrays, hashes
and refs. If the only way to get them meant `completely constant',
ie, no addition or removal or members, no re-orderings, etc, that's
fine -- composition of complex constants with complex vars would let
one do most of what was suggested in my longer posting, and I'd be
happy to say the odder features should be done via object methods.
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: RFC 83 (v1) Make constants look like variables
Steve Simmons writes: : On Sat, Aug 12, 2000 at 06:18:08AM +1000, Damian Conway wrote: : : Please, please, please, PLEASE, let us not replicate the debacle that is : C++'s const modifier! : : It doesn't feel like a debacle to me, it feels like it put the control : in the programmers hands. Yes, the syntax is often unweildy -- but IMHO : that's because when one marries the idea of constants to complex data : structures and references, the world becomes an unweildy place. Hmm, well, we'll certainly have constants of some sort or another. I don't think Damian needs to worry about me making Perl look like C++. I've also grown to detest the fact that every other word in a typical C++ program is "const". My inclination at this point is make certain things constant by default (such as the insides of a complex constant, and the parameters to a subroutine), and then have a way of "undeclaring" constancy if you really want it. It would perhaps be considered bad form to vary someone else's constants. (Outside of Indiana.) Larry
Re: RFC 83 (v1) Make constants look like variables
Nick Ing-Simmons wrote: Ed Mills [EMAIL PROTECTED] writes: There are many logical reasons for and against the RFC's here, but saying "it looks like c so it doesn't make it for me" is a weak argument at best. I don't think anyone made that argument - they have all been "I hate that in ..." type comments. You forget... There have been numerous cases of people saying things like "that's what Python [or Java] calls those functions, so we should call them something else." -- John Porter
Re: RFC 83 (v1) Make constants look like variables
John Porter [EMAIL PROTECTED] writes: Nick Ing-Simmons wrote: Ed Mills [EMAIL PROTECTED] writes: There are many logical reasons for and against the RFC's here, but saying "it looks like c so it doesn't make it for me" is a weak argument at best. I don't think anyone made that argument - they have all been "I hate that in ..." type comments. You forget... There have been numerous cases of people saying things like "that's what Python [or Java] calls those functions, so we should call them something else." You may be right - though as I recall those were "that's what X calls those functions, ours don't work the same so we should call them something else" My point was if experienced folk don't like something somewhere else we should think twice before borrowing it. The _names_ don't matter much at this stage - Larry can change them but if "making things const like C++" is a bad idea then it is a bad idea - A midden by any other name would smell as foul. -- Nick Ing-Simmons
Re: RFC 83 (v1) Make constants look like variables
Philip Newton wrote: $'bar = 'unchanging'; # klingon? Has there ever been an RFC discussing retention or deletion of this backwards-compatibility feature? Yes. :) RFC71, which caused much grief to Damian: Now he will never be able to port his new Klingon.pm to Perl 6. $pkg'var! $det'yiu! -- Mike Pastore [EMAIL PROTECTED]
Re: RFC 83 (v1) Make constants look like variables
How would this take into account stuff like this:
sysopen(HANDLE, "/etc/motd", O_RDWR|O_CREAT, 0644);
The "O_RDWR|O_CREAT" part is what I'm talking about here. This is a
constant w/o suffix. We'll either have to:
1. Change it to $O_RDWR|$O_CREAT or $O{RDWR}|$O{CREAT}
Maybe for errors us $E{AGAIN} and so on?
2. Make special exceptions for "special" constants
I'd *definitely* prefer #1, although we do run the risk of confusing
some C folks. Not that that should stop us, but just something to think
about. The %O and %E hashes might be kind of neat - you could check out
all the supported options and errors just by walking a hash with a short
C-esque name. Plus the top-level namespace is much cleaner.
-Nate
Re: RFC 83 (v1) Make constants look like variables
Spinning off from Larrys syntactic comment and Mike Pastores example, how about some of the following: How about any variable created in UPPER case is a constant? Quite restrictive, and likely to screw many things up, admittedly, but it's an easy rule to remember and one which is generally considered good programming practice. ISTR it's what Ruby uses. It works well for all those Perl-provided variables (e.g. $ME) that *should* be read-only, but not so good for those that are supposed to be read/write (e.g. @INC). A
Re: RFC 83 (v1) Make constants look like variables
On Fri, 11 Aug 2000, Andy Wardley wrote: Spinning off from Larrys syntactic comment and Mike Pastores example, how about some of the following: How about any variable created in UPPER case is a constant? Quite restrictive, and likely to screw many things up, admittedly, but it's an easy rule to remember and one which is generally considered good programming practice. ISTR it's what Ruby uses. It works well for all those Perl-provided variables (e.g. $ME) that *should* be read-only, but not so good for those that are supposed to be read/write (e.g. @INC). Or perhaps merely a new identifier, ie: $:pi = 3.1459;# constant pi %:struct = ( # constant struct :Name = 'Jack', # constant key (I got tired of Jane) Age = 32,# mutable key :Birthday = '08/15' ); what about: $!foo = 'immobile';# mnemonic, NOT as in NOT change $'bar = 'unchanging'; # klingon? $.zot = 'static'; Foo for thought. -- Mike Pastore [EMAIL PROTECTED]
Re: RFC 83 (v1) Make constants look like variables
On Fri, Aug 11, 2000 at 06:36:44PM +0100, Andy Wardley wrote: How about any variable created in UPPER case is a constant? This involves Perl dictating style to the user. Very un-Perllike, IMHO. Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
Re: RFC 83 (v1) Make constants look like variables
Please, please, please, PLEASE, let us not replicate the debacle that is C++'s const modifier! Damian
Re: RFC 83 (v1) Make constants look like variables
Steve Simmons wrote: I really like the idea of constants in perl, but think the RFC should go a lot further. C/C++ has solved this problem; we should follow in their footsteps. ... I desparately _don't_ want to follow the horrible mess that is const in C++. The enormous hassle in trying to do any sensible optimisation on C++'s consts has been a real nightmare. Trying to find a way of adding a 'restrict' keyword which actually does something useful has been just as bad. For why guarantees of aliasing and constness are important, see for example: http://oonumerics.org/oon/oon-list/archive/0328.html The same sort of thought process should be applied to lists, arrays, references, and objects. IMHO the RFC should be updated to reflect all these issues before we can properly consider it. Sorry to rain all over your parade, Jeremy. The core idea is great, but the implementation section really needs expansion. It's not like that! An RFC is the start of a discussion, not the last word... Your interesting ideas are not 'raining on my parade'--they're very constructive thoughts and I really appreciate them. This is certainly an area I've been thinking about--as I said in an earlier post: quote Yes. But what about types and attributes within complex types? - Constant refs vs refs to constants? - Types of hash (or 'pair') keys and elements? - Attributes (e.g. constantness) of hash keys and elements? - Ditto for arrays/lists... I left this out of v1 of the RFC because I wanted to get some feedback on syntax. If we can flesh this out I'll incorporate it into v2. /quote My current thinking is that a ref to a constant should only be possible through creating a constant first, and then creating a reference to that separately. I'm still unsure of array and hash elements, however. Using the ':' in this way has the potential to cause ambiguity with list generation syntax (RFC 81), and add complexity where there may not be much payoff. I really need to see some examples of code where this would be of practical benefit, I think.
Re: RFC 83 (v1) Make constants look like variables
At 11:07 AM 8/12/00 +1000, Jeremy Howard wrote: My current thinking is that a ref to a constant should only be possible through creating a constant first, and then creating a reference to that separately. What, like: $foo = \5' which you can do in perl 5 right now. (Basically a scalar's created (probably), given the value '5', and marked read-only) I'm still unsure of array and hash elements, however. Using the ':' in this way has the potential to cause ambiguity with list generation syntax (RFC 81), and add complexity where there may not be much payoff. If you want individual elements of hashes or arrays to be read-only, that's OK, though I can see that complicating things. And constants, of course, may well be substituted for in the bytestream anyway--if you write: my $foo : const = 5; $bar = $foo; you may well get: $bar = 5; under the hood. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Does Perl need true constants? (was Re: RFC 83 (v1) Make constants look like variables)
How about any variable created in UPPER case is a constant?
Well, Perl does something similar now, just that they're not readonly.
But as everyone knows messing with @ISA, %ENV, BEGIN, FETCH, etc, etc,
etc will definitely alter your program.
Do we really need constants in Perl? I've always wondered why constants
are necessary. For one thing, I think the name is bad, since it implies
they must be readonly and static. I think "definitions" or "specifiers"
is better.
I think a set of rules like this:
1. Anything in all-UPPER case is reserved for Perl
2. But do whatever you want
Is an argument for removing "use constant" and constants altogether. If
a person wants to do something like this in Perl 6:
$STDOUT = $myfileobject;
print "Hello, world!\n";
$O{RDWR} = 42;
open sys "/etc/motd", $O{RDWR}|$O{CREAT}, 0644;
Let them! They probably know what they're doing. And if they don't, then
they should have read rule #1.
And, if you want to roll your own "definitions", you can do so in
modules. They just won't be readonly, but this is something that can be
circumvented by simple accessor functions:
my $f = new Custom::FileModule;
print "The default file is ", $f-constant('DEFAULT_FILE');
Which is probably similar to what you'd end up doing if you're writing a
big site-wide module anyhow. A big problem with NOT doing it this way
(and just creating $ALLCAPS scalars/hashes/etc) is that if Perl 6.2.1
decides $PI is going to be "Paragraph Indicator", you're in big trouble.
Anyways, I'm not really strongly-opinionated, but I do think that the
syntax has to be extremely simple, like what Larry suggested earlier in
the thread:
my num $PI : constant = 3.1415926;
my int @FIB : constant = (1,1,2,3,5,8,13,21);
I disagree with Steve Simmons; I don't think creating huge struct-like
hashes is the way to go. Just make the variable readonly. "Perl isn't
really a very paranoid language anyways" (or something like that). :-)
-Nate
Re: RFC 83 (v1) Make constants look like variables
Perl6 RFC Librarian wrote: It is proposed that a new syntax for declaring constants be introduced: my constant $PI = 3.1415926; my constant @FIB = (1,1,2,3,5,8,13,21); my constant %ENG_ERRORS = (E_UNDEF='undefined', E_FAILED='failed'); I like this. Implementation wise, it could fit nicely with the DRAFT structure RFC, which needs things that look like hashes with a constant set of keys, although for structures, the values can vary with the method calls. -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
Re: RFC 83 (v1) Make constants look like variables
my %STRUCT : constant = ( Name =str 'Jane', Isn't this ambiguous, considering that the = operator quotes the left side? -Hao
Re: RFC 83 (v1) Make constants look like variables
nitpickyA semantic definition of "constant" would be nice./nitpciky I'd like to propose the following definition: A constant value cannot be assigned to, deleted, or used as the argument to a mutating function/operator. Doing any of these would be a catchable error. (However, it can be deleted by the GC, and thus may have a DESTROY method.) It cannot be local()ized, unless the "localizable" flag was given, IE my $foo = 42 : constant(localizable); (This should be an error sepperate from "cannot localize" and "assignment to a constant".) Note that I use the word "value" and not "variable". I suggest that additionaly, in a hash if a key is constant, it means that the key cannot be deleted, but it's value can be changed. To make the whole pair constant, set the value to be a constant -- removing the key would imply deleting the value as well, which is an error. A hash being constant, or a list being constant implies that all of it's members are constant. A ref to a thingy being constant is different from a ref to a constant thingy. The constant attribute can never be removed from a variable once it is set. The localizable flag cannot be added later, but can be removed. There may be other flags in the future; their addablity/removeablility is not defined. The constant attribute is rather odd in that normaly, somthing of the form "my $foo = 42 : attrib" creates $foo, sets it's "attrib" attribute, and then assigns 42 to it. OTOH, the constant attribute is set after the assignment -- otherwise the assignment would always be in error! -=- James Mastros
Re: RFC 83 (v1) Make constants look like variables
On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote: This method of creating constants has three serious drawbacks: They're also quite heavy, although I think that CONSTSUB was to take care of that. What I never understood, although I'm sure there's a very simple reason, is why it wasn't simply made a read-only scalar. -- Bryan C. Warnock ([EMAIL PROTECTED])
RFC 83 (v1) Make constants look like variables
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Make constants look like variables
=head1 VERSION
Maintainer: Jeremy Howard [EMAIL PROTECTED]
Date: 10 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 83
=head1 ABSTRACT
This RFC proposes that the current constant.pm module removed, and
replaced with a syntax allowing any variable to be marked as constant.
=head1 DESCRIPTION
Currently, constants are created in Perl using the constant.pm module:
use constant PI = 3.1415926;
which creates an inlined subroutine:
sub PI () {3.1415926;}
This method of creating constants has three serious drawbacks:
=over 8
=item Can not be interpolated in strings
Whereas variables can be interpolated into strings (e.g. "PI is $Pi"),
subroutines can not be. This makes using constants inconvenient, since
string concatenation must be used.
=item Inconsistant syntax
The sudden appearance of barewords can be quite unsettling to new users.
After becoming told that 'arrays are @name, scalars are $name, ...', the
rule suddenly stops working just because the programmer wants the value to
stay constant.
=item Redundant warnings
In persistant Perl environments such as mod_perl, inlined subroutines
often created the redundant warning 'Constant subroutine PI redefined'.
This has been a frequent source of confusion amongst new mod_perl users.
=back
It is proposed that a new syntax for declaring constants be introduced:
my constant $PI = 3.1415926;
my constant @FIB = (1,1,2,3,5,8,13,21);
my constant %ENG_ERRORS = (E_UNDEF='undefined', E_FAILED='failed');
Constants can be lexically or globally scoped (or any other new scoping
level yet to be defined).
=head1 IMPLEMENTATION
Constants should have the same behaviour as the do now. They should be
inlined, and constant expressions should be calculated at compile time.
=head1 REFERENCES
perldoc constant; perldoc perlsub (for constant subroutines)
