Front page | perl.perl5.porters |
Postings from September 2023
Re: PPC Elevator Pitch for Perl::Types
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
September 2, 2023 18:54
Subject:
Re: PPC Elevator Pitch for Perl::Types
Message ID:
ZPOEyLenoLHuPZ6Z@iabyn.com
On Sat, Sep 02, 2023 at 04:11:02AM +0000, Oodler 577 via perl5-porters wrote:
> > If the latter, please expand.
>
> It is not an actual source filter as documented in `perlfilter`,
> although it is the same general concept. As mentioned in the
> previous response, _"this source-filter-like functionality is
> currently contained in the Perl compiler's file `Class.pm` and is
> triggered by including `use RPerl;` in a Perl source code file."_
> You can see the filter-like implementation in the link and code
> snippet from our last response:
We seem to be misunderstanding each other at a fairly fundamental level.
My understanding (and please correct me if I'm wrong) is that your desired
eventual outcome of this discussion is that a distribution called
Perl:Types will be available on CPAN, and will also bundled into the perl
distribution, so that someone with a standard perl install can type into
their code something like:
use Perl::Types;
my integer $x = f(); # croaks if f() doesn't return an int.
This is independent of the existence of RPerl - i.e. some code from RPerl
may be incorporated into Perl::Types source, but the perl use isn't
required to install RPerl or use any of the weird RPerl syntax.
So, with that understanding, I've expressed curiosity as to how you are
going to implement this functionality using only the resources available
in perl. You said "Source filters". I said that was a bad idea. You've now
said "it's something similar to a source filter - look at this RPerl
code".
Why should I look at RPerl code? I'm not interested in RPerl. I Don't like
RPerl.
Do you believe it is possible to implement Perl::Types in perl? If so, how?
If not, are you suggesting proposals for new hooks or APIs that should be
incorporated into perl to make adding type systems easier? Or what?
I really have no idea what it is you're asking.
> Yes we agree this could be a source of problems.
>
> Rather than using a source filter (or similar mechanism as detailed
> above), can you please suggest a more stable and reliable
> implementation?
I have no idea. It may not be possible. It's not my problem.
> Rather than using `tie`, can you please suggest a more performant
> and reliable implementation?
No I can't. I haven't got a clue. I've spent 20 years working on the
internals of perl, and I think what you are requesting is a very difficult
to solve problem that may well have no solution.
> Adding data types to your Perl source code is the first step on
> the path toward compiling your Perl source code, which can provide
> anywhere from 10x to 400x (or more) runtime performance increase.
Ah yes, sprinkle on a bit of magic pixie dust and suddenly perl can be
made 400x faster.
> Yes you are correct that enabling type-checking will introduce
> runtime overhead to interpreted Perl code, but that slowdown
> disappears once your Perl code is fully compiled because the
> type-checking is done at compile time rather than runtime.
That way lies RPerl, surely?
> For those who want type-checking for interpreted Perl code only,
> we have done our best to minimize the runtime overhead by allowing
> the developer to choose between `foo_CHECKTRACE()` and the slightly
> faster `foo_CHECK()`. As mentioned, _"type checking is currently
> controlled on a per-file basis using the `TYPE_CHECKING` preprocessor
> directive"_:
I don't understand that all all. Please stop just pointing at random bits
of RPerl code which I am completely unfamiliar with and expecting that to
be an explanation.
> > > * memory safety (bounds checking)
>
> > Can you give an example of where currently perl isn't memory safe, but
> > Perl::Types would make it so?
>
> We are not currently aware of any such issues with the Perl
> interpreter, and our goal is not to attempt to point out anything
> wrong with the interpreter's memory management. Rather, this is
> again primarily related to the need for memory bounds checking for
> those who wish to compile their Perl code.
So using Perl::Types doesn't actually add any value to user's code as
regards memory safety.
> Can you please suggest possible pure-Perl syntax alternatives for
> specifying the various maximum indices of an arbitrarily-nested
> `array` and `arrayref`, without requiring any changes to the existing
> Perl internals?
Again, stop trying to make everything my responsibility.
> What are your thoughts on this kind of polymorphism, function overloading based on argument and/or return value data type(s)?
I don't have any strong opinions on it, but personally I don't see what
value it adds. It seems to be that, after adding a type system which
unduly limits the flexibility of your code, adding polymorphism based on
type just allows you to then remove *some* of that inconvenience.
I like the fact that in perl I can throw an int or a float or
string at a function, and it will already always do the Right Thing.
In perl I can write
while (<>) {
$foo += $1 if /foo=(\d+)/;
}
without having to worry about string to integer conversions or whatever.
> > On a purely individual note, I am finding Perl::Types very unappealing so
> > far.
>
> Can you please give us a specific list of all the things you find
> unappealing?
Well, the basic problem is that we still don't know what semantics
Perl::Types is supposed to provide or how it will be implemented.
So my objections are partly conjectural. But IIUC, RPerl's "type" system
is really just the CPU-level type system. I.e. what you get in C etc,
where an int is a simple 32-bit or 64-bit entity, which is fast but unsafe.
In C, if you do
int i = 0x7fffffffffffffff;
i *= 4;
printf "%d\n", i;
then you'll get some sort of wrapped-around value.
In perl, if you do
my $i = 0x7fffffffffffffff;
$i *= 4;
printf "%s\n", $i;
you get
3.68934881474191e+19
because internally, perl goes to great lengths to avoid overflows and loss
of precision, automatically converting internally between signed int,
unsigned int and doubles etc.
So I'm not keen on the idea of downgrading perl's dynamic type system into
a C-style type system.
In terms of making perl go a lot faster, I have various ideas, but little
time to realise them - there are always too many basic things to fix.
But I much prefer the idea of keeping perl as *perl* (dynamic typing etc)
and let the interpreter do the clever stuff: such as speculative execution
branches where perl assumes (based on code analysis and previous calls
to that code position) that the result will be an integer, and so skips
using full-blown SVs and just does direct integer arithmetic. If at some
point during execution an overflow is detected or whatever, then perl
jumps back to a checkpoint, and this time takes the "heavy" branch using
full-blown SVs etc.
So in something like $a[$x+$y*$z], perl detects that $x, $y and $z are
usually integer values, and takes a short-cut. If that doesn't work out,
then it still gets the right result, just more slowly.
So the user gets the performance benefits without having to rewrite
all their code to include 'integer' declarations everywhere.
As a final caveat, note that I'm more of an internals guy than a language
design guy. So my views on proposed new language features shouldn't be
taken too seriously. But if I say that a particular proposal will be hard
or impossible to implement, take that seriously.
--
The Enterprise successfully ferries an alien VIP from one place to another
without serious incident.
-- Things That Never Happen in "Star Trek" #7
Thread Previous
|
Thread Next