On Tue, Feb 10, 2004 at 12:53:43AM +0100, Leopold Toetsch wrote:
> Hi Stef,
Hi Leopold,
I cross-post to perl6-internals because I am not sure about the
exact semantic of hash and array access in Perl6.
>
> St�phane Payrard <[EMAIL PROTECTED]> wrote:
>
> > Le Mon, Feb 09, 2004 at 09:52:28PM +0100, le valeureux mongueur
> > Leopold Toetsch a dit:
>
> Trop long d'introduction. Pas de valeur.
>
> [ precise summary snipped ]
>
> > P3 = PO[P1] # regular keyed access without flag
>
> > # set a flag in P1 before doing the equivalent of C<P3 = PO[P1]>
> > P3 = P0{P1}
>
> It was already discussed (a long time ago, when current Key PMC went
> into CVS) that we might need a different syntax do differenciate
> in an instruction like:
>
> P3 = Phash_like[Pkey] # Phash_like is an aggregate that does both ...
>
> between integer or string keyed access.
>
> > The C<get_*_key()> would test the flag to do the proper operation.
>
> > To compare it with your proposition below: even if the flag lies in
> > the subscript pmc, I think it is more a property of the operation than
> > of the subscript pmc. It does not specify the type of a value. That's
> > why I want to bundle the flag setting with the access operation.
> > Anyway, a flag avoids to create a new set of keyed methods.
>
> I think that concept isnn't generally suitable for compilers. Perl6 has
> %P0[$key} and @P0[$key]. This syntax imposes some type restriction (or
> coercion) on the key and defines the operation.
I am not sure that Perl6 syntax imposes any type restriction on keys.
If so, it would probably invalidate my example of two-way hash accessed either
by C<$value = @a{$key> or C<$key = @a[$value]> with $key and $value
being non Key pmcs.
The two notations of "hash access" and "array access" or the
explicit setting of a flag denote two ways of accessing a pmc.
The possible types of the keys and the semantic of the access
operation is up to the pmc. And in a sense this is not new
because whatever semantic can be implemented with ties in Perl5.
In most cases but not all, the array (resp. hash ) access will
involve a subscript type that will be coerced to an integer
(resp. string).
About the flags used: they cannot be KEY_integer_FLAG and
KEY_string_FLAG because they are private flags that may have
other meanings in not Key pmcs. But PObj_access_as_hash (or
PObj_acts_as_String) would do. When zero the access is an
"array" access.
About the overhead of the added C code: if we choose to support
indexed access thru subscript pmcs that are not of type Key, we
cannot avoid it. But explicitly creating Key pmcs, or converting
pmcs to string or int for the sake of a keyed access is an
overhead too. So I don't see why supporting not key pmc would be
so much a problem.
> But with Perl5 syntax you are lost: The compiler wouldn't know, what to
> emit.
>
> There are of course more complicated examples:
>
> P3 = P0[Pa; Pb; Pc] # intermdiate aggregates have to know ...
In the case of composite keys, all the component but the last must
be keys. Indeed the flag should be set in each atomic component.
>
> [ more compiler writers opinions needed ]
>
> leo
--
stef
