On Wed, Jun 13, 2001 at 07:17:06PM +, Nick Ing-Simmons wrote:
> Given the inner functions we could presumable generate the decode
> functions (c.f. xsubpp)
This is something I'm very much in favour of: it doesn't matter if
vtables mean we have loads of little functions, because we can auto-g
At 02:40 PM 6/13/2001 +0100, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 12:00 PM 6/13/2001 +0100, Dave Mitchell wrote:
> > >should we abandon vtables (ie arrays of fn pointers indexed by op),
> > >and just have a single hander function per type which has the op as an
> a
At 03:40 PM 6/12/2001 -0700, Damien Neil wrote:
>On Tue, Jun 12, 2001 at 06:12:35PM -0400, Dan Sugalski wrote:
> > At the moment I'm leaning towards the functions doing their own decoding,
> > as it seems likely to be faster. (Though we'd be duplicating the decoding
> > logic everywhere, and bigge
Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>I don't see where shadow functions are really necessary -
>after all, no one has ever complained that you can't do
>
>pp_chomp(sv); /* or pp_add(sv1, sv2), for that matter */
>
>in Perl 5.
Yes we did. And note the doop.c file which is part answer
to t
At 05:15 PM 6/13/2001 +0200, Bart Lateur wrote:
>On Wed, 13 Jun 2001 01:22:32 +0100, Simon Cozens wrote:
>
> > Something that should be part of the core? I'll leave
> >that for you to decide.
>
>Most definitely NOT.
Most definitely sort of.
>There is no reason to put fucntionality for free match
On Wed, 13 Jun 2001 01:22:32 +0100, Simon Cozens wrote:
> Something that should be part of the core? I'll leave
>that for you to decide.
Most definitely NOT.
There is no reason to put fucntionality for free matching of Japanese
characters into the basic perl executable. There were already voice
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:00 PM 6/13/2001 +0100, Dave Mitchell wrote:
> >should we abandon vtables (ie arrays of fn pointers indexed by op),
> >and just have a single hander function per type which has the op as an arg?
>
> Are you talking vtables (which we're using for func
At 12:00 PM 6/13/2001 +0100, Dave Mitchell wrote:
>I was thinking back to the earlier discusions on opcode dispatch,
>and the fact that some people thought that a big switch was as good as,
>or possibly faster than a dispatch table. Which led me to think...
The only reason big switch statements a
At 01:13 PM 6/13/2001 +0200, Bart Lateur wrote:
>On Tue, 12 Jun 2001 18:12:35 -0400, Dan Sugalski wrote:
>
> >'Kay, here's a question to ponder. Should the op dispatch loop handle
> >argument decoding, or should that be left to the opcode functions?
>
>Are you talking about lazy vs. normal evaluat
On Wed, 13 Jun 2001 12:00:21 +0100 (BST), Dave Mitchell wrote:
>I was thinking back to the earlier discusions on opcode dispatch,
>and the fact that some people thought that a big switch was as good as,
>or possibly faster than a dispatch table. Which led me to think...
I would think that a swit
On Tue, 12 Jun 2001 18:12:35 -0400, Dan Sugalski wrote:
>'Kay, here's a question to ponder. Should the op dispatch loop handle
>argument decoding, or should that be left to the opcode functions?
Are you talking about lazy vs. normal evaluation?
Lisp knows basically two modes, normal evaluation
mad thought for the day:
I was thinking back to the earlier discusions on opcode dispatch,
and the fact that some people thought that a big switch was as good as,
or possibly faster than a dispatch table. Which led me to think...
should we abandon vtables (ie arrays of fn pointers indexed by op)
12 matches
Mail list logo
