Function arguments

[Joshua Tolley]

I was poking at getting function arguments to work, and realized something.
We use Parrot_ext_call() to call a compiled subroutine. That function requires
among its arguments a string to describe the subroutine's argument and return
types, a variable-length list of function arguments, and finally an object to
store the return value. The problem is that Parrot_ext_call() assumes you will
know the subroutine's argument and return types at compile time, and we don't.
We can't call Parrot_ext_call() and pass it three strings one time, then call
it and pass it two integers and a PMC the next time, because we don't know
those details at compile time. So I propose we don't do it that way.

Instead, one thing we could do is set Parrot registers for each input
argument. So PL/Parrot functions couldn't expect normal arguments, but they
could just inspect registers when they start, to get the data they're looking
for. In PIR this is easy; I don't know how it might work in various HLLs.

In PL/Perl, input arguments are all packed into @_, and we might do something
similar by packing input arguments into an array of PMCs or something. In
PL/Python and PL/LOLCODE, input arguments are all named, and the call handler
function just creates variables in the interpreter having those names. That
technique makes perfect sense for languages with named function arguments, but
not all HLLs will have named function arguments, and I don't see a way in the
available Parrot functions to create a variable in a particular namespace.

All that, and I have no idea how to handle return types. :)

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

[eggyknap]

I just had another thought. The reason PL/Perl takes its function
arguments as members of @_, PL/Python as named variables, and PL/pgSQL
as numbered special variables, is that each language has different
syntax and semantics for argument passing that make sense for that
language. For PIR it makes sense that we load registers with
arguments, but some HLLs might find that idea meaningless. So another
possibility: if, as I've proposed in the ROADMAP document, PL/Parrot
provides database access through a PMC that magically exists, perhaps
we make function arguments accessible through methods of that PMC, and
leave it at that. Sure, some PL/Parrot-based HLL will have to go
through the PMC to get its arguments, rather than having them simply
appear in whatever way makes sense for that language, but it's a
possibility that gets us past the sticky problem of knowing beforehand
what makes sense for whatever language a person might want to use.

That, of course, raises this question: If we sidestep the problem of
how precisely to make the arguments appear in some way the language
can handle by sticking them in a PMC, we then have the same problem
providing the PMC in a way the language can handle. Suggestions? :)

[Joshua Tolley]

I tend to forget that Parrot is a moving target, and we can influence it to
make changes that will benefit us. Perhaps the best solution is to ask for a
new API that's similar to Parrot_ext_call(), but that always accepts an array
of PMCs as input arguments and a single PMC pointer as an output argument. I
realize the sorts of arguments you sent to or receive from a subroutine might
not always be PMCs, but certainly we can wrap them in a PMC, no?

[Jonathan Leto]

Howdy,

These are some really good ideas and issues to bring up. Once we get
over the hump of being able to pass function arguments and return
values between Parrot and Postgres, a lot possibilities for other
people to hack on stuff will open up.

Deciding how to do this in a way that will work for all HLL's on
Parrot is key, but we may want to just find some solution that works
for PIR right now, so it is not blocking us from doing other stuff. I
will ponder and research this more and get back to you.

Duke

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkuSV5cACgkQRiRfCGf1UMN3cACfX4KDes+TU0O+1v4V0TcZtCSE
> DUEAn3mFtdGxHYuiEIYsUovloWcfJ6Lv
> =qDdp
> -----END PGP SIGNATURE-----
>
>

--
Jonathan "Duke" Leto
jona...@leto.net
http://leto.net