new C<,>,( as I've been told here by wise ones), doesn't guarantee order
in which its operands will be evaluated, and even doesn't guarantee that
they won't be optimised away before evaluating, if all expression is in  
void
context..  right?

so it will be erroneous to write:

   pray_to $_, sacrifice <$virgin> for @evil_gods

because it could be executed as:

   sacrifice <$virgin>, pray_to $_ for @evil_gods

that is against rites;
or even "optimized away" as:

   sacrifice <$virgin> for @evil_gods

which is a senseless loss of costly and rare resources.
And I can't just write

    pray_to $_ and sacrifice <$virgin> for @evil_gods

because prayer result is almost always undefined, ..but who knows?

I'm thinking about C<then>, analogious to old C<,> (maybe with lower
precedence than C<and> and C<or> have?)

    pray_to $_ then sacrifice <$virgin> for @evil_gods

hm.. maybe C<then> should make first action in void context (I hate noise
when doing business)

P.S. of course, I can just use
   for @evil_gods { ... }
but I thought there's more than one way to sacrifice It... I'm just afraid  
of Repetitive Injure..
BTW, slight improvisations don't not harm in such things...

P.P.S. do we have a way to imply void context on function inside  
expression, something like C<scalar>, C<+>, C<~>, C<?> do?

--
$_ = join      q--,       map++        $_=>split        q qq, q
xitrswzmnsgdqwakzbjwodqkwoqhdrswx xor y yayys x y yxy y x print