Re: RFC 334 (v1) I'm really trying to understand this...
If you get the chance, I would really grateful if you could translate the abstract into lay terms, just confused by the concept of "low level perl" Why??, perl is my only (byte) compiled language... ...I'm an admin. TIA ;)
Re: RFC 334 (v1) I'm really trying to understand this...
On Thu, Oct 12, 2000 at 07:10:30PM -, John van V wrote: If you get the chance, I would really grateful if you could translate the abstract into lay terms, just confused by the concept of "low level perl" * We want to call Perl routines as if they were C routines. * This means applications which embed Perl don't have to care whether the various routines they're about to call are C or Perl. * It also means we can write bits of perl in Perl, and similarly not have to care about this fact. -- It is now pitch dark. If you proceed, you will likely fall into a pit.
Re: RFC 334 (v1) Perl should allow specially attributed subs to be called as C functions
At 06:30 PM 10/10/00 -0400, John Porter wrote: Dan Sugalski wrote: Perl functions that are called from outside will have to have some sort of interpreter attached to 'em. I can see either a default interpreter, or the one they were compiled into being valid as a choice. If there's no hit, I'd love to have all perl functions callable from outside. I'm not sure that'll be the case, though I'm all for it... As you say, it's a matter of providing context. For some categories of functions, the only context necessary will be an interpreter handle. For other, presumably lower-level, functions, other gobs of context will be needed. If it will be possible to encapsulate that other context stuff into a ball, then presumably a handle to that ball can be handed to the calling program, for use in future calls. But that may be a big "if"... It may be a huge and insurmountable "if". It may even require the caller to do some sort of semi-global setup or something. (PERL_SET_CONTEXT, say) It may turn out that the context required to function will make this proposal infeasable, though I hope not. (Might be tricky when using it with multiple active interpreters, but I bet we can do it in the single-interpreter case at least) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 334 (v1) I'm {STILL} trying to understand this...
At 07:48 PM 10/12/00 +, John van V wrote: * It also means we can write bits of perl in Perl, and similarly not have to care about this fact. Granted, some developers are thick as a brick... If you are writing perl in Perl, then, presumably, you would know this. But perl won't be written in Perl. It'll be written in C, most likely. It'll be written in a modular and overridable way, though. And that means that if we want to override things with perl code, that perl code needs to be callable the same way that any C function is. Doing this also means someone writing an app with an embedded perl interpreter can call into perl code the same way as they call into any C library. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 334 (v1) Ahhhh.. i get it
$thanks - (1000K)
Re: RFC 334 (v1) I'm {STILL} trying to understand this...
At 08:57 PM 10/12/00 +0100, Simon Cozens wrote:
On Thu, Oct 12, 2000 at 03:43:07PM -0400, Dan Sugalski wrote:
Doing this also means someone writing an app with an embedded perl
interpreter can call into perl code the same way as they call into any C
library.
Of course, the problem comes that we can't have anonymous functions in C.
Sure we do. You can get a pointer to a function, and then call that
function through the pointer. (Though argument handling's rather dodgy)
That is, if we want to call Perl sub "foo", we'll really need to call
something like
call_perl("foo", ..args... );
whereas we'd much rather do this:
foo(..args..)
(Especially since C's handling of varargs is, well, unpleasant.)
C's vararg handling sucks in many sublime and profound ways. It does,
though, work. If we declare in advance that all C-visible perl functions
have an official parameter list of (...), then we can make it work. The
calling program would just fetch function pointers from us somehow, and do
the call in.
Granted this will be a pain on our side (since I expect the C vararg stuff
is very different from platform to platform, even more so (and more
annoyingly) than plain function call stuff) but it is doable.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: RFC 334 (v1) Ahhhh.. i get it
Heh. In my youth, we said "Thanks a million." I see that inflation has now turned that into "Thanks a million and twenty four thousand." : On 12 Oct 2000, John van V wrote: $thanks - (1000K)
Re: RFC 334 (v1) I'm {STILL} trying to understand this...
Dan Sugalski [EMAIL PROTECTED] writes: C's vararg handling sucks in many sublime and profound ways. It does, though, work. If we declare in advance that all C-visible perl functions have an official parameter list of (...), then we can make it work. The calling program would just fetch function pointers from us somehow, and do the call in. Can't. ISO C requires that all variadic functions take at least one named parameter. The best you can do is something like (void *, ...). -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 334 (v1) I'm {STILL} trying to understand this...
On Thu, Oct 12, 2000 at 03:24:23PM -0700, Russ Allbery wrote: Can't. ISO C requires that all variadic functions take at least one named parameter. The best you can do is something like (void *, ...). Argh. Can't we just use a stack? I like stacks. Stacks make sense. -- ..you could spend *all day* customizing the title bar. Believe me. I speak from experience." (By Matt Welsh)
Re: RFC 334 (v1) I'm {STILL} trying to understand this...
At 12:07 AM 10/13/00 +0100, Simon Cozens wrote: On Thu, Oct 12, 2000 at 03:24:23PM -0700, Russ Allbery wrote: Can't. ISO C requires that all variadic functions take at least one named parameter. The best you can do is something like (void *, ...). Well, damn. And I mean that sincerely. :( Argh. Can't we just use a stack? I like stacks. Stacks make sense. Stacks cost time and programmer effort. Parameters are generally passed in registers, (how many depends on your architecture, but sane ones have a bunch) while stacks require smacking data into memory somewhere and messing with the stack pointer. Even if you have a macro to push, it means doing this: PUSH(i); PUSH(j); PUSH(k); call_foo(); instead of: call_foo(i, j, k); Stacks are OK for internal work (though I'd prefer a register file, if even a virtual one) but for externally exposed stuff we're better off taking parameters if we can. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 334 (v1) I'm {STILL} trying to understand this...
Dan Sugalski wrote: Well, damn. And I mean that sincerely. :( I don't think it's that big a deal. Easy enough to wrap in a macro. -- John Porter
Re: RFC 334 (v1) I'm {STILL} trying to understand this...
On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote: Dan Sugalski wrote: Well, damn. And I mean that sincerely. :( I don't think it's that big a deal. Easy enough to wrap in a macro. I thought (hoped) that the plan was the avoid the cpp like the plague and cancer it is. The massive overdose of cpp magic is one of the main reasons why understanding/debugging/developing Perl 5 core is so much fun. This example is slightly off because most of the "fun" is courtesy gcc, not perl, but I think it illustrates the point quite nicely. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-08/msg01810.html -- John Porter -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 334 (v1) I'm {STILL} trying to understand this...
Jarkko Hietaniemi wrote: On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote: I don't think it's that big a deal. Easy enough to wrap in a macro. I thought (hoped) that the plan was the avoid the cpp like the plague and cancer it is. Well, yes, definitely; but we're just adding an argument to the front of the arg list. Is that so bad? -- John Porter
Re: RFC 334 (v1) I'm {STILL} trying to understand this...
At 11:21 PM 10/12/00 -0400, John Porter wrote: Jarkko Hietaniemi wrote: On Thu, Oct 12, 2000 at 10:55:52PM -0400, John Porter wrote: I don't think it's that big a deal. Easy enough to wrap in a macro. I thought (hoped) that the plan was the avoid the cpp like the plague and cancer it is. Well, yes, definitely; but we're just adding an argument to the front of the arg list. Is that so bad? Yes, it is. Extra arguments cost. It's not free to pass them in by any means--you can see hits up to 10% in some extreme cases. If the arguments are used it's one thing, but if they're dummy (as they would be in those cases where the indirect routine you're calling *isn't* a perl one) then that cost can really add up. CPP won't help us either, since we'll be calling these routines indirectly, via a function pointer in C. There's no way we can reasonably get CPP involved, even if we wanted to. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
