Back to this again . .
> > ..., and someone pointed out that it had a problem
> > with code like "{ some_function_returning_a_hash() }". Should it give a
> > closure? Or a hash ref? ...
> Oh, well now that it's stated this way... (something went wrong in my
> brain when I read the actual message) It returns a closure :(. A4 says
> that as a term, { } define a closure, unless it contains a pair
> constructor at the top level. But, thanks to Perl 6's smartness, that would
> be excessive syntax anyway:
> $hashref = some_function_returning_a_hash()
> would do what you wanted.
Would it always? What if I had two functions (or more), all returning
part of the hash I want to package up? Can I do:
$hashref = some_function_returning_a_hash(),
some_other_function_returning_more_of_the_hash();
and get the result of both functions into the anonymous hash?
Besides, does
$hashref = some_function_returning_a_hash()
make $hashref simply refer to the result of the function, or does it
make $hashref refer to a hash containing a *copy* of the result of the
function? If Perl6 is going to do fancy things with functions returning
lvalues, which looks like the case, those two things aren't necessarily
the same thing.
Or, saying the same thing another way, does this:
$href = %hash;
which I presume will be legal Perl6, mean the same as this Perl5:
$href = \%hash; #A
or this Perl5:
$href = { %hash }; #B
and how would I say each of A and B in Perl6 unambiguously?
Automatic referencing and dereferencing is all well and good, and it
appears that it's here to stay in Perl6 (it's been in most Apocalypses),
but I don't think anyone's actually sat down yet to thrash out exactly
under what circumstances it happens.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"It's no good believing in somebody else if you can't believe in yourself. You
give them the reason to take all the power and wealth." - _Turn it Up_, Alan
Parsons
