in reply to Curious: are anon-hashes in random order?

constant takes a hash reference as its argument, and random order doesn't matter in this case, because each directive is named, not positional. There is no ambiguity.

constant puts its parameter (the hash ref) into a variable called $multiple on line 59, then on line 69, commences a check to see if the param is in fact a hash ref, and will croak if it isn't.

Further, this has nothing to do with the run phase either. You can't assign a hashref to a variable and then expect it to work in a use statement because the use is executed at compile time, but the hash is created at runtime. The reason your latter example works is because you're forcing $clist to be created prior to the use constant ... line by creating it at compile time one line above in another use statement. You could achieve the same thing with this:

my $clist; BEGIN { $clist = {a => 1, b => 2}; } use constant $clist;

Replies are listed 'Best First'.
Re^2: Curious: are anon-hashes in random order?
by perl-diddler (Chaplain) on Sep 13, 2016 at 20:42 UTC
    my $clist; BEGIN { $clist = {a => 1, b => 2}; } use constant $clist;
    That's what I meant by being more 'expansive'... compared to
    my $clist; use <anymodule> ($clist = {a => 1, b => 2}); use constant $clist;
    Note -- # anymodule, above, works for modules that are guaranteed to never cause some conflict with random assign statements in its argument list, like "mem".

    It is a secondary use of mem, but still one that's useful to know if you don't want to have your header/use/init area littered w/compiler-keywords like BEGIN and indentation that sticks out like a wart. Some people don't care about those things, some do. Chocolate or butterscotch, take your pick. ;-)

    Of course all that could be handled in a greatly more straightforward manner if perl had a Macro facility like most compiler languages. While you can do similar w/perl using filters, my impression is that those are frowned upon, leaving no alternatives (or at least none that I'm aware of) :-(.