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

Re: Creating an RFC process for Perl

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 10, 2021 09:12
Subject:
Re: Creating an RFC process for Perl
Message ID:
20210610091211.GA16703@etla.org
On Thu, Jun 10, 2021 at 12:07:54PM +1000, sisyphus wrote:
> On Wed, Jun 9, 2021 at 10:10 PM Neil Bowers <neilb@neilb.org> wrote:
> 
> Two points:
> >
> >    1. Just because you can’t implement something, doesn’t mean you
> >    shouldn’t suggest it. We expect lots of ideas to come from people who are
> >    using Perl every day, regardless of whether they can hack on the core. But
> >    even if an idea is universally liked, it still needs someone to implement
> >    it, and we don’t have too many of those.
> >    2. The first step is to post your idea to p5p, and only move to an RFC
> >    if it survives any discussion there.
> >
> > Nicholas has recently provided a Ryu implementation - see
> https://github.com/MoarVM/MoarVM/pull/1472 .
> IIUC, this will be included in Raku, following review.
> (That's sort of why I addressed my post to Nicholas - but knowing quite
> well that others would feel welcome to make a comment, as they should.)

I don't think that I need to duplicate anything I already wrote there.

"Implementation" and "Licensing" would be the parts that need adding to.


The output of Ryū was not in the format that MoarVM needed.
(It generates something like '1E-4' - what is needed is '1e-04', etc)

So I wrote C code to massage that into the string format needed.*

(I think that for Grisu3, the output also needed changing, but when Zoffix
added Grisu3 it seems that he made the changes in a local copy of the
Grisu3 C code. I thought it clearer to keep the upstream code "virgin"
and do the fixups as "post-processing", so I took this different approach.)

Given that it's submitted to MoarVM, it's implicitly licensed as "Artistic
License 2". I don't *think* that it's acceptable to *just* incorporate AL2
code into a GPL2|AL1 project. So if it turns out in the future we also need
that code here

1) Explicitly as copyright holder I'm fine with that code being used here

and

2) More generally, I'm fine with any code I wrote that is submitted to a
   project with an AL2 licence being re-used (and re-licensed) as dual
   GPL2|AL1 for use in a dual GPL2|AL1 project
   (ie "same terms as Perl itself")
   

Looking a bit further at the Ryū repository I realised that there were
a couple of things to discuss on the PSC, so I stuck it on the agenda for
Friday, and I wasn't going to comment until then. Meanwhile, Neil also
replied...

> I'll prepare and submit a case to p5p, as per your second point ... and see
> where that leads.

Thanks.

Also "changing the internals of how floating point is outputted" isn't
*exactly* covered by the initial list of "things that need an RFC". But it
does feel like the sort of thing that should be an RFC. So thanks for
finding something useful that we missed.

Nicholas Clark

* Co-incidentally I happened to use piece of paper with the notes for that
  code on it as part of lighting the barbecue at the weekend. The code is
  done, and it and the comments covered everything in the notes...

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About