get_pmc_keyed() in PerlString?
Sterling Hughes
I'm right now looking at getting a proper implementation of array/string
offsets done for the PHP compiler.
Here's the problem, in PHP you can access indices of both string's an
array's in the same way, meaning:
<?php
$foo = "hallo johnny";
echo $foo[1]; // "a"
?>
Is just as valid as:
<?php
$foo = array("a", "b", "c");
echo $foo[1]; // "b"
?>
To have this available easily using Perl's types, get_pmc_keyed() would
need to be implemented in the PerlString PMC. Currently (for the sake
of nice looking mandelbrot demos), we just assume is a native string and
do the offset from that string (which parrot/imc does support.)
Should PerlString support a get_pmc_keyed() method (according to Perl
5/6 semantics), or is this a point where its about time to start implementing
our own PMCs?
-Sterling
Leopold Toetsch
> Should PerlString support a get_pmc_keyed() method (according to Perl
> 5/6 semantics), or is this a point where its about time to start
> implementing our own PMCs?
get_pmc_keyed() seems a bit heavy to handle single chars in a
PerlString (Each char would create a separate PMC with a PerlString
attached to it).
Can you use native STRINGs for that?
> -Sterling
leo
Thies C . Arntzen
sure, if we only knew the type of the variable we're accessing:
function dump0($a)
{
echo printf("%s\n",$a[0]);
}
dump0("hallo"); // called with a string
dump0(array("thies", "arntzen")); // with an array
would produce (in php):
h // string offset
thies // array index
how do you think we should generate "good" imc code for that?
re,
thies
Leopold Toetsch
> would produce (in php):
dump0() is obviously non-prototyped (or takes PMCs) which doesn't differ
here. So I would do:
.sub _subscripted
.param pmc p
.param int idx
does I0, p, "array"
if I0, handle_array
.include "pmctypes.pasm"
typeof I0, p
eq I0, .PerlString, handle_string
# unhandled type
exit 1
.local pmc elem
handle_array:
elem = p[idx];
...
handle_string:
$S0 = p
$S1 = $S0[idx] # or substr $S1, p, idx, 1
elem = new .PerlString
elem = $S1
...
absolutely untested.
But it seems, that subscripting of string PMCs yields another PMC in the
general case, so its really probably simpler to use your proposed
change. You can easily experiment with custom PMCs, if you use
dynclasses/*.
> re,
> thies
leo
Vladimir Lipsky
Parrot
debug mode was on. In fact, it proved to be an effect of the same cause --
we
have global resources sharable among interpreters, that we try to free more
than
once. This time it's encoding_array. If you're going to disable the
encoding_array
freeing for now, just make sure you disable the chartype_array one either.
0x4C56
Leopold Toetsch
Did you recheck that after my fix to vtable freeing? My patch covered
encoding and chartype too.
> 0x4C56
leo
Vladimir Lipsky
> Did you recheck that after my fix to vtable freeing? My patch covered
> encoding and chartype too.
No, I didn't. Did you fix the Parrot_loadbc function name? If didn't, I'll
have a go for Parrot_set_PackFile()
> leo
0x4C56
Happy
.~.
/V\
// \\
/( )\
^`~'^
2004
keeps comin'
Dan Sugalski
>Hey,
>
>I'm right now looking at getting a proper implementation of array/string
>offsets done for the PHP compiler.
>
>Here's the problem, in PHP you can access indices of both string's an
>array's in the same way, meaning:
[Snip PHP treating strings as character arrays]
>To have this available easily using Perl's types, get_pmc_keyed() would
>need to be implemented in the PerlString PMC. Currently (for the sake
>of nice looking mandelbrot demos), we just assume is a native string and
>do the offset from that string (which parrot/imc does support.)
>
>Should PerlString support a get_pmc_keyed() method (according to Perl
>5/6 semantics), or is this a point where its about time to start implementing
>our own PMCs?
This... could be a problem. Perl, using a perl string as an array,
should treat it as a symbolic reference if that's enabled. And,
strictly speaking, if PHP is handed a PerlInteger it ought to treat
it the same way as a PerlString. Or not, but it'd be reasonable as
they're really facets of the same base type.
I can see a number of solutions here, some of which involve compiler
hackery. The thing that first springs to mind is to have the PHP
compiler emit a check of some sort before use, and either do array
access or substring access. That's got a certain appeal to it, as it
means we don't have to do anything. :) (Well, not true--we have to
provide sufficient easily queryable metadata to tell if a variable is
more or less an array, or a string, but we ought to so that anyway)
If that's not a reasonable option, and I can see it not being so,
that makes things somewhat more interesting. Definitely calls for at
least one custom PMC for PHP, and potentially an automatic wrapping
function to throw a PHPStringWrapper (or whatever) around anything
stringlike that comes back from an 'external' function call. That
requires a bit more work on parrot's part, though, and, while I'd
like to do this at some point (for JVM and .NET native library
wrapping) I hadn't intended to do it yet, for lack of time and need.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk