Perl extension

$x = new Perl("Test");
$y = new PerlScalar($x);
The above could generate mistakes.
It is better to use perl_wantarray(something)
or perl_wantarray(); something;.

Any ideas or suggestions? It would also be cool if people could mess around
with it a bit and give us some feedback.

Is this possible (?):

$x = new Perl("Test");
$y = $x->f(); // scalar context
$x->f(); // void context
$y = array( $x->f() ); // array context

or maybe
$y = perl_array( $x->f() );

Best regards,

--
Piotr Klaban

At 08:48 AM 3/2/2004 +0100, Piotr Klaban wrote:

$x = new Perl("Test");
$y = new PerlScalar($x);
The above could generate mistakes.
It is better to use perl_wantarray(something)
or perl_wantarray(); something;.

Any ideas or suggestions? It would also be cool if people could mess
around
with it a bit and give us some feedback.

Is this possible (?):

$x = new Perl("Test");
$y = $x->f(); // scalar context
$x->f(); // void context
$y = array( $x->f() ); // array context

or maybe
$y = perl_array( $x->f() );

Nope, because that would require changes in the language which we wouldn't
want to do just for Perl.
The following could maybe be made to work:
$x->void->f();
$x->scalar->f()
$x->array->f()

Andi
Andi

Hey,
As some of you might have noticed, Dmitry worked on a Perl extension which
allows PHP to run Perl scripts as well as instantiate Perl objects in PHP
and use them.

Intresting idea, but I have some questions:

• Should ext/perl "only" bring CPAN modules into PHP or is the goal to run any
  Perl code in PHP?
• Why ext/perl and not ext/parrot? Sterling started some experiments with
  Parrot last year, why not go this way? Yes, I know that Parrot is far away
  from a final release, but do we really need Perl support in PHP now?

The main problem with the extension is the fact that Perl functions behave
differently according to their context (scalar/array) which doesn't exist
in PHP. We thought of all sorts of ways to solve this problem but aren't
sure what the best approach would be.

That is the problem of the Perl C API, but you will get more problems too. In
Perl you have 3 variable types: scalars (string, integer, float, ...), arrays
(lists without holes and numeric keys) and hashes (assoc array is nearly the
same in PHP). Both, Perl arrays and Perl hashes, you have to map to PHP
arrays, but where is the point to differ between a list and an assoc array?

Simple example:
In Perl ('a' => 'b', 'c' => 'd') could be an assoc array with 2 elements
(hash) or a list with 4 elements (array, elements on odd positions are the
old keys).

My idea:
perl_declare_as_scalar
perl_declare_as_array
perl_declare_as_hash
Now the PHP variable knows (internal) what Perl variable type it should have.

Other problems I see:

• Perl scalars could be references to anything (for instance on variables
  inside a sub/function)
• Perl have tie (bind a variable on a package and do magic things like
  automtic sort lists, share variables between processes, ...)
• Perl have an good working own Garbage Collection, do you really want to
  manage memory manually?
• In Perl $var, @var and %var are different things (same name, but different
  prefix and variable type)
• Is the Perl Artistic License compatible to the PHP License?

As it's in pecl it doesn't have to be finalized quickly but it would be
nice to have something working for PHP 5's release (via pecl).

-1000 for that. Please make PHP5 first, what PHP4 was and is: stable and fast.
Than start again with implementing new features. Only morrons will invest in
a beta language because the buzzword list is long.

PHP doesn't need Perl support really, it is only nice to have. The other (and
imho better) way is to motivate PEAR developer more, than you don't need to
assimilate CPAN code. And again: take some minutes to think about PHP for
Parrot.

Regards, Kai

Andi Gutmans wrote:

Hey,

As some of you might have noticed, Dmitry worked on a Perl extension which
allows PHP to run Perl scripts as well as instantiate Perl objects in PHP
and use them.

i have done something similiar in the pass but with a different approach. i
have written a PHP extension where it's capable of running any arbitary
Perl code and return the result back to PHP

The main problem with the extension is the fact that Perl functions behave
differently according to their context (scalar/array) which doesn't exist
in PHP. We thought of all sorts of ways to solve this problem but aren't
sure what the best approach would be.
The current implementation uses scalar as default, and if you want an
array, you can use perl_wantarray() and the next method call would return
an array (the one after that would return scalar):

Example:

$x = new Perl("Test");
$y = $x->f(); // scalar context;
perl_wantarray();
$y = $x->f(); // array context;
$y = $x->f(); // scalar context;

in my extension, i have handled this situation base on the context within
the Perl code, not in PHP. everything is passed back to PHP as reference
except for scalar. the reference is then dereferenced base on the "type"
they are point to so for example:

<?php

dl("perl.so");

$k = p2p_eval("%k = 1..10; %k");

print_r($k)

?>

prints:

Array
(
[1] => 2
[3] => 4
[7] => 8
[9] => 10
[5] => 6
)

which returns a hash to $k but:

$k = p2p_eval("@k = 1..10; @k");

print_r($k);

prints:

Array
(
[0] => 1
[1] => 2
[2] => 3
[3] => 4
[4] => 5
[5] => 6
[6] => 7
[7] => 8
[8] => 9
[9] => 10
)

which returns an array back to $k because the last expression of the Perl
code evaluates to an array reference. scalars are returned by value:

$k = p2p_eval("'x1234y' =~ /(\d+)/; $1");

print_r($k);

prints:

1234

this way, i don't have to concern about what context the PHP code is being
used as long as the Perl code returns the right thing in the right context,
my extension will handle the data type correctly.

just something to share...

david

s$s*$+/<tgmecJ"ntgR"tgjvqpC"vuwL$;$;=qq$
\x24\x5f\x3d\x72\x65\x76\x65\x72\x73\x65
\x24\x5f\x3b\x73\x2f\x2e\x2f\x63\x68\x72
\x28\x6f\x72\x64\x28\x24\x26\x29\x2d\x32
\x29\x2f\x67\x65\x3b\x70\x72\x69\x6e\x74
\x22\x24\x5f\x5c\x6e\x22\x3b\x3b$;eval$;