multi-programming-language questions
Phil Hassey
I've been lurking here for about two months, after having read the summaries
for several months previous. I'm interested in parrot because 1. I want it
very badly for php / python / perl combinationability(?) 2. Just reading
about the project is a fascinating learning experience.
I've looked over the parrot docs on parrotcode.org, and have a few questions
/ concerns. Most of my problems lie within the fact that I'm so interested
in seeing php / python / perl coexisting peacefully.
1. Function case -- some languages like php don't use case for function or
method names. Thus $a->toString(); is the same as $a->tostring(); However,
a language like java does care. How will php be able to call the correct
java method?
I suspect one solution for php would be to have a way to do a case
insensitive method lookup.
2. Strings -- everyone deals with strings differently. There was some
allusion to this issue in the docs on parrotcode.org, although the question
wasn't quite answered. I also might not have quite understood the vtables
chapter...
So if I create a perlscalar string, and send it to a python function, what
happens? Does the string act like a perlscalar or a pythonString? Or if I
cared one way or an other, could I force it to switch to being a pythonString
or stop it from switching?
I suspect a language like PHP wouldn't have too much trouble with dealing
with foreign strings, as it uses functions, and if all strings were a
subclass of some parrotString class, PHP could handle them. But when a php
string was sent to python or perl, that string would have no methods at all
(except for maybe the parrotString methods?)
The more fundamental question is -- is it possible to (if requested)
magically transform one object to another type -- but only while it's in a
different languages context? I suppose multi-threading would make the issue
even more confusing...
4. Global Scopes -- each language has its own idea of what is part of the
core function/pre-defined values set.
If I start a python script, and call a php script, will php have python's
global core (__import__,apply, compile,complex,xrange, etc...) or will the
php script have the usual myriad of php functions available (all 5000 of
them)?
I guess when I'm in a php or python context, I'd want things to feel like a
php or python context... Maybe each language gets its own namespace?
php::main, python::main...
Anyway, all these questions are comeing from someone who doesn't do a whole
lot with perl. Yet, I'm _very_ excited about parrot, as I see a lot of
duplicated effort between the various dynamic languages. And because of that
duplicated effort, some things just never get duplicated. There are _many_
times when I'm using PHP, that I wish I could _really_ use CPAN. And other
times when I'm using python that I wish I could jump back into PHP for a
second. Or I want to use a function that I know is only implemented the way
I like it in the other language... And there are even sometimes that I wish
I could move over to perl for a minute and do something else. Beyond code
reuse, and language switchability, I also like the idea of a single powerful
platform. (That, hopefully, is superior to the individual ones. I have
gripes about the PHP platform and the python platform, that I wishfully hope
to see resolved by parrot.)
So, anyway, sorry for liking PHP, and sorry for asking lots of (maybe
ignorant) questions about how it will all work.
BTW -- is anyone working on php->parrot right now? I saw a mention of it a
few weeks ago, but no links..
Thanks!
Phil
Uri Guttman
PH> 1. Function case -- some languages like php don't use case for
PH> function or method names. Thus $a->toString(); is the same as
PH> $a->tostring(); However, a language like java does care. How will
PH> php be able to call the correct java method? I suspect one
PH> solution for php would be to have a way to do a case insensitive
PH> method lookup.
no, that is a compiler problem. all the php compiler would have to do is
lower (or upper) case all method names. parrot will only see the single
case version.
PH> 4. Global Scopes -- each language has its own idea of what is
PH> part of the core function/pre-defined values set. If I start a
PH> python script, and call a php script, will php have python's
PH> global core (__import__,apply, compile,complex,xrange, etc...) or
PH> will the php script have the usual myriad of php functions
PH> available (all 5000 of them)? I guess when I'm in a php or python
PH> context, I'd want things to feel like a php or python context...
PH> Maybe each language gets its own namespace? php::main,
PH> python::main...
again a compiler problem.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Dan Sugalski
>List,
>
>I've been lurking here for about two months, after having read the summaries
>for several months previous. I'm interested in parrot because 1. I want it
>very badly for php / python / perl combinationability(?) 2. Just reading
>about the project is a fascinating learning experience.
>
>I've looked over the parrot docs on parrotcode.org, and have a few questions
>/ concerns. Most of my problems lie within the fact that I'm so interested
>in seeing php / python / perl coexisting peacefully.
>
>1. Function case -- some languages like php don't use case for function or
>method names. Thus $a->toString(); is the same as $a->tostring(); However,
>a language like java does care. How will php be able to call the correct
>java method?
>I suspect one solution for php would be to have a way to do a case
>insensitive method lookup.
PHP's going to have a problem there. If it calls $foo->bar, and $foo
has a Bar method instead (or, worse, a Bar and BAR method) then the
call will fail. Not much we can do, unfortunately.
>2. Strings -- everyone deals with strings differently. There was some
>allusion to this issue in the docs on parrotcode.org, although the question
>wasn't quite answered. I also might not have quite understood the vtables
>chapter...
>So if I create a perlscalar string, and send it to a python function, what
>happens? Does the string act like a perlscalar or a pythonString? Or if I
>cared one way or an other, could I force it to switch to being a pythonString
>or stop it from switching?
>I suspect a language like PHP wouldn't have too much trouble with dealing
>with foreign strings, as it uses functions, and if all strings were a
>subclass of some parrotString class, PHP could handle them. But when a php
>string was sent to python or perl, that string would have no methods at all
>(except for maybe the parrotString methods?)
>The more fundamental question is -- is it possible to (if requested)
>magically transform one object to another type -- but only while it's in a
>different languages context? I suppose multi-threading would make the issue
>even more confusing...
Being able to share variables across language code is one of the big
things we're working on. It should be fine, and since all the
language routines will ultimately be working on parrot's low-level
string type it's just a matter of getting the right bits out of
existing variables via a predefined interface. Shouldn't be a problem.
Kinda hand-wavey, but I'm way behind and trying to answer quickly. Sorry... :)
Oh, and where's #3? It's gone missing.
>4. Global Scopes -- each language has its own idea of what is part of the
>core function/pre-defined values set.
>If I start a python script, and call a php script, will php have python's
>global core (__import__,apply, compile,complex,xrange, etc...) or will the
>php script have the usual myriad of php functions available (all 5000 of
>them)?
>I guess when I'm in a php or python context, I'd want things to feel like a
>php or python context... Maybe each language gets its own namespace?
>php::main, python::main...
We'll probably do some sort of namespace isolation, but if you use
php code, it'll make sure the base php libraries are pulled in. Some
of the more internals-oriented stuff, like walking attribute spaces
on objects and such, may not work the same when running on parrot,
though we'll be able to translate or thunk a lot of that sort of code.
>BTW -- is anyone working on php->parrot right now? I saw a mention of it a
>few weeks ago, but no links..
I don't think anyone's working on it at the moment, but I might be wrong.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk