Luke Palmer wrote:
Should {} be an empty hash rather than an empty code?
Does it matter? More interesting is the question what it returns
or evaluates to if it's a block. Actually with my idea of List
beeing a subtype of Code the parse time recognition of blocks
as List of Pair has no implication for the semantics! It falls
into the category of optimizations that can be performed if the
involved types can be determined at compile time.
Thus assigning that to a plain % sigiled variable expression would
kick out the previous content and store a freshly created undef
under a key calculated from the incoming undef. Which in my eyes
is pretty useless. In particular if the outcome is that +%hash == 1
instead of defining that
%hash = {};
clears the content of the hash and that +%hash == 0. But the fans
of extra levels of indirection in the @array case might like to get
a default key like '' or 0 beeing used, such that the particular
undef from the {} of the rhs of the assignment can be retrieved with
%hash<0><0>. For an arbitrary undef any non-existing index suffices :)
Why did we change { %hash } from making a shallow copy of a hash to
the code that returns %hash?
Sorry, I don't understand this question. Do you want 'shallow copy'
to mean 'take a ref'? Or Parrot/Pugs level COW?
Are you alluding to the referential semantics discussion?
--
TSa (Thomas Sandlaß)
