Alright, here's an issue I was musing on after dinner
yesterday: There are huge sets of optimizations that could
be made *if* the user promises not to do certain things.
For instance, who needs a symbol table when the user has
promised not to do any symbolic lookups? (Yes, I know, the
debugger, bu
At 01:26 PM 7/5/2001 -0500, David M. Lloyd wrote:
>Here's a feature suggestion for Perl 6.
>
>It would be nice to be able to tell the interpreter to call a user-defined
>C function between opcodes. This could make it easier to implement
>debuggers, profilers, etc. as well as providing a method of
At 07:10 PM 7/5/2001 -0400, Bryan C. Warnock wrote:
>On Thursday 05 July 2001 02:11 pm, Dan Sugalski wrote:
> > =begin question
> >
> > Should we scrap the buffer pointer and just tack the buffer on the end
> > of the structure? Saves a level of indirection, but means if we need
> > to make the bu
At 02:49 AM 7/6/2001 -0400, Uri Guttman wrote:
>question:
>
>can you declare at the language level a scalar to be a bigint or bignum?
I think Larry's planning on that, yep. For arrays and hashes at least, I
expect, and I don't see why not for scalars too.
>that means that native format is never
At 05:38 AM 7/6/2001 -0700, Benjamin Stuhl wrote:
>Alright, here's an issue I was musing on after dinner
>yesterday: There are huge sets of optimizations that could
>be made *if* the user promises not to do certain things.
>For instance, who needs a symbol table when the user has
>promised not to
> I'm not sure we need a separate flag for optimization level and
> assumptions, but if we do something more like what Compaq C does:
>
>-optimize=(level=5,inline) -assume=(nosub_redefinition,notype_change)
The () will unleash the hell in UNIX shells.
> Yes, I know it's wordier, but the ab
At 09:51 AM 7/6/2001 -0500, Jarkko Hietaniemi wrote:
> > I'm not sure we need a separate flag for optimization level and
> > assumptions, but if we do something more like what Compaq C does:
> >
> >-optimize=(level=5,inline) -assume=(nosub_redefinition,notype_change)
>
>The () will unleash the
On Fri, 6 Jul 2001, Dan Sugalski wrote:
> At 01:26 PM 7/5/2001 -0500, David M. Lloyd wrote:
>
> >It would be nice to be able to tell the interpreter to call a user-defined
> >C function between opcodes. This could make it easier to implement
> >debuggers, profilers, etc. as well as providing a m
At 11:44 AM 7/6/2001 -0500, David M. Lloyd wrote:
>On Fri, 6 Jul 2001, Dan Sugalski wrote:
>
> > At 01:26 PM 7/5/2001 -0500, David M. Lloyd wrote:
> >
> > >It would be nice to be able to tell the interpreter to call a user-defined
> > >C function between opcodes. This could make it easier to impl
On Fri, 6 Jul 2001, Dan Sugalski wrote:
> > > You've pretty much got it. The flag-checking will be hardwired, but
> > > there's no reason that the function called can't be user-defined.
> > > Being able to install an arbitrary number of user-defined inter-opcode
> > > (and inter-statement) functi
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> We won't be using a char-based string math library--it'll all be
DS> some internal binary format or other. (I can make a good argument
DS> for it being done with a base 10 exponent rather than a base 2
DS> one. I can see doing it
Benjamin Stuhl wrote:
> (eg. I solemnly swear to never use symbolic
> references, count on specific op patterns, or
> use any number large enough to require
> bignums.)
These are things (aside from the number limit, but overflow catching
is need
Dan Sugalski wrote:
> The C structure that represents a bigint is:
>
>struct bigint {
> void *buffer;
> UV length;
> IV exponent;
> UV flags;
>}
>
> =begin question
>
> Should we scrap the buffer pointer and just tack the buffer on the end
> of the structure? Saves
At 12:51 PM 7/6/2001 -0500, David L. Nicol wrote:
>Benjamin Stuhl wrote:
>
> > (eg. I solemnly swear to never use symbolic
> > references, count on specific op patterns, or
> > use any number large enough to require
> > bignums.)
>
>These are thin
Dan Sugalski wrote:
>
> At 12:51 PM 7/6/2001 -0500, David L. Nicol wrote:
> >Benjamin Stuhl wrote:
> >
> > > (eg. I solemnly swear to never use symbolic
> > > references, count on specific op patterns, or
> > > use any number large enough to require
> > >
At 01:59 PM 7/6/2001 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
> >
> > At 12:51 PM 7/6/2001 -0500, David L. Nicol wrote:
> > >Benjamin Stuhl wrote:
> > >
> > > > (eg. I solemnly swear to never use symbolic
> > > > references, count on specific op patterns, or
> > >
Dan Sugalski wrote:
>
> At 01:59 PM 7/6/2001 -0500, David L. Nicol wrote:
> in-code pragmata instead of compiler switches?
>
> Lexically scoped optimization hints seem like rather a tricky thing to deal
> with.
I know I'm naive but here's how I see it:
-> we design a linkage standard
At 02:38 PM 7/6/2001 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
> >
> > At 01:59 PM 7/6/2001 -0500, David L. Nicol wrote:
> > in-code pragmata instead of compiler switches?
> >
> > Lexically scoped optimization hints seem like rather a tricky thing to deal
> > with.
>
>I know I'm naive but
18 matches
Mail list logo
