second string refactor landed

[Allison Randal]

Patrick R. Michaud wrote:
> Can we PLEASE PLEASE PLEASE use this as an opportunity to
> fix the naming and/or semantics of string_equal 
> (now Parrot_str_equal)?
> 
> Previously the C<string_equal> function (and now C<Parrot_str_equal> )
> returns zero (i.e., false) if the two arguments are *NOT* equal, 
> which makes for some very confusing code.  Let's not propagate or
> sanctify this any further than it already exists.
> 
> I recognize that it's not simple to go update the logic for all
> of the calls to string_equal, but if we're global-search-and-replacing
> the function name anyway, let's at least change it to 
> Parrot_str_not_equal so that the boolean result matches what
> is actually being tested.

Yes, I'm quite happy to make that change (it's driven me nuts for ages 
now). I'll do a simple substitution for "Parrot_str_not_equal" now, and 
add a separate "Parrot_string_equal" function.

> Should we take this as an indication that Parrot will be playing
> a little looser with the deprecation guidelines between now 
> and 1.0?  AFAICT it wasn't mentioned in DEPRECATED.pod, nor any of the
> #parrotsketch meetings (apologies if it was and I missed it).

So far, DEPRECATED.pod has been used primarily for PIR-level features. 
That will change with 1.0, especially with more languages outside the 
core repository.

This one was mentioned as "large string refactor", but didn't list 
individual function name changes.

Allison