[BUG] hash iterator interface changed, needs errata or deprecation notice

[pmichaud]

The following code worked in Parrot 1.0.0 (r37535) and Parrot 1.3.0 (r39599):

$ cat hash-1.pir
.sub 'main'
    .local pmc hash, hash_it
    hash = new ['Hash']
    hash['1'] = 'a' 
    hash['2'] = 'b'
    hash['3'] = 'c'

    hash_it = iter hash
  loop:
    unless hash_it goto done
    $P0 = shift hash_it
    $P1 = concat $P0, 'x'
    say $P1
    goto loop
  done:
.end

$ 37535/parrot hash-1.pir
1x
2x
3x
$ 39599/parrot hash-1.pir
1x
2x
3x

The same code fails in 1.4.0 (r40185) and current trunk:

$ 40185/parrot hash-1.pir
Multiple Dispatch: No suitable candidate found for 'concatenate_str', with signature 'PSP->P'
current instr.: 'main' pc 24 (hash-1.pir:12)
$ trunk/parrot hash-1.pir
Multiple Dispatch: No suitable candidate found for 'concatenate_str', with signature 'PSP->P'
current instr.: 'main' pc 24 (hash-1.pir:13)
$ 

The problem is not limited to the concat opcode -- other opcodes cause problems also:

$ cat hash-2.pir
.sub 'main'
    .local pmc hash, hash_it
    hash = new ['Hash']
    hash['1'] = 'a' 
    hash['2'] = 'b'
    hash['3'] = 'c'

    hash_it = iter hash
  loop:
    unless hash_it goto done
    $P0 = shift hash_it
    $P1 = add $P0, 100
    say $P1
    goto loop
  done:
.end

$ 37535/parrot hash-2.pir
101
102
103
$ 39599/parrot hash-2.pir
101
102
103
$ 40185/parrot hash-2.pir
Multiple Dispatch: No suitable candidate found for 'add_int', with signature 'PIP->P'
current instr.: 'main' pc 24 (hash-2.pir:12)
$ trunk/parrot hash-2.pir
Multiple Dispatch: No suitable candidate found for 'add_int', with signature 'PIP->P'
current instr.: 'main' pc 24 (hash-2.pir:13)
$ 

The underlying problem appears to be that starting with the 1.4.0 release, hash iterators began returning HashIteratorKey PMCs instead of String PMCs:

$ cat hash-3.pir
.sub 'main'
    .local pmc hash, hash_it
    hash = new ['Hash']
    hash['1'] = 'a' 
    hash['2'] = 'b'
    hash['3'] = 'c'

    hash_it = iter hash
  loop:
    unless hash_it goto done
    $P0 = shift hash_it
    $P1 = typeof $P0
    say $P1
    goto loop
  done:
.end

$ 37535/parrot hash-3.pir
String
String
String
$ 39599/parrot hash-3.pir
String
String
String
$ 40185/parrot hash-3.pir
HashIteratorKey
HashIteratorKey
HashIteratorKey
$ trunk/parrot hash-3.pir
HashIteratorKey
HashIteratorKey
HashIteratorKey
$ 

It seems to me that a change of this sort should have been preceded by a deprecation notice -- as far as I can tell no such notice was given. Regardless, returning a HashIteratorKey PMC would seem to be the least usable or useful of any of the options available.

Pm

[pmichaud]

After discussion on irc ( http://irclog.perlgeek.de/parrot/2009-11-09#i_1708073), I've concluded that we're better off keeping the new behavior than trying to provide backward compatibility with the old.

This does represent a somewhat significant change in behavior that goes outside the deprecation policy, however, so I suspect some sort of errata or other notice ought to be made somewhere. Chromatic has already opened a ticket for changing the related section in the PIR book -- see TT #1254.

I'll leave this ticket open until someone decides that the issue has been sufficiently well documented/addressed.

Thanks!

Pm

[jkeenan]

Replying to pmichaud:

I'll leave this ticket open until someone decides that the issue has been sufficiently well documented/addressed.

Can anyone advise how we would determine whether the issue had been sufficiently well documented or addressed?

Thank you very much.

kid51

[jkeenan]

Replying to jkeenan:

Replying to pmichaud:

I'll leave this ticket open until someone decides that the issue has been sufficiently well documented/addressed.

Can anyone advise how we would determine whether the issue had been sufficiently well documented or addressed?

Question repeated. Since pmichaud mentioned that this would need to be fixed in PIR book as well, I'm cc-ing authors of book.

kid51