# Perl extension - Thread: https://externals.io/message/8292 - Original archive: https://news-web.php.net/php.internals/8292 - Started by Andi Gutmans on 2004-03-01T22:10:51+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #8292 — Andi Gutmans — 2004-03-01T22:10:51+00:00 URL: https://externals.io/message/8292#8292 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 --- ## #8295 — Piotr Klaban — 2004-03-02T07:48:34+00:00 URL: https://externals.io/message/8292#8295 · In reply to: #8292 > $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 --- ## #8296 — Andi Gutmans — 2004-03-02T08:14:50+00:00 URL: https://externals.io/message/8292#8296 · In reply to: #8292 At 08:48 AM 3/2/2004 +0100, Piotr Klaban wrote: > > > […] >The above could generate mistakes. >It is better to use perl_wantarray(something) >or perl_wantarray(); something;. > > > […] > around > > […] > >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 --- ## #8312 — cyberian@arcor.de — 2004-03-02T17:11:04+00:00 URL: https://externals.io/message/8292#8312 · In reply to: #8292 > 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 --- ## #8316 — cyberian@arcor.de — 2004-03-02T19:00:36+00:00 URL: https://externals.io/message/8292#8316 > 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 --- ## #8361 — david — 2004-03-03T23:10:53+00:00 URL: https://externals.io/message/8292#8361 · In reply to: #8292 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: 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*$+/