Front page | perl.perl5.porters |
Postings from June 2021
Re: RFC - core exception catalogue
Thread Previous
|
Thread Next
From:
Branislav Zahradník
Date:
June 26, 2021 18:19
Subject:
Re: RFC - core exception catalogue
Message ID:
CAB=rbO=X8XE51xwE_9DriJ8ox_rkiQTzLuJyEUMGvttxPubsYg@mail.gmail.com
On Fri, 25 Jun 2021 at 11:49, Nicholas Clark <nick@ccl4.org> wrote:
>
> 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
>
I'm starting to thing I do not understand what you mean under "different
systems".
From existing code point of view, there will be no change.
With feature enabled (here is my opinion that every new behaviour must be
available
only with proper "use v" declaration), core exceptions will provide
- symbolic, human language independent identification
- symbolic tests for such exceptions
- change / evolution resistant symbols
Symbolic definition should be easy to google (for example, one should be
able to find
such symbol in both English and German texts)
That also leads to as-uniform-as-possible representation in multiple human
langauges.
Core developers should be able to change wording yet symbol must remain
same.
Non-functional reasons to change wording may be human language evolution
or (offensive) unforeseen interpolations.
This proposal is focused on core exceptions, hence PERLX prefix.
Should numeric catalogue be available for modules?
Based on discussion here, yes, it should be available as 1:1 relation to
stash.
Should core catalogue contain standard library extensions?
Unclear.
XSLoader? I'm inclined to yes.
Anything that requires direct "use Anything"? no
>
> 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.
>
> 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)
>
My fault (for being too familiar with Oracle SQL).
Language is Oracle PL/SQL but also SQL language uses same approach.
> I was meaning language without static typing, which we'd consider similar
> to
> Perl, such as Lua, Python, Ruby, TCL (and I guess JS)
>
Honestly, I don't care much about other languages. None of it (including
Perl)
focuses on long term software development (yeah, maintaining real-live
software
is not as funny as writing smart examples and/or new microservices someone
else
had to maintain).
* no business model
>
Isn't "undying perl" in fact 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"
>
Ok, this I don't like. Don't speak about "who doesn't have it" but speak
about
"how it can benefit perl".
>
> Python or Ruby don't have the resources to translate error messages, do
> they?
>
I'm more concerned about users than core.
How many programmers do you know who prefer saying in terms like "invalid
identifier"
in their native language?
It's open source, should it be supported, there will be translations.
> 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.
>
Extrapolate. Should this tricky thing be available, then you can introduce
similar
magic for eg "CORE::Scalar::", "CORE::Array::", ...
What will be benefit of that? Is it worth of experiment?
I'd say yes.
Before we even get to "what belongs in a vtable?"
>
Again, is it worth of experiment?
I'd say yes.
>
> 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.
>
So, here comes "use v".
>
> Yes, but...
>
> Lack of first class namespaces means that it's not possible to autobox
> scalars. Hence
>
Regarding RFC process:
this shows that there are relations between RFCs.
For example later "milestones" this one depends on working autoboxing.
Question here should be only: do we want to go that direction?
If yes, just note this relation in RFC and start with autobox RFC.
I don't disagree with this relation.
(rest of comments removed, premature negativism)
Thread Previous
|
Thread Next