Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Perl extension »

Perl extension

php.internals

Andi Gutmans

22 years ago
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. 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; This is obviously not very sexy. Other ideas could be passing an additional flag to the function call, possibly creating wrapper objects for the Perl objects which would decide on the type of method call. For example: $x = new Perl("Test"); $y = new PerlScalar($x); $z = $y->f(); // Scalar context $w = new PerlArray($x); $b = $w->f(); // Array context Any ideas or suggestions? It would also be cool if people could mess around with it a bit and give us some feedback. 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). Thanks, Andi

Piotr Klaban

22 years ago
On Tue, Mar 02, 2004 at 12:10:51AM +0200, Andi Gutmans 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() ); Best regards,
-- Piotr Klaban

Andi Gutmans

22 years ago
At 08:48 AM 3/2/2004 +0100, Piotr Klaban wrote:
>On Tue, Mar 02, 2004 at 12:10:51AM +0200, Andi Gutmans 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

Dmitry Stogov

22 years ago
> The following could maybe be made to work: > $x->void->f(); > $x->scalar->f() > $x->array->f() > > Andi
Yes, but not with plain functions and perl_eval(). perl_call("func", $arg1, $arg2); Dmitry.

Vlad Bosinceanu

22 years ago
>Yes, but not with plain functions and perl_eval(). > >perl_call("func", $arg1, $arg2); > >Dmitry. > >
What about perl_eval("func", PERL_CONTEXT_WHATEVER, $arg1, ...)?

Kai Schröder

22 years ago
On Monday 01 March 2004 23:10, 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.
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

Petras Kudaras

22 years ago
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kai Schröder wrote: | On Monday 01 March 2004 23:10, 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. | | 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? Well, Perl itself does not differentiate from "CPAN modules" or "any other modules". Once you can load Perl modules and use the functions (or methods, for that matter), you can use any Perl code, and you are not restricted to CPAN. | - 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? Parrot is a year or so from the final release. However, even so, Sterling started implementing PHP in Parrot and not the other way round. I thought PHP6 would have Parrot as its platform? :) | 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, ...) I was half hoping that PHP5's __get() and __set() methods could provide a similar capability when I first read about them, but I have been dissapointed :/ | - 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) There are more: filehandles, dirhandles, & for subs and * for globs. - -- Petras Kudaras aka moxliukas http://moxliukas.esu.as -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFARMg7ILp4U3/5SuARAqJAAKCmtWJiZ35Hat3CffIj4i6Gbno6bQCfR9f1 /jp96JD/Ocojxi2/CzcMDBk= =eddL -----END PGP SIGNATURE-----

Kai Schröder

22 years ago
On Tuesday 02 March 2004 18:45, Petras Kudaras wrote:
> Well, Perl itself does not differentiate from "CPAN modules" or "any other > modules". Once you can load Perl modules and use the functions (or methods, > for that matter), you can use any Perl code, and you are not restricted to > CPAN.
Yes, I know, but the mail from Andy sounds like "only" write a wraper that can create instances of Perl objects, call the methods and bring back the result to PHP.
> Parrot is a year or so from the final release. However, even so, Sterling > started implementing PHP in Parrot and not the other way round. I thought > PHP6 would have Parrot as its platform? :)
This would be great, we'll see in this decade. ;)
> I was half hoping that PHP5's __get() and __set() methods could provide a > similar capability when I first read about them, but I have been > dissapointed :/
No, to marriage Perl and PHP is more than some macro magic. :(
> There are more: filehandles, dirhandles, & for subs and * for globs.
Right, but let first find solutions for the "primitive" problems, before we think about real problems. Regards, Kai

Piotr Klaban

22 years ago
On Tue, Mar 02, 2004 at 06:11:04PM +0100, Kai Schröder wrote:
> 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).
IMHO this is done by Perl converting HASH to ARRAY internally. In the same way Perl converts array to scalar with scalar(@a), that is equal to number of records in @a (equal to $#a-$[+1) and synonym of PHP's count($a). With scalar(%a) you get number of used/allocated hash buckets, in Perl6 it would get a reference to %a (as stated in Exegesis 2). IMHO all the perl complications should be passed over in first version of PHP perl module. In Polish there is a proverb "The Krakow (old Polish capital city) has not been build at one". I.e. start from the simple extension and .. extend it.
> Other problems I see: > - Perl scalars could be references to anything (for instance on variables > inside a sub/function)
That is why PHP variable could be one from the two: - a perl object - a PHP variable independent from the Perl variable, mapped to scalar, or array/hash array during the copying phase.
> - Perl have an good working own Garbage Collection, do you really want to > manage memory manually?
IMHO when object is destroyed on the PHP side, the Perl GC is used on the Perl side.
> - In Perl $var, @var and %var are different things (same name, but different > prefix and variable type)
> PHP doesn't need Perl support really, it is only nice to have. The other (and
In 2001 I thought that Perl6 would be ready for use in Aug 2002 ... IMHO PHP is similar to Perl5, and I have heard of PHP/Perl module a few years ago. It is just a matter of time ... the module need to exists.
> 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.
+1000 for PHP for Parrot (AFAIK PHP it would run faster (?)).
-- Piotr Klaban

david

22 years ago
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$;