At 09:23 AM 10/1/2001 -0400, Michael Maraist wrote:
> > > Just because parrot knows what functions can croak, it
> > > doesn't mean that
> > > it can possibly know which locks have been taken out all
> > > the way back up
> > > the stack between the call to longjmp and the
> > > corresponding setjmp. And,
> > > under your scheme we would potentially end up with two
> > > copies of every
> > > utility function - one croak_safe and one croak_unsafe.
> >
> > Not very likely - the only reason I can find for most
> > utility functions (other than possibly string coercions) to
> > fail is either panic("out of memory!") or panic("data
> > structures hopelessly confused!") (or maybe panic("mutexes
> > not working!")) - anything likely to throw a programmatic
> > exception would be at the opcode level, and so not be open
> > to being called by random code.
>
>The perl6 high-level description currently sugests that op-codes can
>theoretically
>be written in perl. Perhaps these are only second-class op-codes
>(switched off a single user-defined-op-code), but that suggests that
>the good ole "die/croak" functionality will be desired.
Sure, but that's no problem. Things should propagate up those code streams
the way they do any other.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
