Declarations of constants

2 views
Skip to first unread message

Ingo Blechschmidt

unread,
May 27, 2005, 11:16:06 AM5/27/05
to perl6-l...@perl.org
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;


# Way 4 (evil?)
macro MEANING_OF_LIVE { "42" }


# Way 5 (overloading of the numification of Class -- evil)
Class does role {
method *prefix:<+> (MEANING_OF_LIVE $class:) {
42;
}
}
class MEANING_OF_LIVE {}

say +MEANING_OF_LIVE;


# Please add more ways :)


--Ingo

--
Linux, the choice of a GNU | Black holes result when God divides the
generation on a dual AMD | universe by zero.
Athlon! |

Ingo Blechschmidt

unread,
May 27, 2005, 11:51:40 AM5/27/05
to perl6-l...@perl.org
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"(); # Perl?
say [1,2,3].does(Code) # true?

Or did you simply forget the braces around 42? :)


--Ingo

--
Linux, the choice of a GNU | Wer die Freiheit aufgibt, um Sicherheit zu
generation on a dual AMD | gewinnen, der wird am Ende beides
Athlon! | verlieren" -- Benjamin Franklin

"TSa (Thomas Sandlaß)"

unread,
May 27, 2005, 12:13:47 PM5/27/05
to perl6-l...@perl.org
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 42(); # 42?

&postfix:<.( )>:( Int :)

> say "Perl"(); # Perl?

&postfix:<.( )>:( Str :)

> say [1,2,3].does(Code) # true?

Depends on the type of [] which is Ref of Array or so.
But I think it should be false.

> 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;

But then I presume you could say:

foo = 17;
if foo < 8
{
@a[foo] = 8;
}

We could call that a codeless lvalue sub ;)
--
TSa (Thomas Sandlaß)

Ingo Blechschmidt

unread,
May 27, 2005, 12:41:24 PM5/27/05
to perl6-l...@perl.org
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 firstly "is rw" is the default
on vars declared with my(), and secondly &foo will be undef, not some
kind of Proxy object. To do what you want, you'd have to write (I
think):
my &foo = new_codeless_lvalue_sub();

sub new_codeless_lvalue_sub {
my $var;
return {
new Proxy: FETCH => { $var }, STORE => -> $new { $var = $new };
};
}

> But then I presume you could say:
>
> foo = 17;
> if foo < 8
> {
> @a[foo] = 8;
> }
>
> We could call that a codeless lvalue sub ;)

This indeed looks very slick! I wouldn't use it for normal vars, though.


--Ingo

--
Linux, the choice of a GNU | The next statement is not true.
generation on a dual AMD | The previous statement is true.
Athlon! |

Adam Kennedy

unread,
May 31, 2005, 4:37:11 AM5/31/05
to perl6-l...@perl.org
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; # One significant figure

sub time_to_ground ($height, $accel) {
...acceleration math...
}

my $time = time_to_ground( 500, $gravity );

... thus simplifying internally to

my $time = 1234;

Adam K

Simon Cozens

unread,
May 31, 2005, 6:54:16 AM5/31/05
to perl6-l...@perl.org
cp...@ali.as (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 significant figure
> sub time_to_ground ($height, $accel) {
> ...acceleration math...
> }

The ability to play around with the working of &time_to_ground before it
runs is one of the things I like about Perl.

--
A language that doesn't have everything is actually easier to program
in than some that do.
-- Dennis M. Ritchie

Damian Conway

unread,
May 31, 2005, 8:31:44 PM5/31/05
to perl6-l...@perl.org
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) {
> ...acceleration math...
> }
>
> my $time = time_to_ground( 500, $gravity );
>
> ... thus simplifying internally to
>
> my $time = 1234;

No. But you could get the effect by explicitly asking for time_to_ground() to
be called at compile-time:

my $gravity is constant = 10; # One significant figure

macro time_to_ground ($height, $accel) {
...acceleration math...
}

my $time = time_to_ground( 500, $gravity );

Damian

Reply all
Reply to author
Forward
0 new messages