>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 01:50 PM 10/10/00 -0400, Chaim Frenkel wrote:
>> There is an intermediate method, have our own execution and data stack.
>> Basically build a TIL interpreter. This might be intermediate in speed
>> between raw machine code and the perl vararg calls.
DS> Perl functions that are called from outside will have to have some
DS> sort of interpreter attached to 'em. I can see either a default
DS> interpreter, or the one they were compiled into being valid as a
DS> choice.
Hmm, I was probably off base. I was thinking of multiple
implementations of the runops methodology. Not of how to call into
perl only between perl funcs. If at all possible there should be only
one way to write the function and one way to call it.
So that the innards can be independent of the actual implementation. A
Calling from the outside should be extremely limited. One shouldnt' be
allowed to straddle the fence.
>> If not intermediate in speed, I suspect it would involve cleaner
>> looking code. All functions would look the same all calls between
>> internal functions would look the same.
DS> If there's no hit, I'd love to have all perl functions callable from
DS> outside. I'm not sure that'll be the case, though I'm all for it...
I don't think you want that. Calling a perlop directly has to mean that
the caller is signing in blood that there are no guarentees of when it
would break.
We might want someone peeking behind the curtain to supply an expected
version, and we could either accomadate it or break it early enough
to give sufficient time to adjust the code.
<chaim>
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
