Re: Empty hash
On Thu, 2 Jun 2005, Stuart Cook wrote:
On 6/1/05, Luke Palmer [EMAIL PROTECTED] wrote:
Should {} be an empty hash rather than an empty code?
Given that an empty hashref is probably much more useful than an empty
block, I propose that {} be an empty hash and {;} be an empty block.
Speaking of which, maybe this may be getting in the too-extreme
territory, but taking into account that a hash _is_ a function, it
wouldn't be that bad to blur the distinction between a hash and code, from
a UI perspective. How should one do it? Oh, but then I don't have the
slightest idea...
Michele
--
DAX ODIA ANCORA
- Scritta su diversi muri milanesi
Re: Empty hash
On 6/1/05, Luke Palmer [EMAIL PROTECTED] wrote:
Should {} be an empty hash rather than an empty code?
Given that an empty hashref is probably much more useful than an empty
block, I propose that {} be an empty hash and {;} be an empty block.
This mirrors the fact that (AFAIK) { $_ = 1 } is a hash and { $_ =
1; } is a block.
Alternatively, it could be a special hash that can also be called (and
which does nothing), but I doubt that's useful or desirable.
Stuart
Re: Empty hash
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
%hash00. 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ß)
Re: Empty hash
On 6/2/05, TSa (Thomas Sandlaß) [EMAIL PROTECTED] wrote:
Luke Palmer wrote:
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?
I think he means Why does it produce a Code (which happens to return
%hash), instead of a (ref to a) new hash that starts out with the same
k/v pairs as %hash, but thereafter can be modified independently?
Stuart
Empty hash
Two questions:
Should {} be an empty hash rather than an empty code?
Why did we change { %hash } from making a shallow copy of a hash to
the code that returns %hash?
Luke
