:
M S11-modules.pod
Log Message:
---
Constants, enums and (our) variables are also exportable (I hope)
Message:
---
generics can produce constants without declarator
For the purposes of determining whether a variable is declared
constant, it is not enough to consider whether the C
declarator has been used. Generic code that instantiates parameters
with constant arguments can also produce
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>Behalf Of Mark J. Reed
>Sent: Monday, April 14, 2008 2:05 PM
>To: Jonathan Worthington
>Cc: David Green; Perl6
>Subject: Re: Idea: infer types of constants
>
>On Mon, Apr 14
TSa wrote:
Jonathan Worthington wrote:
Miller, Hugh wrote:
Was that private communication or on another mailing list?
It was also sent to perl6-language, through I was on the To or Cc line
too, so I guess that's how I got it but the list, somehow, didn't. Not
sure why the original message I r
Miller, Hugh wrote:
What about the type support (system) one sees in ML ? (e.g., the way it
assigns automatically types can be assigned, does not require specific
types when they are not needed, flags incompatibilities, etc.) Do those
things not fit well with Perl's approaches and aims ?
They
HaloO,
Jonathan Worthington wrote:
Miller, Hugh wrote:
Was that private communication or on another mailing list?
What is the type of $b? Well, we can't actually infer that because foo
might be:
sub foo() {
$OUTER::a = "oh hi, i iz not int!"
}
That should be $CALLER::a because $OUTER
HaloO,
John M. Dlugosz wrote:
Then the declaration
my ::T $x = whatever;
should use the exact same generic mechanism! At worst, it needs
I would expect that this works by binding ::T to the type of whatever.
my Any ::T $x = whatever;
Any here is optional.
and it will introduce th
Mark J. Reed markjreed-at-mail.com |Perl 6| wrote:
On Mon, Apr 14, 2008 at 2:32 PM, Jonathan Worthington
my Dog $fifi .= new(); # works in Rakudo too ;-)
And even in Pugs! :) Doesn't help with literals, though, e.g.
my Float $approx_pi = 3.14;
So the idea of marking the use of
To me the foo looks like a template sub and I wonder how it is
instanciated with different types. Since type parameters are
provided with [] it should be foo[Int], foo[Str] and the like.
I wonder further if that could also be written foo of Str like
with Array of Int etc.
my foo of Int &intfo
On Mon, Apr 14, 2008 at 2:32 PM, Jonathan Worthington
> my Dog $fifi .= new(); # works in Rakudo too ;-)
And even in Pugs! :) Doesn't help with literals, though, e.g.
my Float $approx_pi = 3.14;
--
Mark J. Reed <[EMAIL PROTECTED]>
Mark J. Reed wrote:
I don't care for the use of * there, but it would be nice to have some
way to declare the variable to have the type implied by its
initializer, where the complier can tell what that is, so you could
remove the redundancy in this:
my Dog $fido = new Dog();
while still allowin
strong typing and static types
> > should say that the compiler =will= implicitly get the type for $pi
> > rather than making it Any.
>
> Except if constants infer their type and other variables don't, that's
> one more special case to remember. What if there were a
ny.
Except if constants infer their type and other variables don't, that's
one more special case to remember. What if there were a quick and
unobtrusive way to get the type of the value instead of "Any"? Can we
use a "whatever" type?
my * $x =
HaloO,
Brandon S. Allbery KF8NH wrote:
our ::T sub foo (T $a, T $b)
without needing to introduce a new twigil syntax for type variables.
My reading as well. But I would write it sub foo (::T $a, T $b --> T)
for better indicating that ::T is taken from the parameters.
(Although I would won
On Apr 13, 2008, at 2:02 , John M. Dlugosz wrote:
In Perl 6, I think you would have to arrange to write the return
type later rather than sooner to do this:
sub foo (::T $a, T $b)
is of T
and writing it the other way around would violate the one-pass
parsing.
Just from looking at thi
I'm thinking that if strong typing is enabled, mixing untyped and typed
things will cause warnings or errors that need not be there.
I'm thinking that 'constant' is more special than other variables, and
that the formal description of strong typing and static types should say
that the compiler
John M. Dlugosz wrote:
> Just surfing, I noticed something about the "D" programming language:
>
> "
> The types of constants need not be specified explicitly as the compiler
> infers their types <http://en.wikipedia.org/wiki/Type_inference> from
&
Just surfing, I noticed something about the "D" programming language:
"
The types of constants need not be specified explicitly as the compiler
infers their types <http://en.wikipedia.org/wiki/Type_inference> from
the right-hand sides of assignments.
const fact_7 = Fac
All sounds good up to:
Larry Wall wrote:
The cultural ambiguity is also being reduced insofar as we're trying
to discourage use of bare constants in favor of sigilled constants.
If you see a bare function name you should generally assume it
has arguments in Perl 6.
Well, in that case, s
On Thursday 17 August 2006 21:27, David Green wrote:
> However, what I'm wondering is whether Order::Same is "but true" and
> the others "but false"? (Which makes cmp in boolean context the same
> as eqv, but it seems to make sense that way.)
OTOH, C programmers can as well assume 'cmp' being an
I don't know if I've made this clear, but over the last few years I've
been treating "but True" and "but False" as design smells. They're
fine as a workaround for dire circumstances and uncooperative types,
but you'll not find me designing very many of the core interfaces to
use them, or other run
On Thu, Aug 17, 2006 at 11:27:21AM -0600, David Green wrote:
: However, what I'm wondering is whether Order::Same is "but true" and
: the others "but false"? (Which makes cmp in boolean context the same
: as eqv, but it seems to make sense that way.)
We should not be encouraging people to use c
On 8/17/06, Reed, Mark (TBS) wrote:
S03, lines 418-420: "[cmp] always returns C,
C, or C (which numerify to -1, 0, or +1)."
Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
which case it would be clearer to put them in respective order above...
Maybe you could view it e
-- Original message --
From: "Reed, Mark (TBS)" <[EMAIL PROTECTED]>
> S03, lines 418-420: "[cmp] always returns C,
> C, or C (which numerify to -1, 0, or +1)."
>
> Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
> which case it would be cl
S03, lines 418-420: "[cmp] always returns C,
C, or C (which numerify to -1, 0, or +1)."
Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In
which case it would be clearer to put them in respective order above...
Adam Kennedy wrote:
Forgive my ignorance here, but for all of these different ways of doing
constants, will they all optimize (including partial
evaluation/currying) at compile/build/init/run-time?
my $gravity is constant = 10; # One significant figure
sub time_to_ground ($height, $accel
[EMAIL PROTECTED] (Adam Kennedy) writes:
> Forgive my ignorance here, but for all of these different ways of
> doing constants, will they all optimize (including partial
> evaluation/currying) at compile/build/init/run-time?
Gosh, I hope not.
> my $gravity is constant = 10; # One
Ingo Blechschmidt wrote:
Hi,
# Way 1
my $MEANING_OF_LIFE is constant = 42;
Forgive my ignorance here, but for all of these different ways of doing
constants, will they all optimize (including partial
evaluation/currying) at compile/build/init/run-time?
my $gravity is constant = 10
Hi,
"TSa (Thomas Sandlaß)" wrote:
> Ingo Blechschmidt wrote:
>> Or did you simply forget the braces around 42? :)
>
> No, it was intented for seeing what the reactions will be :)
:)
> Just using &foo as unsigiled variable. This might need
>
> my &foo is rw;
I don't think this will DWYW, as fi
Ingo Blechschmidt wrote:
is that allowed (as 42 is a Num (or an Int), not a Code)?
I don't know, but guess not.
Do (most of) the basic types morph themselves into Codes, when needed?
I don't consider it type morphing. If your examples parse
at all they will be dispatched as usual
say 4
Hi,
"TSa (Thomas Sandlaß)" wrote:
> my &MEANING_OF_LIVE = 42; # But might be considered evil sigilless
> mode
is that allowed (as 42 is a Num (or an Int), not a Code)?
Do (most of) the basic types morph themselves into Codes, when needed?
say 42();# 42?
say "Perl"();
Ingo Blechschmidt wrote:
# Please add more ways :)
enum ;
my &MEANING_OF_LIVE = 42; # But might be considered evil sigilless mode
--
TSa (Thomas Sandlaß)
Hi,
# Way 1
my $MEANING_OF_LIFE is constant = 42;
# Way 2
my &MEANING_OF_LIVE = -> () { 42 };
# or
sub MEANING_OF_LIVE () { 42 }
# Then one can use sigilless constants:
say MEANING_OF_LIVE;
# Way 3 (still possible?)
use constant MEANING_OF_LIVE => 42;
# W
On Fri, Mar 18, 2005 at 03:38:38PM +0800, song10 wrote:
: hi, all
:
: is there any way to import constants from other modules without
: specifying scope everytime?
: such like this:
:
: module A;
: use constant { PI => 3.14, VER => 1.1 }
: ...
:
:
:
: module B;
: my $var = A::PI;
hi, all
is there any way to import constants from other modules without
specifying scope everytime?
such like this:
module A;
use constant { PI => 3.14, VER => 1.1 }
...
module B;
my $var = A::PI; # this way is fine when A is 'short' or rare
imagination
module C;
ive oft wondered how a constant/parameter namespace could be designed to:
- lighten Exporter symbol export in perl 5
- expose (for example) POSIX constants in only the contexts where
theyre meaningful
within a POSIX call - ex various c-open flags (im too lazy
to cite any
> SO MUCH baggage. "final" has Java baggage. "only", "stable",
> "ro" or "firm" might be the way to go. "unbindable" is a bit of a
> mouthfull... Perhaps "fixed" or "eternal" would be good.
I'm rea
On Tue, Oct 30, 2001 at 04:15:46PM -0600, David M. Lloyd wrote:
> On Wed, 31 Oct 2001, Damian Conway wrote:
>
> > To me C means: "the *value* stored in the memory
> > implementing this variable cannot be changed". Which doesn't preclude
> > rebinding the variable to some *other* memory.
> >
> > B
On Wed, 31 Oct 2001, Damian Conway wrote:
> To me C means: "the *value* stored in the memory
> implementing this variable cannot be changed". Which doesn't preclude
> rebinding the variable to some *other* memory.
>
> But others have a different (and equally reasonable) interpretation of
> C: "th
>
> I understand that we can wag a finger at the person who does this
> and tell them that they will have bad luck for seven years.
Or we could provide a trait that prevents it:
my $MAXPATHLEN is unbindable const = 2048;
> I suggest that Perl's inte
Nathan Wiger wrote:
> Jeremy Howard wrote:
> >
> > Good question. I haven't tackled this in RFC 83, because it is a more
> > general question about attribute syntax. We don't really have a good
> > attribute syntax RFC yet, although Nate threw up some ideas a couple of
days
> > ago. Is someone int
Jeremy Howard wrote:
>
> Good question. I haven't tackled this in RFC 83, because it is a more
> general question about attribute syntax. We don't really have a good
> attribute syntax RFC yet, although Nate threw up some ideas a couple of days
> ago. Is someone interested in whipping up an RFC t
Greg Boug wrote:
> Apologies if these comments have already been noted...
>
> > my $PI : constant = 3.1415926;
> > my @FIB : constant = (1,1,2,3,5,8,13,21);
> > my %ENG_ERRORS : constant = (E_UNDEF=>'undefined',
E_FAILED=>'failed');
> &g
Apologies if these comments have already been noted...
> my $PI : constant = 3.1415926;
> my @FIB : constant = (1,1,2,3,5,8,13,21);
> my %ENG_ERRORS : constant = (E_UNDEF=>'undefined', E_FAILED=>'failed');
>
> Constants can be lexically or
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 Aug 2000
Last Modified: 21 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 83
V
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Better constants and constant folding
=head1 VERSION
Maintainer: John Siracusa <[EMAIL PROTECTED]>
Date: Aug 15 2000
Last-Modified: Aug 16 2000
Version: 2
Mailing List:
>>>>> "JS" == John Siracusa <[EMAIL PROTECTED]> writes:
JS> On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote:
>> It is proposed that a new syntax for declaring constants be introduced:
>>
>> my $PI : constant = 3.1415926;
>> my @FIB : co
On 8/16/00 4:00 PM, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Better constants and constant folding
>
> =head1 VERSION
>
> Maintainer: John Siracusa <[EMAIL PROTECTED]>
> Date: Aug 15 2000
> Version: 1
> Mailing List: [EMAIL PROTECTED]
> Number:
On 8/16/00 3:55 PM, John Siracusa wrote:
> On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote:
>> This RFC proposes that the current constant.pm module removed, and
>> replaced with a syntax allowing any variable to be marked as constant.
>
> Unfortunately, I submitted an nearly identical RFC yesterd
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Better constants and constant folding
=head1 VERSION
Maintainer: John Siracusa <[EMAIL PROTECTED]>
Date: Aug 15 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 113
ting one (I searched for "const" on the RFC homepage, I
swear! :)
I'm not sure if mine will end up getting posted, but in case it doesn't,
here are my comments/additions to RFC 83:
> It is proposed that a new syntax for declaring constants be introduced:
>
> my $PI : co
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]>
Created: 10 August 2000
Last modified: 16 August 2000
Version: 2
Mailing List: [EMAIL PRO
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
> > &qu
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 char
quot;. 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.
Which is t
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 ma
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 hat
Ed Mills <[EMAIL PROTECTED]> writes:
>
>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 bo
rogrammers 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
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 se
s 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 l
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! $d
On Fri, 11 Aug 2000, Mike Pastore wrote:
> $'bar = 'unchanging'; # klingon?
Of course, this is impossible unless Perl6 (finally?) drops compatibility
with the old Perl4 package separator '. Now, $'bar eq $::bar, and package
D'oh is package D::oh.
Has there ever been an RFC discussing retention
> 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&#
xity 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;
$ba
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++.
From: "Nathan Wiger" <[EMAIL PROTECTED]>
Sent: Friday, August 11, 2000 1:58 AM
> How would this take into account stuff like this:
>
>sysopen(HANDLE, "/etc/motd", O_RDWR|O_CREAT, 0644);
This is completely the problem of the module that exports O_RDWR.
O_RDWR could still be defined as a sub tha
Please, please, please, PLEASE, let us not replicate the debacle that is
C++'s const modifier!
Damian
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
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
> 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
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. Spinning off from Larrys syntactic comment and Mike
Pastores example, how about some of the following:
A constant struct with constant
DWR}|$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 mi
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 wh
A semantic definition of "constant" would be nice.
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 th
> my %STRUCT : constant = (
> Name =>str 'Jane',
Isn't this ambiguous, considering that the => operator quotes the
left side?
-Hao
to be made
constant, simply because they're CONSTANT and unchanging.
One more thing: Does the 'constant' refer to the hash (ie, the ability to
add and delete items) or to the individual data elements?
Darn typing!! Darn constants!!
--
Mike Pastore
[EMAIL PROTECTED]
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'
[EMAIL PROTECTED] writes:
: 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');
Can't pu
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
80 matches
Mail list logo
