Further to: Resumable ops and exceptions

[Jos Visser]

There are a number of ops that could fail. Examples are find_lex but
also the various load and lookup ops. Options for handling failure are:

- Abort parrot
- Throw an exception
- Return a default (null) value

I think it is hard for the parrot designers to decide what language
implementors want (given the vast array of languages out there for which
parrot is a godsend). I am currently extending my OpenComal interpreter
with a parrot code generator and since Comal is a somewhat awkward
language I need different things than the average perl/python/hq9
implementor.

I would therefore vote for a feature where I (as language designer)
could indicate whether for instance a find_lex (but others too) fails
silently (null return value) or with an exception.

Maybe this should be a global something...

Real CPU's often have a control register that contains CPU-wide flags.
Maybe parrot needs one too?

++Jos.es

--
ek is so lug jy vlieg deur my
sonder jou is ek sonder patroon
"Breyten Breytenbach"

[Leopold Toetsch]

Jos Visser wrote:

> There are a number of ops that could fail. Examples are find_lex but
> also the various load and lookup ops. Options for handling failure are:
>

> I would therefore vote for a feature where I (as language designer)
> could indicate whether for instance a find_lex (but others too) fails
> silently (null return value) or with an exception.

Or you install an exception handler that just returns, when a
LEXICAL_NOT_FOUND exception object is seen.
But this is only possible at opcode level. Anyway, we first should move
the internal_exception out of scratchpad_get (and similar) to the
opcode. Then we can do both, throw a resumable exception or ignore the
error (depending on your poposed flags). We already have ctx->warns for
e.g. PerlUndef warnings, why not an error flag too.

> ++Jos.es

leo

[Piers Cawley]

Jos Visser <jo...@osp.nl> writes:

> There are a number of ops that could fail. Examples are find_lex but
> also the various load and lookup ops. Options for handling failure are:
>
> - Abort parrot
> - Throw an exception
> - Return a default (null) value
>
> I think it is hard for the parrot designers to decide what language
> implementors want (given the vast array of languages out there for which
> parrot is a godsend). I am currently extending my OpenComal interpreter
> with a parrot code generator and since Comal is a somewhat awkward
> language I need different things than the average perl/python/hq9
> implementor.
>
> I would therefore vote for a feature where I (as language designer)
> could indicate whether for instance a find_lex (but others too) fails
> silently (null return value) or with an exception.
>
> Maybe this should be a global something...

Not global. Or, if it is global, it needs to be dynamically scoped
since you could possibly have different modules implemented in
different languages.

--
Piers

[Jos Visser]

On Mon, Aug 11, 2003 at 10:29:26AM +0100 it came to pass that Piers Cawley wrote:
> > Maybe this should be a global something...
>
> Not global. Or, if it is global, it needs to be dynamically scoped
> since you could possibly have different modules implemented in
> different languages.

After some thought it occurred to me as well that a global/thread based
status register would indeed be unhandy since different routines
(written in different languages) must save/change/use/restore the
register. An exception is indeed the better way to go...

++Jos.nl