develooper Front page | perl.perl5.porters | Postings from June 2021

Re: RFC - core exception catalogue

Thread Previous | Thread Next
Nicholas Clark
June 25, 2021 09:49
Re: RFC - core exception catalogue
Message ID:
On Wed, Jun 23, 2021 at 06:29:20PM +0200, Branislav Zahradník wrote:
> On Wed, 23 Jun 2021 at 17:31, Nicholas Clark <> wrote:

> > Do errors generated from XS code shipped in the core get system exceptions?
> > Perl code? You seem to be wanting to make a distinction between errors
> > based on where they come from, which prevents us adopting code from CPAN
> > (or putting it out onto CPAN)
> >
> depends on point of view. if you can get exception without using require /
> use, than
> it should behave like this.
> OK, so technically what you are saying, that exception catalogue should not
> be singleton
> but available for any other module to use their own numbering scheme. Eg
> eg: ${ ^PerlX_Foo_Bar_00400 }
> That's doable, I can imagine implementation. Did I understand it correctly?

I think you understood it correctly.

I don't think that it's a good idea have different systems for "the core"
and CPAN code, because there's actually a continuum

Core C code <=> XS Extensions <=> Core Perl code <=> Dual life Perl Code <=>
Code on CPAN

and specific implementations can move left or right on that line.

So yes, an exception catalogue that can extend to all of them solves that.

> > > User generated exceptions should be instances (so `isa` can be used in
> > > catch conditions).
> > >
> > > We can also provide "my $errno = define user exception".
> > >
> > > On other hand user should be able to write "die ${ ^PerlX_00400 }"
> >
> > Does *any* other dynamic language use numbers to describe this?
> > A text based system, with a class hierarchy seems much easier to use,
> > without needing to memorise masses of "magic" numbers, or constantly look
> > them up.
> >
> Oracle SQL - standard numbers and range of number to be usable by modules
> (without allocation).

That wasn't what I was thinking of as a dynamic language. (I'm not familiar
with Oracle's SQL, but the SQL in Postgres is not something that I'd consider
as a dynamic language)

I was meaning language without static typing, which we'd consider similar to
Perl, such as Lua, Python, Ruby, TCL (and I guess JS)

but I realise it's actually more than just dynamic. It's

* open source
* no business model
* single implementation defines the standard, instead of a standards doc
* monolithic implementation in C (parser, runtime, support)

and more nuanced, "large ecosystem of extensions written in C"

(JS does not meet all of those criteria.)

I'd *not* even consider MySQL or Postgres as completely useful examples of
"peers" to consider for "how to steal process from" because

* I've worked in firms that paid money for open source database support
* I've never worked in firms that paid money for open source programming
  language support (nor have I even met anyone who has)

I'm aware that ActiveState exists. But I've never met a known customer.
And, curiously, even with the EOL of Python 2, they ran a survey for

1) Does your business still use it?
2) Do you have a migration plan?
3) Would you buy support?

and despite many respondents answering "yes" and "yes" to the first two,
they still mumbled "no" to the third.

It's really not obvious how to monetise programming language maintenance.
Databases and operating systems seem to be viewed as dangerous black boxes
that need security updates, or can eat data and go dead in the water
overnight. Whereas programming languages are "something we can work around
problems in".

So I don't see database SQL implementations as a good example, independent
of open or close source.

Python or Ruby don't have the resources to translate error messages, do they?
And they favour exception hierarchies, over flat catalogues?

> > > ok ! blessed ($@);
> > > ok $@ isa CORE::X::X00400::;
> >
> > You can't do that with the current internals.
> >
> I'm aware of that, that's why it is mentioned as "related work" (or
> follow-ups)

I don't think that it's a good idea to propose ideas that don't really
make sull sense without some other potentially tricky thing not implemented.

> > What you show needs simultaneously to be (in reverse)
> >
> > * an object (with a payload)
> > * that isn't an object
> >
> > This isn't going to work.
> >
> I'd split question into to:
> 1. do you have symbol table attached?
> 2. are you object?
> It can be done with using virtual function table pattern.
> Disadvantage is, according my current knowledge it implies refactoring of
> magic.

It does. And magic is pervasive throughout the core and XS code on CPAN.

What we have this:

struct mgvtbl {
    int		(*svt_get)	(pTHX_ SV *sv, MAGIC* mg);
    int		(*svt_set)	(pTHX_ SV *sv, MAGIC* mg);
    U32		(*svt_len)	(pTHX_ SV *sv, MAGIC* mg);
    int		(*svt_clear)    (pTHX_ SV *sv, MAGIC* mg);
    int		(*svt_free)	(pTHX_ SV *sv, MAGIC* mg);
    int		(*svt_copy)	(pTHX_ SV *sv, MAGIC* mg,
                                        SV *nsv, const char *name, I32 namlen);
    int		(*svt_dup)	(pTHX_ MAGIC *mg, CLONE_PARAMS *param);
    int		(*svt_local)(pTHX_ SV *nsv, MAGIC *mg);

(where length isn't even used any more, now that `length undef` is `undef`.
So don't fret about that U32 not being STRLEN enough)

There is only 1 "get" action. It has no idea about context.

Adding vtables to *SCALAR*s is daunting. It's not even clear if it's
possible, because "SCALAR" is such a bad abstraction - would we really
want to split apart undef, references, strings and numbers? Or something
more than that (namespaces? file handles? exceptions?)

Before we even get to "what belongs in a vtable?"

> > It's similar to wanting to be able to overload references so that
> >
> >    defined $obj
> >
> > returns false - objects are always going to be defined.
> >
> not quite,
> you are asking wrong question which only by a chance returns you answer you
> need.
> you can overload boolean conversion of object and use proper question: "!!
> $obj"

I agree that it's the wrong question. :-)
But people wanted to make code written the "wrong" way work, and so were
struggling to figure out some way to make it possible.

*You* have seen the problem here. They hadn't.

> > Or wanting to call methods on undef
> >
> > * there is only one value that is undefined
> > * it's not an object, and can't be
> >
> It's not object but can have attached namespace.

Yes, but...

Lack of first class namespaces means that it's not possible to autobox
scalars. Hence

* either one needs to solve that to achieve consistency
* or one effectively can autobox `undef`, but no other scalar value

which is either "solve a hard problem" or "introduce bad design"

In turn, even with that solved, as I wrote, there is only one undef value.

So it means that if you want to define methods on undef, effectively you
are globally monkey-patching undef's namespace. Which also seems
"introduce bad design"

For many of these things, it feels that the fixes needed are so intertwined
that you can't make progress without changing so much at once that you end
up with a similar magnitude of change as Perl 6 became.

Which people belatedly realised was really so much that it needed a new name.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About