Mailing List Archive

On Wed, Jun 23, 2021 at 07:01:01AM +0200, Branislav Zahradn?k wrote:
> Accepting contribution via github PR:
> https://github.com/happy-barney/perl-poc/blob/perl-rfcs/RFC-exception-catalogue.md

Technically this might no longer be my call to make
(although I may be delegated some work - I'm assuming that the new PSC doesn't
claim a monopoly on enthusiasm either)

but

1) We specifically asked for elevator pitches first, not draft RFCs
2) This draft RFC doesn't fit the template. Sections such as
"Backwards Compatibility" are important, and in the template for that
reason
3) There are actually good ideas in here that can be done independently
This message can be split into several elevator pitches.

ONE:

> ## Express intention with symbol
> ## Deduplicate error literals

This is an internal refactoring, and doesn't need an RFC
(A refactoring by definition shouldn't change user behaviour)

I think that this sort of cleanup would be a really good idea. It's rather
large though - do you have an idea how to do it incrementally?


TWO:

> ## Match errors
>
> Test may look like (although `~~` may be more appropriate)
> ```
> if ($@ == ${^PerlX_00400}) {
> }
> if ($@ == ${^PerlX_Function_Not_Implemented}) {
> }
> ```

This is a user visible change. This itself belongs in an RFC.
Clearly it's dependant on the first refactoring.

Using `==` implies that $@ becomes (at least) a dual var, exposing a
numeric value as well as the original string.

This *seems* like a reasonable idea, but it's not obvious how it it then
interacts with user-generated exceptions, and objects as exceptions.

> ## Fine-tune / evolve exception text
>
> Proposal allows changes of exception texts without breaking old codes.
>
> Once feature (bundle) is enabled, its should be an error to match `$@`
> with regular expressions.
>
> Due backward compatibility there should be two catalogues:
> - compatible (messages will not be modified)
> - evolvable (messages follows this proposal)
>
> Grey area: raising exceptions added after implementing this rfc

You're completely missing user generated exceptions.

> ## Exceptions as an object
>
> Create internal package literals to allow exception match via `isa`
>
> Usable by `catch`
>
> ```
> if ($@ isa CORE::X::X00400::)
> if ($@ isa CORE::X::Function::Not::Found::)
> ```

Exceptions can already be objects:

$ perl -wE 'sub bark { say "woof" }; eval { die bless [] }; say "here"; $@->bark'
here
woof


I don't think that this plan really works as-is. It seems to completely miss
that existing code can already generate exceptions that will not be in the
"official" catalogue, *and* it seems to ignore exception objects.

Nicholas Clark

On Wed, 23 Jun 2021 at 08:47, Nicholas Clark <nick@ccl4.org> wrote:

> On Wed, Jun 23, 2021 at 07:01:01AM +0200, Branislav Zahradník wrote:
> > Accepting contribution via github PR:
> >
> https://github.com/happy-barney/perl-poc/blob/perl-rfcs/RFC-exception-catalogue.md
>
> Technically this might no longer be my call to make
> (although I may be delegated some work - I'm assuming that the new PSC
> doesn't
> claim a monopoly on enthusiasm either)
>
> but
>
> 1) We specifically asked for elevator pitches first, not draft RFCs
> 2) This draft RFC doesn't fit the template. Sections such as
> "Backwards Compatibility" are important, and in the template for that
> reason
> 3) There are actually good ideas in here that can be done independently
> This message can be split into several elevator pitches.
>

ok, so next time no RFC in subject but EPI (EPO? :-))


>
> ONE:
>
> > ## Express intention with symbol
> > ## Deduplicate error literals
>
> This is an internal refactoring, and doesn't need an RFC
> (A refactoring by definition shouldn't change user behaviour)
>
> I think that this sort of cleanup would be a really good idea. It's rather
> large though - do you have an idea how to do it incrementally?
>

Incrementally ? yes, it's possible

Put in here as strongly related (we can even assign numbers internally)


>
>
> TWO:
>
> > ## Match errors
> >
> > Test may look like (although `~~` may be more appropriate)
> > ```
> > if ($@ == ${^PerlX_00400}) {
> > }
> > if ($@ == ${^PerlX_Function_Not_Implemented}) {
> > }
> > ```
>
> This is a user visible change. This itself belongs in an RFC.
> Clearly it's dependant on the first refactoring.
>
> Using `==` implies that $@ becomes (at least) a dual var, exposing a
> numeric value as well as the original string.
>

> This *seems* like a reasonable idea, but it's not obvious how it it then
> interacts with user-generated exceptions, and objects as exceptions.
>
>

I agree, `==` may not be proper operator (I used "may look" for that
therefore I mentioned
that smart match will be much more appropriate.Or abusing `isa` to detect
it's behaviour by rhs



> > Grey area: raising exceptions added after implementing this rfc
>
> You're completely missing user generated exceptions.
>

Yes and no.

User generated exceptions will never match system exceptions and doesn't
need
follow "error number" pattern.

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 }"


>
> > ## Exceptions as an object
> >
> > Create internal package literals to allow exception match via `isa`
> >
> > Usable by `catch`
> >
> > ```
> > if ($@ isa CORE::X::X00400::)
> > if ($@ isa CORE::X::Function::Not::Found::)
> > ```
>
> Exceptions can already be objects:
>
>
This proposal is about internal exceptions, those witch currently acts as
strings.
Idea behind this is to pass this tests:

ok ! blessed ($@);
ok $@ isa CORE::X::X00400::;


>
> I don't think that this plan really works as-is. It seems to completely
> miss
> that existing code can already generate exceptions that will not be in the
> "official" catalogue, *and* it seems to ignore exception objects.
>

This proposal covers only internal exceptions (I'm sorry if it was not
clear)




>
> Nicholas Clark
>

On Wed, Jun 23, 2021 at 11:24:36AM +0200, Branislav Zahradn?k wrote:
> On Wed, 23 Jun 2021 at 08:47, Nicholas Clark <nick@ccl4.org> wrote:
>
> > On Wed, Jun 23, 2021 at 07:01:01AM +0200, Branislav Zahradn?k wrote:
> > > Accepting contribution via github PR:
> > >
> > https://github.com/happy-barney/perl-poc/blob/perl-rfcs/RFC-exception-catalogue.md
> >
> > Technically this might no longer be my call to make
> > (although I may be delegated some work - I'm assuming that the new PSC
> > doesn't
> > claim a monopoly on enthusiasm either)
> >
> > but
> >
> > 1) We specifically asked for elevator pitches first, not draft RFCs
> > 2) This draft RFC doesn't fit the template. Sections such as
> > "Backwards Compatibility" are important, and in the template for that
> > reason
> > 3) There are actually good ideas in here that can be done independently
> > This message can be split into several elevator pitches.
> >
>
> ok, so next time no RFC in subject but EPI (EPO? :-))

Not just this.

Please also start with the "elevator pitch", not the full RFC.
You're welcome to *link* to a larger document, but pitch the pitch to
the list.

I'm behind on doing the minutes from last Friday, but we explicitly
discussed this, and we unanimously agreed that it was important to start
with (*short*) elevator pitches, not large templated documents.

It's easy to swamp the list with documents that are too large for people
to read, and so there won't be fast useful responses. There's a 1:500
ratio between writing an e-mail to the list and reading it - it *is* of
net benefit to the list functioning to write less at first.

(So yes, technically the new PSC can change its mind, but that would need
not just Paul disagreeing with what I just wrote, but also having Neil and
Rik change their minds.)

This is my opinion (not the previous or current PSC's) but getting the idea
summarised down to the elevator pitch is important. If it's proving hard,
that could mean:

1) There's actually more than one idea. (so more than 1 pitch and RFC)
2) It's not the right part of a bigger plan to start with
3) The plan is too large for the RFC process to handle.

That last one also matters - the RFC process was intended for incremental
changes. Things that can get done easily within a release cycle, and things
that (mostly) stand alone.

If the changes don't make sense without so many other things changed too,
such that features would need to ship "next year" that aren't actually
used yet, then that's something that belongs as a bigger branch (or
branches) that get rebased, but don't get merged until there's something
for the end user.

> > > Grey area: raising exceptions added after implementing this rfc
> >
> > You're completely missing user generated exceptions.
> >
>
> Yes and no.
>
> User generated exceptions will never match system exceptions and doesn't
> need
> follow "error number" pattern.

I'm not convinced that this is a good direction to go - building a system
where one set of errors are "first class" and the others not.

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)

> 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.

> > > ## Exceptions as an object
> > >
> > > Create internal package literals to allow exception match via `isa`
> > >
> > > Usable by `catch`
> > >
> > > ```
> > > if ($@ isa CORE::X::X00400::)
> > > if ($@ isa CORE::X::Function::Not::Found::)
> > > ```
> >
> > Exceptions can already be objects:
> >
> >
> This proposal is about internal exceptions, those witch currently acts as
> strings.
> Idea behind this is to pass this tests:
>
> ok ! blessed ($@);
> ok $@ isa CORE::X::X00400::;

You can't do that with the current internals.

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.

It's similar to wanting to be able to overload references so that

defined $obj

returns false - objects are always going to be defined.

Or wanting to call methods on undef

* there is only one value that is undefined
* it's not an object, and can't be

Nicholas Clark

On Wed, 23 Jun 2021 at 17:31, Nicholas Clark <nick@ccl4.org> wrote:

>
> Not just this.
>
> Please also start with the "elevator pitch", not the full RFC.
> You're welcome to *link* to a larger document, but pitch the pitch to
> the list.
>

Oh, that's what I'm actually doing, stripping parts of much larger document
.. :-)

But I got what you want to say.


> That last one also matters - the RFC process was intended for incremental
> changes. Things that can get done easily within a release cycle, and things
> that (mostly) stand alone.
>

So this answers my question I had when you came with RFC idea (maybe it was
answered then and I missed that) - yes, there will be milestones. And that
probably
answers markdown vs pod - github flavored markdown has task list.


> > User generated exceptions will never match system exceptions and doesn't
> > need
> > follow "error number" pattern.
>
> I'm not convinced that this is a good direction to go - building a system
> where one set of errors are "first class" and the others not.
>
> 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?


> > 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).



>
> >
> > 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)

>
>
> 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'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"


>
> 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.


>
> Nicholas Clark
>

On Wed, Jun 23, 2021 at 06:29:20PM +0200, Branislav Zahradn?k wrote:
> On Wed, 23 Jun 2021 at 17:31, Nicholas Clark <nick@ccl4.org> 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
contracts
* 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

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)

On Sat, Jun 26, 2021 at 08:18:41PM +0200, Branislav Zahradn?k wrote:
> On Fri, 25 Jun 2021 at 11:49, Nicholas Clark <nick@ccl4.org> wrote:

[re-ordered to make my reply flow better]

> > * no business model
> >
>
> Isn't "undying perl" in fact business model ? :-)

No, it's a "battle plan". I guess, more, it's a campaign strategy.

We're not going to win each individual battle. We just need to win more, and
pick battles we can win.

What I mean, and this is *key*, is that we don't have a revenue stream that
lets us pay developers to work on things we want.

Any plan that assumes that we can direct people to work on particular tasks
won't work. Any plan that requires it will fail.

This is why I ask "does Python do this?" "does Ruby do this?" etc.

Because if for an idea the answer is "no" to all of the (valid) peers, then
it's not obvious that it will work for us, and we certainly shouldn't
*assume* this.

The models of commercial software don't all apply to open source projects
without revenue streams.

(Some do - shipping a perl release is like shrink wrap software - once it
escapes, you have to live with the consequences forever. You can't hot fix
all the servers and be happy that your bug is gone.)

> > 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.

SQL isn't a dynamic language, and I believe doesn't have classes.

It's not a good comparison. Starting here is starting from the wrong place.

> > 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).

You should.

If you don't (and *everyone* doesn't) look at what works and what failed for
equivalent languages (eg the timescales of the Python 3 rollout), then

* we're proposing ideas in a vacuum
* we're not learning from other people's history, and are at risk of
repeating it

> > 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.

Translations are effort. Keeping translations up to date is more effort.

There's always the first obvious question - what happens if the programmer
needs to change the original text of an error message, potentially
invalidating the translations...

* change blocks until all translations can be updated?
* change happens - translations now stale, keep using stale translations?
* change happens - translations now invalid and not used?

No answer is pretty.


I believe that *none* of Perl's peers think it worth translating error
messages, and many have more resources than we do. I don't think that it's
realistic to assume that we should because we could. We *can't*. We don't
have the resources.

Diverting time to "being able to translate error messages" is diverting time
from delivering other features.

I don't think we're going to win back any mindshare with this feature.
We're not losing developers because other languages have translations and we
don't.


> > * 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".

Please don't think that you can dismiss this.

"large ecosystem of extensions written in C" *matters*. It means that the C
internals are exposed to a large amount of code upon which the success of
the language as a whole depends.

Meaning that it's not *easy* to refactor the C code, because there are
dependencies on it that can't easily be changed, and hence have to keep
working. For example, DBI and DBD.

JavaScript doesn't expose a C API. (Strictly, "JavaScript implementations")
This gives their implementers a *lot* more freedom to change internal
representations to gain more flexibility or performance.

It also makes writing a JIT a lot lot easier.

> > 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.

Agree, yes, it's worth an experiment. Experiments are always approved of!
Some fail. That's the point. It's research.

But good science changes as few variables as possible, as it's easier to
control for.

(Heck, that is about the *only* thing in this mail that I'm formally qualified
to say. Seriously. But seriously qualified to say it. The development stuff is
all experience)

Running several experiments in parallel takes more researchers. Or slows
down getting the results of any single experiment.

Nothing stops anyone experimenting or prototyping.


> 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)

The intent of the RFCs is not about "approving experiments". It's about
assessing proposals that look like they will work, and can delivers.

Implicit, but ought to be explicit is "deliver soon".

This is the "choosing battles" thing, and not repeating obvious mistakes.

We're trying not to repeat the great Perl 6 mistake of "taking 15 years to
deliver". We need to deliver improvements soon.

We have plenty of suggestions, far more than we have volunteers to implement
them.

So

* we need to prioritise things that we can deliver this year
* to lower risk, we should pick things that have few(er) dependencies

experiments can run in parallel. experiments don't need RFCs.
RFCs should be for plans that can deliver.

Nicholas Clark