On Tue, Nov 29, 2005 at 02:18:17PM -0600, Patrick R. Michaud wrote:
> On Tue, Nov 29, 2005 at 12:08:01PM -0800, Chip Salzenberg wrote:
> > P0 := P1 # aliasing: P0 and P1 point to same PMC
> > P0 := opcode # aliasing: P0 points to PMC returned by opcode
> > P0 = ... # assignment: modifies P0, NO MATTER WHAT '...' IS
> >
> > S0 := S1 # aliasing: S0 and S1 point to same header
> > S0 := opcode # aliasing: S0 points to header returned by opcode
> > S0 = ... # assignment: modifies S0, NO MATTER WHAT '...' IS
>
> First comment: How do we coordinate the transition? Do we go to
> having a separate branch (ick), or do we just declare a date in
> which the grand renaming will take place?
I'm planning a flag day sometime in December. I'm also planning to
create a simple "handles most cases" translator.
> Second comment: how about access to keyed items -- does this mean:
>
> P0 := P1[S1] # alias
> S0 = P1[S1] # assignment
> I0 = P1[S1] # assignment
> N0 = P1[S1] # assignment
Yes.
> P0 = P1[S1] # supported?
Yes, it means to fetch a PMC and make P0 an alias to it. Perl 6
equivalent should be, more or less:
$a := $array[$i];
> S0 := P1[S1] # presumably an error?
Yes, as long as fetch operations can only return PMCs. Given the
existence of a generic fetch operation that actually returned a Parrot
string value natively, that line could become legal.
(Strings _are_ problematic in that they're create automatically in
some cases, AFAICT. More on that later.)
> Perhaps I've just trained myself to the current implementation, but
> I like that the shorter '=' does what I tend to want/expect and I
> write an explicit 'assign' or 'set' opcode when I need something
> different.
The current system does have its advantages, granted. But I think
having such a fundamental operator as '=' mean two subtly different
things based on visually indistinct clues is just not releasable.
And if you can get used to what we have, you'll certainly get used to
something better. :-)
--
Chip Salzenberg <[EMAIL PROTECTED]>
