Mailing List Archive

On Wed, 16 Aug 2023 04:37:07 +0000
Oodler 577 via perl5-porters <perl5-porters@perl.org> wrote:

...

The following is my personal response, though it is shaped somewhat
along the direction that seems to agree with the PSC's feelings overall.

My short reaction to this: No.


My medium-sized reaction to this: This doesn't sound like the sort of
thing that is either a) a natural extension to the way that people
currently write Perl code, nor b) an end-goal direction that I would be
happy to see the language go in.

------

What now follows is a much longer essay explaining my reasoning for
saying the-above. It's not necessary to read this simply to get my
answer.


## A Natural Extension

When trying to design new Perl features, I am often inspired by two
other languages whose history I have followed - C and Scheme. There's
some interesting parallels. I'm not referring to technical features of
those languages, but of some interesting points of history. Both
languages are defined by a formal specification, with multiple
different implementations and users all trying to share it. ANSI C and
then C89 were both specifications that wrote down and formalized what
had been existing common practice around compilers and implementations.
The same was true for Scheme specs up to R5RS. After that, both C99 and
R6RS did something weird. They both (independently) went off in a
direction where the language spec itself tried to invent new concepts,
before they were commonly implemented or commonly used by users of
those languages. I think it's fair to say that neither spec was
well-received by either its implementors or its users. Sure both had
some good points, but in both cases the spec was found to have
over-reached, promising things that implementors didn't want to create
and users couldn't imagine they'd want. In time both were quietly
retconned. C11 mostly builds atop C89, offering as "optional" a bunch of
things that C99 offered but nobody liked. Scheme R7RS has now been
split into a "small" and a "large" model that basically builds on top
of R5RS and pretends R6 never happened.

(There's also some interesting parallel here with Perl: going up to 5,
trying to invent new things at 6, then splitting off to its own new
name while 5 continues in the hope of an eventual 7. But I digress ;) )

The point I'm trying to make here is that successful languages almost
always come out of observing what people are *actually* doing or
wanting to do but can't for lack of features, and formalizing those
behaviours into convenient concepts within the language so everyone can
operate on common terms.

Lets take a comparison here to Perl's subroutine signatures. At first,
Perl didn't have such a feature natively, but gave users the building
blocks (via the @_ array) to construct something of that nature
themselves. So eventually lots of people were writing code looking
something like

sub f { my ($x, $y, @z) = @_; ... }

When signatures were added, they didn't really add fundamentally new
abilities; they just tidied up what had been existing practice up til
that point. They allowed people to write code in a shorter, neater,
less noisy fashion, that still behaved *as if* it was written in the
longer form.

sub f ($x, $y = 123, @z) { ... }

sub f {
@_ >= 1 or die "Too few arguments";
my $x = $_[0];
my $y = @_ > 1 ? $_[1] : 123;
my @z = @_[2..$#_];
...
}

Lately we've added the //= and ||= operators to signature syntax as
well to permit people to write in signatures what they'd often write
before as stuff like `my $y = $_[1] // 123;`.

Signatures were added in order to provide a short neat concise way for
the programmer to give a standard notation for various behaviours
around creating lexicals and inspecting @_ that *they were already
doing*. Signatures have become popular and well-used precisely because
they are just a neater way to rewrite existing code.

What does this mean for a "type system"? Again, it would do well to
check what existing behaviours people are actually writing now. Almost
universally, the kinds of code people are trying to clean up and
replace are variations on a theme of "Do I like this value?" when being
passed into subroutines or methods, stored in object fields, stored in
regular lexicals, that kind of thing. In effect, where subroutine
signatures tidied up code of the form such as `my $x = shift @_`, so
too should a value constraint system tidy up code of the form
`ACCEPTABLE($_[0]) or die "Cannot accept this argument"`.

Keep that in mind in the following.

## End-Goal Direction

This brings me on to my second point. Back in 2020, I wrote a blog post
that I turned into a presentation at a conference, "Perl in 2025",
where I imagined what kind of Perl code I might be writing five years
hence. Many of the points explained in that talk have set the direction
for things I have been actively working on since then. One I've not
really looked at until you bring it up here, is that "type system".

In my talk (https://www.youtube.com/watch?v=raSRNIoUYig), somewhere
around the 25m mark, I start classifying what various folks mean out of
"type systems". There's three main categories:

1. Static code checks
I.e. Can the compiler (perl -c) tell me "this program is bad"?

2. Dynamic value assertions
I.e. Does the program abort if I give it the wrong data?

3. Compiler hints
I.e. can the runtime run faster because it knows certain
conditions will be impossible?

These categories aren't mutually exclusive of course. For example, C's
type system is very much a mix of categories 1 and 3. TypeScript adds
a category 1 system to JavaScript, and Python also has some optional
typing stuff that again mostly fits category 1.

Perl is a very dynamic language - most of the things that you can do
would violate any sense of "static safety" that category 1 would
attempt to give. Perl isn't built for "performance above all else"
anyway, and category 3 would cut off many situations where we actually
like that flexibility - e.g. being able to use overloaded objects like
bigint, bigrat, String::Tagged, etc... in place of native values. Sure,
I agree that having to check for overloading makes code like `$x + $y`
run a bit slower than if you didn't have to check that, but being able
to transparently pass bigint or bigrat values into existing code and
operate on values larger than native platform IV or NV without losing
any precision at all is a great feature to have.

For these reasons, I feel that really only category 2 is the sort of
thing that is something we can, or should, add to Perl. This is why I
bring attention to the idea that we want to automate away the kinds of
"die if I don't like this value" code that people are already writing.
That's basically what category 2 already is, just manually written out
by hand. Whatever Perl might add in future should be an automation and
standardization of that existing style of code.

Furthermore, because I feel sufficiently strongly that this style of
dynamic value constraints at runtime is the best approach to be taking,
I have tried hard to avoid the word "type" when writing about or
describing it. I've said repeatedly and I'll say again: the whole
thing is verymuch "do we like the look of this value?". The key words
here are "look" and "value". It's about dynamic values that the program
actually operates on. It's about what they look like, not what their
underlying in-memory bit-pattern representation actually is.


# A Critique of Perl::Types

With these points in mind, we are now more prepared to take a closer
look at what your Perl::Types proposal suggests. Overall it's hard to
see what real behaviour is being added by the proposal as the details
in the email are very short. The CPAN dist has almost no code, no
tests, no documentation, so it's very hard for me to guess. I therefore
can't say with 100% certainty that what you propose doesn't fit what
I'm about to explain, but from an initial read of it I find it doubtful.

Perhaps, as a starting point, someone could outline what *kind* of type
system you imagine here, with particular reference to the three
categories I outline above. To what extent does what you propose fit
into each of categories 1, 2 or 3?

## An over-sensitivity to internal data representation

Your email talks about the difference between IVs, NVs and PVs and
honestly that is a tiny internal detail of representation waaay down in
the weeds. Perl - as a language and a culture - has never really cared
about whether a number is really a number, or a string containing some
digit characters to represent it in decimal form. 10 and "10" are mostly
the same thing. Sure, the bits stored in memory are different, but what
you can do with them is the same.

Many people use this to great advantage. For example, if you write a
commandline script that takes some sort of "count" argument, you're
probably going to parse it out of the text contained in the @ARGV
array. By nature that will have arrived as text, but that's OK - it's
Perl. As long as the value looks like a number, we can use it as a
number. It would be most un-Perlish to say that text in @ARGV has to be
converted into a pure-number form just to accept commandline
processing. That kind of conversion would be more at home in languages
such as Python, which make much stronger distinctions about numbers vs.
strings.

I don't see anywhere in your proposal where you account for this; a way
to specify "This value should be usable as if it was a number". Don't
forget things like bigint and bigrat exist and can be used as numbers.
Also when thinking about strings, objects can have overloading on them
to behave like strings ((not quite as well as we'd like currently in
Perl, but that's the subject of PPC0013)).

What I would like to see is something like this; where we imagine (for
sake of current argument) that "Numerical" is something that exists -
its actual nature still to be determined.

my Numerical $n;

$n = 10; # permitted
$n = "10"; # also permitted
$n = bigint->new("10"); # also permitted

$n = "hello"; # not permitted; throws some kind of
# exception at runtime

and of course we can apply those to fields, subroutine parameters,
etc.. in the hopefully-obvious way:

class Point {
field Numerical $x;
method move(Numerical $dX) { ... }
}

sub add(Numerical $x, Numerical $y) { ... }

In all of these cases, the ability to put a value constraint on a field
or parameter is really just a shortcut to writing some "check or die"
code manually. As I tried to hammer in above - this is just an
automation of the way that people can currently write these.

class Point { field Numerical $x; ... }
class Point { field $x; ADJUST { is_Numerical($x) or die "Bad x" }
... }

sub add(Numerical $x) { ... }
sub add($x) { is_Numerical($x) or die "Bad x"; ... }

Admittedly the one on plain lexicals isn't easy to write currently, but
it's possible via a little bit of Magic. It's something I may have a
hack at at some point soon.

## An under-sensitivity to particular values

The other thing that I feel is hugely missing from Perl::Types is
further constraints of values. Whereas I basically never care if a
numerical value is an IV, NV, PV, or some overloaded object or
whatever, what I do often care about is whether it is within some
numerical range. Perhaps it has to be positive. Or positive-or-zero. Or
maybe between two bounds - perhaps a percentage only goes up to 100, or
a mix ratio only goes up to 1.0.

And of course further constraints apply a lot more than just numbers.
Maybe for a string I'd constrain a certain length, or to match a
certain regexp pattern.. or object references have to be within a
certain subclass, or have some matching value for one of their fields,
or... whatever. Whatever Perl code I could have written in my
"IS_ACCEPTABLE($param) or die ..." expression, I should be able to
express in a value constraint. I don't currently see anything like
that in your proposal. That strikes me as a big missing feature.


# What Would I Suggest Instead?

I don't feel it very useful for me to write half a book's-worth of text
as a reply that basically says "no don't do that", without suggesting
something else more preferable instead. So I'm going to end this reply
with a quick look at something I'd much rather be considering.

The module Types::Standard seems to set a standard interface for
performing "constraint checks", that fulfils much of the behaviour I
describe above. It's well-known, well-used (via the Type::Tiny module),
and used by lots of people in lots of places.

As a general shape of model (i.e. true/false assertions on "do we like
this look of this value?") it seems far more aligned with the general
shape I outline above. I've even got as far as writing a little
Object::Pad field attribute module for using these check objects on
field assignments

https://metacpan.org/pod/Object::Pad::FieldAttr::Checked

class Point {
field $x :Checked(Num);
...
}

At some point I may get around to writing a similar attribute for
regular lexical variables. I was going to allow it to apply equally to
subroutine signatures, only I discovered Perl doesn't support those
yet. Hrm. Perhaps something for us to add in 5.39...

my $x :Checked(Num);

# not yet supported
sub add($x :Checked(Num)) { ... }

It's surely not perfect. For one, the syntax needs improving - these
kinds of constraints should be upfront syntax on the fields themselves:

class Point {
field Num $x;
}

my Num $x;

sub add(Num $x) { ... }

Performance-wise it could also be made a lot better. Currently every
checker is stored as a CV pointer, so performing a constraint check
involves an entire call_sv() operation. Internally that'd need a lot of
fixing before we'd consider it for core.

There's also the question of what really is the nature of something
like "Num" in the examples above. As the code currently stands, those
are regular Perl expressions that yield checker object instances at
compiletime, to be used to invoke a `->check` method at runtime. If we
had a truely native constraint-check syntax we'd most likely want to
define what a "check" really is as something more fundamental and new
than just that. It would likely want to operate purely in the C level
in most common cases, avoiding entirely any need for evaluating Perl
expressions just to check the common standard constraints.

But that's relatively small detail on the grand scheme of things.
Overall it's going in about the right direction, and any improvements
to it wouldn't fundamentally alter this shape; just make it better at
doing what it currently does.

What it does is very extensible to more parts of Perl, of course. Once
you have constraint checks that give you a "yes/no" answer and can use
them for accepting or rejecting values at assignment time into lexicals
or fields, or invocation time on function calls (see above examples),
you start to find you can go further than that.

A set of yes/no checks allows you to define multiple dispatch on
subroutines, for example:

check Triangluar :is(Shape) where { $_->points == 3 };
check Rectangular :is(Shape) where { $_->points == 4 };
check Pentagonal :is(Shape) where { $_->points == 5 };

multi sub draw(Triangular $shape) { ... }
multi sub draw(Rectangular $shape) { ... }
multi sub draw(Pentagonal $shape) { ... }

Or perhaps to take part in match/case syntax

match($shape : is) {
case(Triangular) { say "My shape has 3 sides" }
case(Rectangular) { say "My shape has 4 sides" }
...
}

In other words: Once you come up with a good shape for this kind of
thing, you find it's applicable in a lot more places than just
parameters to functions, or field assignments in objects. It's this
sort of force-multiplier that makes good components of languages - one
idea that can be reüsed in lots of different situations.

If people are going to spend their time making "some kind of type
system", the sort of structure I explained here is much more the kind
of thing I'd like to see people making. It has great potential to reüse
existing components, it easily fits into and improves the kind of code
people are already writing and have written for years. Straight away
people will be able to see where - and why - to use this new system.

Great languages are made like Lego kits: a collection of individual
pieces that are each simple to describe, but can be combined in lots of
flexible combinations. We should aim to make good bricks.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Sat, 19 Aug 2023 13:33:52 +0200, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> [...]
>
> If people are going to spend their time making "some kind of type
> system", the sort of structure I explained here is much more the kind
> of thing I'd like to see people making. It has great potential to re?se
> existing components, it easily fits into and improves the kind of code
> people are already writing and have written for years. Straight away
> people will be able to see where - and why - to use this new system.
>
> Great languages are made like Lego kits: a collection of individual
> pieces that are each simple to describe, but can be combined in lots of
> flexible combinations. We should aim to make good bricks.

Honestly this email should be in the perl core documentation.

--
With regards,
Christian Walde

On Sat, 19 Aug 2023 15:57:55 +0200
"Christian Walde" <walde.christian@gmail.com> wrote:

> > Great languages are made like Lego kits: a collection of individual
> > pieces that are each simple to describe, but can be combined in
> > lots of flexible combinations. We should aim to make good bricks.
>
> Honestly this email should be in the perl core documentation.

It's my tribute to the beginning of the R5RS spec, which begins:

"Programming languages should be designed not by piling feature on
top of feature, but by removing the weaknesses and restrictions that
make additional features appear necessary."

-- https://docs.racket-lang.org/r5rs/r5rs-std/r5rs-Z-H-3.html

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

Op 16-08-2023 om 09:19 schreef Ovid:
> Yves (demerphq) got right to the point with pointing out that Will's
> approach is extremely unlikely to work:
> https://github.com/orgs/Perl-Oshun/discussions/27#discussioncomment-6680632


I would say this is the main thing that needs addressing first. Until
this is cleared up, I think all other discussion is futile.


To rephrase shortly, Perl duck typing permeates every aspect of the
language, making the proposal unwieldy at best, but probably impossible
as it tries to use SVs in a very different way than they are used now.
But I may miss something obvious, or something very deep. So can anyone
explain why Perl::Types can work at all, and what changes to the
implementation of the language are needed for that?


HTH,

M4

On Mon, Aug 21, 2023 at 2:38?AM Martijn Lievaart via perl5-porters
<perl5-porters@perl.org> wrote:
>[...] But I may miss something obvious, or something very deep. So can anyone explain why Perl::Types can work at all, and what changes to the implementation of the language are needed for that?

For anything like Perl::Types to work in we're going to at a minimum
need to expand type annotation support, especially around subroutine
signatures.

Any Type system is going to want three things:

1) A way to annotate code with the types (e.g. `my Dog $fido`)
2) A way to assert the type (e.g. `my Dog $fido = Cat->new(); # dies
because Cats aren't Dogs `)
3) A way to define new types (e.g. `type Dog { $_ isa Dog }`)

#3 depends on #2 and #1, with Perl::Types you can just create a class
… how that mechanism works outside of RPerl is currently undefined. In
theory #2 is taken care of if all they're doing is exposing the
underlying SV subtypes. In practice people are arguing that's a
nonsensical thing to do, and ultimately there may need to be some work
there (there definitely is for Oshun style checks).

#1 however can't work without better support from Perl guts because
the mechanism that Perl::Types is currently using[1] will, as best
I've seen, only work on scalars (`my Child @children` doesn't trigger)
and will only work with explicit syntax like `(my Dog $fido, my Cat
$kitty) = @_` which is IMO painful enough I'd avoid using it. There is
also no support (yet) for subroutine signatures `sub (Dog $fido, Cat
$kitty, Child @children) { ... }`.[2]

-Chris

[1] Technically the mechanism that Perl::Types is _currently_ using
won't work at all. The fields pragma only kinda sorta does a check and
Perl::Types isn't even using that. The above is based on work I've
seen from others and replicated myself using Lexical::Types, which
exposes underlying XS APIs … but as far as I can tell those APIs only
exist for scalars, and it doesn't change the fact that `my ( Dog
$fido, Cat $boomer) = @_;` and `sub (Dog $fido, Cat $boomer) {...}`
are syntax errors.

[2] You can currently annotate a return type using a subroutine
attribute `sub adopt :returns(Dog) ($id) { ... }`. Implementing #2 on
subroutines is left as a lemma for the reader.

Op 21-08-2023 om 11:21 schreef Chris Prather:
> On Mon, Aug 21, 2023 at 2:38?AM Martijn Lievaart via perl5-porters
> <perl5-porters@perl.org> wrote:
>> [...] But I may miss something obvious, or something very deep. So can anyone explain why Perl::Types can work at all, and what changes to the implementation of the language are needed for that?
> For anything like Perl::Types to work in we're going to at a minimum
> need to expand type annotation support, especially around subroutine
> signatures.
>
> Any Type system is going to want three things:
>
> 1) A way to annotate code with the types (e.g. `my Dog $fido`)
> 2) A way to assert the type (e.g. `my Dog $fido = Cat->new(); # dies
> because Cats aren't Dogs `)
> 3) A way to define new types (e.g. `type Dog { $_ isa Dog }`)
>
> #3 depends on #2 and #1, with Perl::Types you can just create a class
> … how that mechanism works outside of RPerl is currently undefined. In
> theory #2 is taken care of if all they're doing is exposing the
> underlying SV subtypes. In practice people are arguing that's a
> nonsensical thing to do, and ultimately there may need to be some work
> there (there definitely is for Oshun style checks).


So basically you are implying #2 can work for classes (for Perl::Types),
because classes use SVs in a certain predictable way. But for anything
else, this will not work as exposing SVs will not do anything useful for
the context we are looking at, correct?


> #1 however can't work without better support from Perl guts because
> the mechanism that Perl::Types is currently using[1] will, as best
> I've seen, only work on scalars (`my Child @children` doesn't trigger)
> and will only work with explicit syntax like `(my Dog $fido, my Cat
> $kitty) = @_` which is IMO painful enough I'd avoid using it. There is
> also no support (yet) for subroutine signatures `sub (Dog $fido, Cat
> $kitty, Child @children) { ... }`.[2]


That more or less sounds like it is doable, so no big problems there
(although performance impact remains to be seen, obviously).


M4


> [2] You can currently annotate a return type using a subroutine
> attribute `sub adopt :returns(Dog) ($id) { ... }`. Implementing #2 on
> subroutines is left as a lemma for the reader.


:P

> On Aug 21, 2023, at 6:30 AM, Martijn Lievaart via perl5-porters <perl5-porters@perl.org> wrote:
> So basically you are implying #2 can work for classes (for Perl::Types), because classes use SVs in a certain predictable way. But for anything else, this will not work as exposing SVs will not do anything useful for the context we are looking at, correct?

Classes are a red-herring here, and kinda orthogonal. Specifically the APIs that things like Lexical::Types exposes simply don’t exist (as far as I could tell) for anything but scalars. It feels like we implemented just enough to make fields.pm work as a proof of concept and then moved on with our lives.

The reason that Perl::Types shouldn’t have any issue after this is that presumably once they know what type a variable is they can simply call SvIOK, SvNOK, or SvPOK …

Looking at RPerl, each type has a class associated with it so I would assume that there is some mechanism XS to perform the assertion that doesn’t use something like Variable::Magic.

I mean if you can solve the annotation problem, worst case scenario is that you implement a system like https://metacpan.org/pod/Object::Pad::FieldAttr::Checked to do the assertion on set and use the various Sv*OKs.

-Chris

> From: Dave Mitchell
> Date: August 19, 2023 07:40
> Subject: Re: PPC Elevator Pitch for Perl::Types
> Message ID: ZOBx23dmJJLPb3Cg@iabyn.com

> On Sat, Aug 19, 2023 at 02:56:13AM +0000, Oodler 577 via perl5-porters wrote:
> > Does that help answer your initial questions?

> 'fraid not :-)

Sorry, we'll keep trying our best to explain! ;-)

> If I am understanding correctly, Perl::Types is intended to be something
> which can be used stand-alone, independent of RPerl, and which you want to
> be bundled with the perl core.

Yes, that is absolutely correct.

> Within that context, how does adding 'use Perl::Types' at the top of a
> perl (not RPerl) program do its thing? What mechanism are you using that
> causes this line in a non-RPerl program to croak;

> my number $x;
> ...
> $x = 'foo'; # croak

> e.g. is it a source filter, set magic attached to $x, or ...?

Yes you are correct, the current mechanism for enabling type-checking
for subroutine calls is essentially a type of source filter. As
mentioned in our first reply:

> > The Perl compiler currently supports type enforcement for subroutine calls, so that is our starting point for Perl::Types.

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. Similarly, this functionality
will eventually be triggered by the line `use Perl::Types;` instead,
once we complete the refactoring of `Perl::Types` into its own
distribution.

You can see how the `TYPE_CHECKING` preprocessor directive is
handled, with minor differences between the `ON` and `TRACE`
settings:

https://metacpan.org/release/WBRASWELL/RPerl-7.000000/source/lib/RPerl/CompileUnit/Module/Class.pm#L673-715

```perl
if ( $CHECK eq 'ON' ) {
my $i = 0; # integer
foreach my $subroutine_argument ( @{$subroutine_arguments} ) {
# only enable type-checking for arguments of supported type;
# NEED UPGRADE: enable checking of user-defined Class types & all other remaining RPerl types
if (exists $TYPES_SUPPORTED->{$subroutine_argument->[0]}) {
$subroutine_arguments_check_code .= q{ rperltypes::} . $subroutine_argument->[0] . '_CHECK( $_[' . $i . '] );' . "\n"; # does work, hard-code all automatically-generated type-checking code to 'rperltypes::' namespace
}
$i++;
}

activate_subroutine_args_checking( $package_name, $subroutine_name, $subroutine_type, $subroutine_arguments_check_code, $module_filename_long );
$inside_subroutine = 0;
$subroutine_arguments_line = q{};
}
```

You can see that both `ON` and `TRACE` call `activate_subroutine_args_checking()`,
which is where the type-checking calls are inserted into a new subroutine,
that wraps around the original un-type-checked subroutine:

https://metacpan.org/release/WBRASWELL/RPerl-7.000000/source/lib/RPerl/CompileUnit/Module/Class.pm#L1016-1183

```perl
# re-define subroutine call to include type checking code; new header style
do
{
no strict;

# create unchecked symbol table entry for original subroutine
*{ $package_name . '::__UNCHECKED_' . $subroutine_name } = \&{ $package_name . '::' . $subroutine_name }; # short form, symbol table direct, not strict

# delete original symtab entry,
undef *{ $package_name . '::' . $subroutine_name };

# re-create new symtab entry pointing to checking code plus unchecked symtab entry
$subroutine_definition_code .=
'*' . $package_name . '::' . $subroutine_name . ' = sub { ' .
$subroutine_definition_diag_code .
($subroutine_arguments_check_code or "\n") .
' return ' . $package_name . '::__UNCHECKED_' . $subroutine_name . '(@ARG);' . "\n" . '};';

# create new checked symtab entries, for use by Exporter
$check_code_subroutine_name = $package_name . '::__CHECK_CODE_' . $subroutine_name;
$subroutine_definition_code .= "\n" . '*' . $package_name . '::__CHECKED_' . $subroutine_name . ' = \&' . $package_name . '::' . $subroutine_name . "\n" . ';';

$subroutine_definition_code .= "\n" . '*' . $check_code_subroutine_name . ' = sub {' . "\n" . ' my $retval ' . q{ =<<'EOF';} . "\n" . $subroutine_arguments_check_code . "\n" . 'EOF' . "\n" . '};' . "\n";
};

eval($subroutine_definition_code) or (RPerl::diag('ERROR ECOPR02, PRE-PROCESSOR: Possible failure to enable type checking for subroutine ' . $package_name . '::' . $subroutine_name . '(),' . "\n" . $EVAL_ERROR . "\n" . 'not croaking'));
if ($EVAL_ERROR) { croak 'ERROR ECOPR03, PRE-PROCESSOR: Failed to enable type checking for subroutine ' . $package_name . '::' . $subroutine_name . '(),' . "\n" . $EVAL_ERROR . "\n" . 'croaking'; }
```

Thus, any call to your example `mutate()` subroutine would actually
end up calling the new wrapper subroutine instead, which would
start off by type-checking the input argument(s) before proceeding
to run the original `mutate()` code. (As mentioned before, this
would require adding `( my number $my_arg ) = @ARG;` to the top of
`mutate()`, so that `activate_subroutine_args_checking()` knows to
insert a call to `number_CHECK()` or `number_CHECKTRACE()`.)

We can enable type-checking for the subroutine return values by
simply extending this same `activate_subroutine_args_checking()`
to include a call to the appropriate `foo_CHECK()` or `foo_CHECKTRACE()`
right before returning back to the original caller.

Regarding your `my number $x; $x = 'foo';` example, this will
require the use of a `tie` or similar mechanism to intercept every
modification of `$x`, inserting a call to `number_CHECK()` or
`number_CHECKTRACE()` as previously described. In the past, we
have always simply allowed the C(++) compiler to provide this
functionality for us; however, this will have to be explicitly
implemented when `Perl::Types` is refactored into its own distribution.
Arbitrarily-nested data structures (arrays and/or hashes) can be
recursively type-checked using the same `tie` approach, intercepting
any modifications to internal elements and calling `foo_CHECK()`
or `foo_CHECKTRACE()` for each change.

> Also, from your reply about my mutator example not croaking by default,
> this seems to imply that it's quite possible for $x to obtain a
> non-numeric value under some circumstances. So, by default, what
> circumstances will croak and which will silently allow $x to become
> something other than a number? E.g. which of these lines croaks?

> $x = 'foo';
> $x =~ s/1/a/;
> substr($x,0,1) = 'foo';
> my $y = substr($x,0,1);

Once the above-mentioned `tie` functionality is implemented, then
all four of the lines above would potentially give an error if
attempting to store a non-`number` value into the `number`-typed
`$x` variable.

> Just in general terms I'm still confused as to what effect adding
> 'Perl::Types' to my program will have, and how it achieves that effect.

If you set `TYPE_CHECKING` to `OFF` and don't use the Perl compiler,
then `use Perl::Types;` will not have any effect other than allowing
you to use the Perl data types (and their associated helper
subroutines), thereby improving the readability of your code.

If you set `TYPE_CHECKING` to `ON` or `TRACE` (default) and don't
use the Perl compiler, then `use Perl::Types;` will utilize the
source filter mechanism for type-checking errors on subroutine
entry and/or exit, and will also utilize the `tie` mechanism for
type-checking errors on variable modification, thereby improving
the correctness of your code.

If you set `TYPE_CHECKING` to `ON` or `TRACE` (default) and do use
the Perl compiler, then `use Perl::Types;` will utilize the C(++)
compiler for type-checking errors on subroutine entry and/or exit,
as well as variable modification, thereby improving the runtime
performance of your code.

So, as mentioned in the original Elevator Pitch, we can "utilize
Perl data types to achieve a number of benefits including but not
limited to":

* increased performance
* code correctness
* type safety (type checking)
* memory safety (bounds checking)
* documentation of code intent
* potential for polymorphism
* potential for derived or synthetic types

Currently, the Perl compiler has well over 4K individual test cases,
a large number of which relate to the Perl data type system. The
exact number of tests which will be moved from the Perl compiler
into `Perl::Types` will be determined when the refactoring process
is complete.

https://metacpan.org/release/WBRASWELL/RPerl-7.000000/source/t

https://metacpan.org/release/WBRASWELL/RPerl-7.000000/source/lib/RPerl/Test

Are we making progress toward answering your initial questions?

On Behalf of the _Perl::Types Committee_,
Brett Estrade

--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Tue, Aug 22, 2023 at 04:19:04AM +0000, Oodler 577 via perl5-porters wrote:
> Yes you are correct, the current mechanism for enabling type-checking
> for subroutine calls is essentially a type of source filter. As
> mentioned in our first reply:
>
> > > The Perl compiler currently supports type enforcement for subroutine calls, so that is our starting point for Perl::Types.
>
> This source-filter-like functionality is currently contained in
> the Perl compiler's file `Class.pm`

So just for the avoidance of doubt, is the proposal that Perl::Types,
when running in a perl (rather than RPerl) environment, will use perl's
actual source filter mechanism, or that it will use some other
"essentially a type of source filter" thing?

If the latter, please expand.

If the former, note that we generally regard the perl source filter
mechanism as deeply flawed, and wouldn't recommend its use in production
code. The basic problem comes down to the old mantra that "only perl can
parse Perl". A source filter may correctly parse the source 99.9% of the
time, but on those 0.1% occasions, it will get something wrong. Maybe it
will get the start of a // operator confused with the start of a pattern.
Or maybe it will trip over some complex code embeded into a pattern:
/...(?{ $x = '/'; }) .../. Or whatever. At that point, code will get
injected at the wrong point into the source, and the end user gets a
compile error from code that isn't even in their source, which is
completely mystifying and hard to debug.

Switch.pm used source filters, and it was the cause of an endless stream
of tickets. It was eventually deprecated and removed from core in 5.14.0.

> Regarding your `my number $x; $x = 'foo';` example, this will
> require the use of a `tie` or similar mechanism

Again, this is very vague. Do you actually mean perl's tie / magic
mechanism? If not, what "similar mechanism" are you proposing to use?

The problem with using actual ties, is that they make the variable very
slow, even if the actual tie methods such as FETCH() are XS code. That's
because a lot of code paths in the perl interpreter have optimisations for
non-magic values. For example, look at pp_add() in pp_hot.c in the perl
source. This implements perl's '+' operator. Obviously in general the two
operands can be anything - ints, ,nums, strings, magic values, overloaded
objects etc, and mixtures thereof. But in pp_add(), the first thing it
does it check the flags of the two operands, and says:

If they are both non magical and non ref, and if both are either
simple ints or simple nums, then just add the two values, check they
haven't overflowed, set the return value and return. Otherwise go
through the complex 200-lines-of-code path which handles magic, mixed
types etc.

So if, for example, an integer variable was marked with get magic, it
would become a lot slower when being added. Similar considerations apply
in many places.

Also, once tie magic starts being applied to arrays and hashes, you start
to hit edges cases. It's very had to make a tied aggregate behave *exactly*
like a plain array/hash in all circumstances, even ignoring the slowdown.

> So, as mentioned in the original Elevator Pitch, we can "utilize
> Perl data types to achieve a number of benefits including but not
> limited to":
>
> * increased performance

So how would you get increased performance? I've already pointed out that
magic tends to slow things down, and the cost of calling a check routine
will slow things down even further.

> * memory safety (bounds checking)

Can you give an example of where currently perl isn't memory safe, but
Perl::Types would make it so?

> * potential for polymorphism

Please explain further.

Ok, that was the technical side of things. Now on to the policy side.
20 years or so ago, perl went through a phase of adding lots of 'useful'
modules to the perl core. This was widely seen as a mistake.

First, it made a particular module seem to be officially endorsed.
Hypothetically, "among several XML parser modules, we chosen this one as
the best and the one you should use". When design flaws in XML::Parser
(say) are discovered, and the general recommendation is to use
XML::BetterParser instead, XML::Parser is still sitting in the perl core
getting an unfair endorsement. And removing it from core is hard, because
now lots of people used it, and they're using it because, well, we
endorsed it!

Second, if modules stop being actively maintained by their author(s) for
whatever reason, then suddenly we become responsible for maintaining it.
It's enough work just maintaining the core perl interpreter, without
taking on extra responsibilities.

Third, in these days of package managers etc, it's relatively easy for
people to install the CPAN modules they want. They will also get the
newest and best version by default, rather than using the old buggy version
bundled with perl. So there is less good reason to bundle a package with
perl.

So these days the policy is not to bundle CPAN modules with perl unless
they are necessary, usually because they are needed as part of the tool
chain. There have been very few new modules added to the perl core in the
last 15 years or so that are capable of acting as standalone CPAN
distributions instead.

So the short answer is that even if Perl::Types really appealed to us, it
is very unlikely that we would agree to bundle it. And I think we're
far from a consensus yet that it appeals.

On a purely individual note, I am finding Perl::Types very unappealing so
far.

--
I took leave and went to hear Mrs Turner's daughter play on the harpsicon,
but Lord, it was enough to make any man sick to hear her; yet I was forced
to commend her highly.
-- The Diary of Samuel Pepys, 1 May 1663

On Tue, Aug 22, 2023 at 12:03?PM Dave Mitchell <davem@iabyn.com> wrote:

> > Regarding your `my number $x; $x = 'foo';` example, this will
> > require the use of a `tie` or similar mechanism



> > * increased performance
>
> So how would you get increased performance? I've already pointed out that
> magic tends to slow things down, and the cost of calling a check routine
> will slow things down even further.
>

For some context: RPerl is a transpiler which converts a limited subset of
Perl-like syntax to C++ <https://news.ycombinator.com/item?id=18306458> and
then runs it at native speed.
integers and floats are "unboxed" and the native C++ code can run at
lightning fast speed.

Perl wasn't designed with software performance in mind and this often has
not been an issue. Much of our program overhead is I/O, network latency,
etc. When we get CPU-bound, however, we struggle. Perl's optimized well for
all sorts of crazy string manipulation and that was *perfect* for the early
web. In today's data-heavy world, along with AI, lots of math is needed and
Perl's not very fast at that.

It really is a problem with Perl and Perl adoption and I don't know how it
can easily solved.

But Perl was designed for *developer* efficiency and the Oshun data check
project leans into that, hard.

As a developer, I want to know that I can write this (hypothetical syntax,
but very similar to our actual code):

# 1. Passing in something that doesn't match a UUID is fatal.
# 2. Returning anything but an arrayref, or if that arrayref contains
# anything that is not an instance of My::Order, is fatal.
sub get_orders( uuid $uuid ) returns ARRAY[OBJECT[My::Order]] {
# within this scope, setting $uuid to any non-UUID value
# is fatal
my $customer = get_customer($uuid);
return $customer->orders;
}

We do not make promises of code performance. We make promises of developer
performance and data correctness. The amount of code you would have to
write to manually verify all of these assumptions is ridiculous, so many
developers skip that entirely.

We offer:

1. Working code (albeit alpha and NOT appropriate for production use)
2. Almost 200,000 passing tests
3. Documentation (though limited)
4. A full, draft spec which needs to be updated when we agree on syntax
5. We handle bad assignments to the variable well, but assignments deep
inside complex data structures are not handled because of performance. This
is a source of contention.
6. Trivial to downgrade data checks to warnings, or disable them for
performance
7. We have an open process where anyone is allowed to participate. I am
a doorman, not a gatekeepr.

When I say "developer performance" instead of "code performance," consider
the following C function:

#include <stdarg.h>

double get_average_temp(int n, ...)
{
double average = 0.0;
va_list ptr;
va_start(ptr, n);

for (int i = 0; i < n - 1; i++) {
average += va_arg(ptr, double);
}
va_end(ptr);

return average / (n - 1);
}

That takes a variadic list of doubles and computes the "average
temperature" for them. It's written in C, so type checks are done at
compile-time and then thrown out at runtime. Very fast for the computer.

For the developer, if those temperatures are accidentally a mixture of
Celcius and Fahrenheit, there will be no error. There will be no warning.
You might not notice something is wrong. This is not a theoretical
problem. This
is a $125 million problem
<https://www.wired.com/2010/11/1110mars-climate-observer-report/>.
(billions, maybe trilions, if you could count all the times this mistake
has been made).

So Oshun assumes we want correct code *first*. (The following assumes
celsius is a user-defined check):

sub get_average_temp(celsius @temps) returns celsius {
return Celsius->new( temp => sum0(@temps) / @temps );
}

Later, if you want polymorphism via multi subs, we *might* be able to
consider something like:

multi sub get_average_temp(celsius @temps) returns celsius {
return Celsius->new( temp => sum0(@temps) / @temps );
}
multi sub get_average_temp(fahrenheit @temps) returns fahrenheit {
return Fahrenheit->new( temp => sum0(@temps) / @temps );
}

But now we're dispatching on what the arguments mean, not just on primitive
value types without semantic content.

This is *Perl*. If you want CPU performance, you're not going to get it by
attaching a few labels on things. The RPerl transpiler approach literally
*cannot* work here. You can't have unboxed ints and floats flying around
perl's twisty-little maze of macros and even if you did, you lose the
*semantic* meaning of them. There's no such thing as a "4". It's "4 *of
something*" and that's what Oshun does.

I have no idea if the Oshun project will ever get accepted, either. While
the general syntax and intent seems favorable to many (because it fits what
Perl already does), the fact that it would be hard to make it performant
might be its death knell. And when that time comes, I'll point out that
these checks can be disabled for production, but if that's not enough, I
will accept that decision.

--
Curtis "Ovid" Poe
--
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/

* Dave Mitchell <davem@iabyn.com> [2023-08-22 11:02:53 +0100]:

First, thank you for the reply. I got to your conclusion and understand
your stance. I'd like to still address a few techincal things inline.

> On Tue, Aug 22, 2023 at 04:19:04AM +0000, Oodler 577 via perl5-porters wrote:
> > Yes you are correct, the current mechanism for enabling type-checking
> > for subroutine calls is essentially a type of source filter. As
> > mentioned in our first reply:
> >
> > > > The Perl compiler currently supports type enforcement for subroutine calls, so that is our starting point for Perl::Types.
> >
> > This source-filter-like functionality is currently contained in
> > the Perl compiler's file `Class.pm`
>
> So just for the avoidance of doubt, is the proposal that Perl::Types,
> when running in a perl (rather than RPerl) environment, will use perl's
> actual source filter mechanism, or that it will use some other
> "essentially a type of source filter" thing?

Yes, it uses a source filter to start. Lots of things use source filters,
just like lots of things other parts of Perl. Short of carrying along
patches to core, I am not sure how you would really hook into the process
here.

>
> If the latter, please expand.
>
> If the former, note that we generally regard the perl source filter
> mechanism as deeply flawed, and wouldn't recommend its use in production
> code. The basic problem comes down to the old mantra that "only perl can
> parse Perl". A source filter may correctly parse the source 99.9% of the
> time, but on those 0.1% occasions, it will get something wrong. Maybe it
> will get the start of a // operator confused with the start of a pattern.
> Or maybe it will trip over some complex code embeded into a pattern:
> /...(?{ $x = '/'; }) .../. Or whatever. At that point, code will get
> injected at the wrong point into the source, and the end user gets a
> compile error from code that isn't even in their source, which is
> completely mystifying and hard to debug.
>
> Switch.pm used source filters, and it was the cause of an endless stream
> of tickets. It was eventually deprecated and removed from core in 5.14.0.

Understood.

>
> > Regarding your `my number $x; $x = 'foo';` example, this will
> > require the use of a `tie` or similar mechanism
>
> Again, this is very vague. Do you actually mean perl's tie / magic
> mechanism? If not, what "similar mechanism" are you proposing to use?
>

It was an speculative answer to how we'd do something. It is not currently
possible so we simply do not know.

> The problem with using actual ties, is that they make the variable very
> slow, even if the actual tie methods such as FETCH() are XS code. That's

> because a lot of code paths in the perl interpreter have optimisations for
> non-magic values. For example, look at pp_add() in pp_hot.c in the perl
> source. This implements perl's '+' operator. Obviously in general the two
> operands can be anything - ints, ,nums, strings, magic values, overloaded
> objects etc, and mixtures thereof. But in pp_add(), the first thing it
> does it check the flags of the two operands, and says:
>
> If they are both non magical and non ref, and if both are either
> simple ints or simple nums, then just add the two values, check they
> haven't overflowed, set the return value and return. Otherwise go
> through the complex 200-lines-of-code path which handles magic, mixed
> types etc.
>
> So if, for example, an integer variable was marked with get magic, it
> would become a lot slower when being added. Similar considerations apply
> in many places.
>
> Also, once tie magic starts being applied to arrays and hashes, you start
> to hit edges cases. It's very had to make a tied aggregate behave *exactly*
> like a plain array/hash in all circumstances, even ignoring the slowdown.

Again, what recourse do we have? This is the mechanism by which perl gives
us ways to "implement" our own high level data types (SCALAR, HASH, ARRAY).

This is and the source filter being our only options to hook into fundamental
perl "things" is exactly the pain points we as a community need for there
to be some fundamental improvements in. Perhaps through this effort there
will be some motivation to add a more reliable stage that in the past was
only able to be achieved via filters. And with `tie`, it'd be super if there
was a "better" way to Tie there is not. This is a good role for core developers
to fill.

It is the role of the core development to provide proper programming interfaces
for external parties to propose improvements or integrations without dealing
with gobs of very tedious magic; Perl provides these things currently in 3
fundamental ways:

* source filters
* tie interfaces for SCALAR, ARRAY, HASH
* subroutine prototypes (which are IMO great for creating "keywords" UX)

We've asked before, and we will ask again: what mechanism would you suggest;
and if it doesn't exist or isn't mature enough, what changes would be required
to core to more cleanly/appropriately handle what it is we WANT to do here?
Hiring core developers and internal process people is not an option of us,
we're just volunteers like most, with limited time and zero money to throw at
this.

>
> > So, as mentioned in the original Elevator Pitch, we can "utilize
> > Perl data types to achieve a number of benefits including but not
> > limited to":
> >
> > * increased performance
>
> So how would you get increased performance? I've already pointed out that
> magic tends to slow things down, and the cost of calling a check routine
> will slow things down even further.

Performance increased for type checking because we're taking advantage of the
native type checking in the underlying C or C++, give the source filters enable
more or less a "source to source" translation in differing degrees. This is
in contrast to, e.g., creating a framework that simply allows one to apply
regular expressions all over the place. On one hand regexps are slow, on the
otherhand, we still submit - what options do we really have?

It is also important to get this out front, performance does matter; any costs
for setting up the types constraints should be able to be amortized over the
lifetime of the running program to justify its use. Just like one can make
a program run arbitrarily fast if it is not "correct", it can also become
unacceptibly slow if there is too much overhead in the set up. It's the same
trade off we all see every day in other programming projects. It's no different
here.

So performance is absolution a critical point to consider - be it the overhead
induced but the constraints or the benefits of using real (as in C or C++) based
types and checking, which is where this step actually belongs.

>
> > * memory safety (bounds checking)
>
> Can you give an example of where currently perl isn't memory safe, but
> Perl::Types would make it so?

Again, this leverages the underlying C or C++ data structures and capabilities
provided by these compilers and runtimes. It's all about passing it to
the right level. In our case, it is the fundamental C or C++ data type capabilities
present in the compiler and in their runtimes.

>
> > * potential for polymorphism
>
> Please explain further.

The same way it's facilitated everywhere, by dispatching on what the programmer
is passing into the function - in this case, based on real types.

>
> Ok, that was the technical side of things. Now on to the policy side.
> 20 years or so ago, perl went through a phase of adding lots of 'useful'
> modules to the perl core. This was widely seen as a mistake.
>
> First, it made a particular module seem to be officially endorsed.
> Hypothetically, "among several XML parser modules, we chosen this one as
> the best and the one you should use". When design flaws in XML::Parser
> (say) are discovered, and the general recommendation is to use
> XML::BetterParser instead, XML::Parser is still sitting in the perl core
> getting an unfair endorsement. And removing it from core is hard, because
> now lots of people used it, and they're using it because, well, we
> endorsed it!

Are you suggesting some prudence be applied in endorsing one thing over another?
What is the process in place for vetting such modules or subsystems? It is
a sticky situation, i.e., vouching for things.

>
> Second, if modules stop being actively maintained by their author(s) for
> whatever reason, then suddenly we become responsible for maintaining it.
> It's enough work just maintaining the core perl interpreter, without
> taking on extra responsibilities.

This is already an issue for a lot of things and for a lot of people, literally
anywhere in tech.

>
> Third, in these days of package managers etc, it's relatively easy for
> people to install the CPAN modules they want. They will also get the
> newest and best version by default, rather than using the old buggy version
> bundled with perl. So there is less good reason to bundle a package with
> perl.

This is a fair point.

>
> So these days the policy is not to bundle CPAN modules with perl unless
> they are necessary, usually because they are needed as part of the tool
> chain. There have been very few new modules added to the perl core in the
> last 15 years or so that are capable of acting as standalone CPAN
> distributions instead.

Fair enough. I'd like to ask, what recourse do we have to hook into the perl
interpreter in the way that we are, if not to use the limited options present
in perl? Criticizing source filters and any mention of tie is not fair because
that's all we have. The alternative is also not feasible or fair. So what
do you suggest we do here?

>
> So the short answer is that even if Perl::Types really appealed to us, it
> is very unlikely that we would agree to bundle it. And I think we're
> far from a consensus yet that it appeals.
>
> On a purely individual note, I am finding Perl::Types very unappealing so
> far.

Fair enough, thank you for your time in replying. What technical avenue would
you take if you were in our situation, knowing as much as you know and having
taken the time to understand what we are doing here? Like I said above, beyond
source filters and tie, perl doesn't give us many options that don't include
paying a core developer (or more) to incrementally work on the support necessary
to get this working "fast" or "reliably". Because at the end of the day, that's
what it is going to take - a way to work on both sides of the process in order
to simultaneously deliver an advanced Perl module that is unincumbered by the
traditional limitations and dirth of options to hook deeply into what magick
is happening inside of the perl interpreter. And keep in mind, your reply here
will not just help us.

Thank you again.

Cheers,
Brett

>
> --
> I took leave and went to hear Mrs Turner's daughter play on the harpsicon,
> but Lord, it was enough to make any man sick to hear her; yet I was forced
> to commend her highly.
> -- The Diary of Samuel Pepys, 1 May 1663

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Tue, Aug 22, 2023 at 9:48?AM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:

> Yes, it uses a source filter to start. Lots of things use source filters,
> just like lots of things other parts of Perl. Short of carrying along
> patches to core, I am not sure how you would really hook into the process
> here.
> ...
> Fair enough. I'd like to ask, what recourse do we have to hook into the
> perl
> interpreter in the way that we are, if not to use the limited options
> present
> in perl? Criticizing source filters and any mention of tie is not fair
> because
> that's all we have. The alternative is also not feasible or fair. So what
> do you suggest we do here?
>

I wonder if you are not aware of the keyword plugging system, available
since 5.14?
It's used extensively by modules like List::Keywords and Object::Pad as
ways to prototype new functionality that could eventually be brought into
core (and indeed some of it has been, e.g. via Corinna).

* Ovid <curtis.poe@gmail.com> [2023-08-22 16:10:00 +0200]:

> On Tue, Aug 22, 2023 at 12:03?PM Dave Mitchell <davem@iabyn.com> wrote:
>
> > > Regarding your `my number $x; $x = 'foo';` example, this will
> > > require the use of a `tie` or similar mechanism
>
> > > * increased performance
> >
> > So how would you get increased performance? I've already pointed out that
> > magic tends to slow things down, and the cost of calling a check routine
> > will slow things down even further.

We're going to continuing to do the best we can given we perl gives us only
so much access to internals on a higher level; and the fact that we don't
have "core" developers in our pocket or a monetary budget to speak of. We
our time and our zeal, outside of that we can only deal with the cards perl
gives us. I wish there were better ways to do this, which IMO is exactly
the kind of things any future perl work should entail. Giving us better and
more performant access to empower new and more powerful CPAN modules.

> >
>
> For some context: RPerl is a transpiler which converts a limited subset of
> Perl-like syntax to C++ <https://news.ycombinator.com/item?id=18306458> and
> then runs it at native speed.
> integers and floats are "unboxed" and the native C++ code can run at
> lightning fast speed.

Mostly True. RPerl is a real subset (R = "restricted"), not "Perl-like".
"Perl-like" is something like Qore(.org), which has actual threads
and REAL C++ data types. And really does look like Perl. I encourage
others to check it out, and always have. The only reason I don't use
it is because it's not the One True Interpreter^TM (and never will
be).

Will even has a full book for free, in PDF form on the website,

http://rperl.org/learning/

All for vaporware, tho.

>
> Perl wasn't designed with software performance in mind and this often has
> not been an issue. Much of our program overhead is I/O, network latency,
> etc. When we get CPU-bound, however, we struggle. Perl's optimized well for
> all sorts of crazy string manipulation and that was *perfect* for the early
> web. In today's data-heavy world, along with AI, lots of math is needed and
> Perl's not very fast at that.

I don't think it is fair to say what Perl was or was not designed
for performance; that's just not a reasonable thing to claim for
people who work on computers most of the day/night. But I know it
wasn't designed for exposing OpenMP, and this is a direction I am
leading and has a nice tie-in to Perl::Types.

Will is an absolute expert with the Perl API and I am far from it,
as much as one can be without being in some club (speaking of
gatekeeping).

I do have a lot of experience in both HPC and Perl, and can say
that Perl most definitly is an amazing driver for all kinds of
performance related things - yes, via C bindings, but also for a
lot of pure Perl things, provided you do the yoeman's work of
actually profiling with the excellent Devel::NYTProf toolset.

Perl's API is untapped by most, but that's shame and the real place
of most improvement would to make it easier to expose is in a mid-
level way; and I see Perl::Types in may ways as a good example
of this. There are many such benefits to building up support for
this underserved are (not pure Perl but not Perl API).

The fact PDL exists leads to your point. However, there is a
historical obsession with optimizing perl and perl code. Why does
Devel::NYTProf exist? While we can't say perl (lower "p") is intended
to complete with C in many cases, it is also demonstrably false
that there are constant attempts to optimize it out the ying-yang
for what it does, ruthlessly so. So rutheless that one can't even
ensure a "read only" operation on a SV/AV/HV is thread safe. That's
pretty extreme.

Performance refers to a lot of things. We all want fast and efficient
code, so please just stop trying to convince us that performance
is not an issue. That's simply false, I don't care what blog post
says it is not.

>
> It really is a problem with Perl and Perl adoption and I don't know how it
> can easily solved.
>
> But Perl was designed for *developer* efficiency and the Oshun data check
> project leans into that, hard.

Ironically, what you are doing is extremely similar to Ada's
approach, part of which is called "design by contract". Ada has
full specifications on that and it's done by actual language
designers on US tax payer's dime. It's not bad, just not novel. It
seems a first pass on understanding how to apply Ada's approach in
describing the kinds of constraints you wish to describe would be
well worth the effort - and maybe a few academic papers. Were you
aware that Oshun is heading decidely into a space that has been
well specified by Ada?

The last time I used Ada was in college, and it was for 1 semester.
It is an interesting languge, used even in real time systems like
avionics. So clearly it can be performant, but it also doens't have
the limitations perl does.

Anyway, I suggestion you suggest you call Oshun what it is, "design
by contract", not only would more people understand at what level
it sits; but it would assist in the internal and external designs
by the mountains of existing implementations and specifications.
It might be novel in Perl, but it is not novel.

>
> As a developer, I want to know that I can write this (hypothetical syntax,
> but very similar to our actual code):

DARPA funded a spate of "High Productivity Computing System"
languages in the 2000s, and it came up with some interesting results.
Some of them could apply to Perl, especially Chapel (originally
ZPL, Ada is something that influenced it).


https://www.lanl.gov/conferences/lacss/2008/slides/barrett.pdf
https://en.wikipedia.org/wiki/High_Productivity_Computing_Systems

Again, you should look up "design by contract" and Ada.

..snip

> We do not make promises of code performance. We make promises of developer
> performance and data correctness. The amount of code you would have to
> write to manually verify all of these assumptions is ridiculous, so many
> developers skip that entirely.

Ignoring actual performance unwise. I am not suggesting pre-mature
optimizing the tricky stuff, but the obvious stuff, yes. It also
immediately loses most of your potential users. So what's the point
in hedging AGAINST performance? Makes me think you're not really
serious.

>
> We offer:
>
> 1. Working code (albeit alpha and NOT appropriate for production use)
> 2. Almost 200,000 passing tests
> 3. Documentation (though limited)
> 4. A full, draft spec which needs to be updated when we agree on syntax
> 5. We handle bad assignments to the variable well, but assignments deep
> inside complex data structures are not handled because of performance. This
> is a source of contention.
> 6. Trivial to downgrade data checks to warnings, or disable them for
> performance

How is this not vaporware and somehow RPerl and Perl::Types is
getting sniped on the sidelines for being vapor? This is getting
stupid and we're both looking stupid.

> 7. We have an open process where anyone is allowed to participate. I am
> a doorman, not a gatekeepr.

We more structured, who cares. We have a gatekeeping process and
are formal. We'll build our in cathedral, you build your bazaar.

>
> When I say "developer performance" instead of "code performance," consider
> the following C function:

You keep saying "developer performance". See,

https://en.wikipedia.org/wiki/High_Productivity_Computing_Systems

And start talking about prior art, nothing you are doing is novel.
At least we don't make that claim.

I do think Chapel could really offer some ideas on how to extend
Perl in actual useful ways, but it's unrelated to your DbC efforts
(which btw do not conflict with Perl::Types, a point we've made).
Perhaps you can show where Perl::Types, as we've demonstrated would
conflict with Oshun. I am not suggesting they are directly composable,
but Perl::Types could definitely assist you where otherwise you'd
just be using regular expressions everywhere (behind some sugar,
of course).

>
> #include <stdarg.h>
>
> double get_average_temp(int n, ...)
> {
> double average = 0.0;
> va_list ptr;
> va_start(ptr, n);
>
> for (int i = 0; i < n - 1; i++) {
> average += va_arg(ptr, double);
> }
> va_end(ptr);
>
> return average / (n - 1);
> }
>
> That takes a variadic list of doubles and computes the "average

Because I had no idea and it seems "important",

variadic := it can take a varying number of arguments

> temperature" for them. It's written in C, so type checks are done at
> compile-time and then thrown out at runtime. Very fast for the computer.
>
> For the developer, if those temperatures are accidentally a mixture of
> Celcius and Fahrenheit, there will be no error. There will be no warning.
> You might not notice something is wrong. This is not a theoretical
> problem. This
> is a $125 million problem
> <https://www.wired.com/2010/11/1110mars-climate-observer-report/>.
> (billions, maybe trilions, if you could count all the times this mistake
> has been made).

I have no doubt lives and lots of money hinge on Perl, but I assure
you lives and a lot more dollars do hinge on Ada, as it is in
avionics and other real time control systems. DbC is a good thing,
and I don't believe Perl::Types steps in your wading pool here. It
sits lower, and the whole point of what we are doing is providing
a basis for things like DbC, rather than it being a way to apply
a bunch of regular expressions. If someone wants that, they can
integrate Validate::Tiny quite nicely into their project.

>
> So Oshun assumes we want correct code *first*. (The following assumes
> celsius is a user-defined check):
>
> sub get_average_temp(celsius @temps) returns celsius {
> return Celsius->new( temp => sum0(@temps) / @temps );
> }
>
> Later, if you want polymorphism via multi subs, we *might* be able to
> consider something like:
>
> multi sub get_average_temp(celsius @temps) returns celsius {
> return Celsius->new( temp => sum0(@temps) / @temps );
> }
> multi sub get_average_temp(fahrenheit @temps) returns fahrenheit {
> return Fahrenheit->new( temp => sum0(@temps) / @temps );
> }
>
> But now we're dispatching on what the arguments mean, not just on primitive
> value types without semantic content.
>
> This is *Perl*. If you want CPU performance, you're not going to get it by
> attaching a few labels on things. The RPerl transpiler approach literally
> *cannot* work here. You can't have unboxed ints and floats flying around
> perl's twisty-little maze of macros and even if you did, you lose the
> *semantic* meaning of them. There's no such thing as a "4". It's "4 *of
> something*" and that's what Oshun does.

The "R" in "RPerl" means "restricted". It is for people interested
in the tradeoff between leveraging a real type system (from underlying
C or C++) into their code for performance and type safety. It's
not and never was offered as a design by contract approach. It sits
lower than Oshun, and would benefit your project by giving you
access in a lot of cases to the underlying data structures in the
perl interpreter, both at compile time and at runtime - and varying
degress of abstraction from the high level perl SV/AV/HV to the
actual underlying C or C++ (particular in the case of C++ supported
objects and derived data types).

>
> I have no idea if the Oshun project will ever get accepted, either. While
> the general syntax and intent seems favorable to many (because it fits what
> Perl already does), the fact that it would be hard to make it performant
> might be its death knell. And when that time comes, I'll point out that
> these checks can be disabled for production, but if that's not enough, I
> will accept that decision.
>

It seems that the same barrier of entry exists for Oshun as
Perl::Types. They are different things.

Oshun is "Design by Contract" in Perl. Call it what it is. It'll
help you and anyone interested in it clarify the vision and actually
deliver. You can then focus on the UX of DbC and hedge the performance
but of it to whatever abstraction you're currently sitting atop - be
it regular expressions, something sane like Validate::Tiny, or even
Perl::Types.

Perl::Types provides access to real type systems in perl and below
in the C/C++ compilers. So it sits at a lower level and provides
some compelling access to internal data structures that are otherwise
the realm of witches, "high magic" as it is called.

One thing I will assert is Perl::Types and RPerl is about as much
vaporware as Oshun, so it would be benefit both projects to quit
this "vaporware" BS that your cheerleaders seems to be pushing on
here and on the darker depths of the internet echo chambers. It's not
helpful, and it is clearly not a majority position as evidenced by
the pushback they are receiving.

Cheers,
Brett

> --
> Curtis "Ovid" Poe
> --
> CTO, All Around the World
> World-class software development and consulting
> https://allaroundtheworld.fr/

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

* Karen Etheridge <perl@froods.org> [2023-08-22 10:43:23 -0700]:

> On Tue, Aug 22, 2023 at 9:48?AM Oodler 577 via perl5-porters <
> perl5-porters@perl.org> wrote:
>
> > Yes, it uses a source filter to start. Lots of things use source filters,
> > just like lots of things other parts of Perl. Short of carrying along
> > patches to core, I am not sure how you would really hook into the process
> > here.
> > ...
> > Fair enough. I'd like to ask, what recourse do we have to hook into the
> > perl
> > interpreter in the way that we are, if not to use the limited options
> > present
> > in perl? Criticizing source filters and any mention of tie is not fair
> > because
> > that's all we have. The alternative is also not feasible or fair. So what
> > do you suggest we do here?
> >
>
> I wonder if you are not aware of the keyword plugging system, available
> since 5.14?
> It's used extensively by modules like List::Keywords and Object::Pad as
> ways to prototype new functionality that could eventually be brought into
> core (and indeed some of it has been, e.g. via Corinna).

Thank you, we had not looked at this but will.

Cheers,
Brett

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Tue, 22 Aug 2023 18:45:44 +0000
Oodler 577 via perl5-porters <perl5-porters@perl.org> wrote:

> > I wonder if you are not aware of the keyword plugging system,
> > available since 5.14?
> > It's used extensively by modules like List::Keywords and
> > Object::Pad as ways to prototype new functionality that could
> > eventually be brought into core (and indeed some of it has been,
> > e.g. via Corinna).
>
> Thank you, we had not looked at this but will.

It's very powerful; particularly as exposed by XS::Parse::Keyword and
in some cases XS::Parse::Sublike.

With it I've been able to implement:

* async/await syntax
https://metacpan.org/pod/Future::AsyncAwait

* real object syntax
https://metacpan.org/pod/Object::Pad

* real try/catch syntax (that became core's feature 'try')
https://metacpan.org/pod/Syntax::Keyword::Try

* real match/case syntax
https://metacpan.org/pod/Syntax::Keyword::Match

All of these things are in use right now today in various real
systems, real companies actually using this lot for real production
work.

They all play together, because they're not silly "lets rewrite the
source code with a regexp" trickery; they're properly integrated into
the parser in a properly reëntrant way. E.g. observe the way you can
put a match/case inside a try/catch block in an `async method` of a
class. Of particular note I want to draw attention to the fact that
combining `async` from Future::AsyncAwait and `method` from Object::Pad
works just fine despite the fact that neither module knows about the
other. When I wrote about programming languages being like Lego sets,
this is precisely the sort of thing I mean.


In addition at Perl v5.38 we added another mechanism for defining new
infix operators; so now while we're getting rid of smartmatch we can
continue to experiment with better replacements for it.

https://metacpan.org/pod/Syntax::Operator::Equ

https://metacpan.org/pod/Syntax::Operator::Identical

https://metacpan.org/pod/Syntax::Operator::Matches

and again - these all play together just fine. You can use an `equ` or
`=:=` operator inside match/case inside try/catch inside ... I think my
point is clear here.

These are the core-supported mechanisms we've been using for the past
decade to experiment with new syntax and new ideas that we eventually
bring into the core language.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On 22.08.23 18:48, Oodler 577 via perl5-porters wrote:
> * Dave Mitchell <davem@iabyn.com> [2023-08-22 11:02:53 +0100]:
>
>>> So, as mentioned in the original Elevator Pitch, we can "utilize
>>> Perl data types to achieve a number of benefits including but not
>>> limited to":
>>>
>>> * increased performance
>>
>> So how would you get increased performance? I've already pointed out that
>> magic tends to slow things down, and the cost of calling a check routine
>> will slow things down even further.
>
> Performance increased for type checking

This reply makes no sense. The original claim was increased performance
*of the code*, not increased performance of *checking types*. And the
latter is trivially false: Perl currently does not have a type system,
so it "wastes" zero time on static checks. How can you increase the
performance of that?

> because we're taking advantage of the
> native type checking in the underlying C or C++,

Perl has no underlying C or C++, so how is that going to work? (Also,
C's type system is kind of terrible.)

Besides, pushing type checks into an underlying (or "target") language
is generally a bad idea: It means errors will be reported in terms of
the generated code, not the source syntax written by the programmer.

(Besides besides, C++ is not known for its compilation and type checking
speed.)

On Tue, 22 Aug 2023 20:43:03 +0200, Oodler 577 via perl5-porters <perl5-porters@perl.org> wrote:

> vaporware

ovid never used that word.

ovid merely pointed out the basic fact that you have provided no code that
is executable on the official perl distribution

if you have it, please provide



it is also notable that the non-functional code you DO have on CPAN
proposes to provide a string.pm which would violate PAUSE perms, as:

$ cpanm string
--> Working on string
Fetching http://www.cpan.org/authors/id/A/AB/ABERGMAN/types-0.05.tar.gz ... OK

something which you have steadfastly refused reply to in any fashion,
which makes one wonder

--
With regards,
Christian Walde

On Tue, Aug 22, 2023 at 8:43?PM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:

> Mostly True. RPerl is a real subset (R = "restricted"), not "Perl-like".
> "Perl-like" is something like Qore(.org), which has actual threads
> and REAL C++ data types. And really does look like Perl. I encourage
> others to check it out, and always have. The only reason I don't use
> it is because it's not the One True Interpreter^TM (and never will
> be).
>
> Will even has a full book for free, in PDF form on the website,
>
> http://rperl.org/learning/
>
> All for vaporware, tho.
>

No one said rperl is vaporware, I said Perl::Types is. If you don't believe
me, try running «perl -e'use Perl::Types; my integer $foo = "L"'»


> > It really is a problem with Perl and Perl adoption and I don't know how
> it
> > can easily solved.
> >
> > But Perl was designed for *developer* efficiency and the Oshun data check
> > project leans into that, hard.
>
> Ironically, what you are doing is extremely similar to Ada's
> approach, part of which is called "design by contract". Ada has
> full specifications on that and it's done by actual language
> designers on US tax payer's dime. It's not bad, just not novel. It
> seems a first pass on understanding how to apply Ada's approach in
> describing the kinds of constraints you wish to describe would be
> well worth the effort - and maybe a few academic papers. Were you
> aware that Oshun is heading decidely into a space that has been
> well specified by Ada?
>
> The last time I used Ada was in college, and it was for 1 semester.
> It is an interesting languge, used even in real time systems like
> avionics. So clearly it can be performant, but it also doens't have
> the limitations perl does.
>
> Anyway, I suggestion you suggest you call Oshun what it is, "design
> by contract", not only would more people understand at what level
> it sits; but it would assist in the internal and external designs
> by the mountains of existing implementations and specifications.
> It might be novel in Perl, but it is not novel.
>

No, Oshun is not design by contract. Design by contract is fundamentally
about checking code/transitions, not values.

Please stop acting like you're the one here to school people.

> We do not make promises of code performance. We make promises of developer
> > performance and data correctness. The amount of code you would have to
> > write to manually verify all of these assumptions is ridiculous, so many
> > developers skip that entirely.
>
> Ignoring actual performance unwise. I am not suggesting pre-mature
> optimizing the tricky stuff, but the obvious stuff, yes. It also
> immediately loses most of your potential users. So what's the point
> in hedging AGAINST performance? Makes me think you're not really
> serious.
>

Are you?

Leon

* Christian Walde <walde.christian@gmail.com> [2023-08-22 23:09:09 +0200]:

> On Tue, 22 Aug 2023 20:43:03 +0200, Oodler 577 via perl5-porters <perl5-porters@perl.org> wrote:
>
> > vaporware
>
> ovid never used that word.

I am going to take your word for it, but I believe this statement
is correct in the literal sense.

>
> ovid merely pointed out the basic fact that you have provided no code that
> is executable on the official perl distribution
>
> if you have it, please provide
>
>
>
> it is also notable that the non-functional code you DO have on CPAN
> proposes to provide a string.pm which would violate PAUSE perms, as:
>
> $ cpanm string
> --> Working on string
> Fetching http://www.cpan.org/authors/id/A/AB/ABERGMAN/types-0.05.tar.gz ... OK
>
> something which you have steadfastly refused reply to in any fashion,
> which makes one wonder

Have you inspected the source code of types.pm"?

It is a 21 year old CPAN squatter package that contains the following code:
( direct link, https://metacpan.org/dist/types/source/lib/types.pm):

Note via CPAN, types.pm provides:

* float in lib/types.pm
* int in lib/types.pm
* number in lib/types.pm
* string in lib/types.pm
* unknown in lib/types.pm

And the code, which is unfortunate:

package types;
...
package unknown;
our $dummy = 1;
package int;
our $dummy = 1;
sub check {
return 0 if($_[0] eq 'int' && ($_[1] ne 'number' && $_[1] ne 'int'));
return 1;
}
package float;
use base qw(int);
sub check {
return 0 if($_[1] eq 'string');
return 1;
}
our $dummy = 1;
package number;
use base qw(float);
sub check {
return 0 if($_[1] eq 'string');
return 1;
}
our $dummy = 1;
package string;
use base qw(number);
sub check { return 1};
1;
__END__

And that's just the facts. "Playing nice" with a clear case of CPAN squatting
is hard to do. What do you suggest the path forward is for this pickle?

Cheers,
Brett

>
> --
> With regards,
> Christian Walde

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Wed, 23 Aug 2023 00:02:18 +0200, Oodler 577 <oodler577@sdf-eu.org> wrote:

> * Christian Walde <walde.christian@gmail.com> [2023-08-22 23:09:09 +0200]:
>
>> On Tue, 22 Aug 2023 20:43:03 +0200, Oodler 577 via perl5-porters <perl5-porters@perl.org> wrote:
>>
>> > vaporware
>>
>> ovid never used that word.
>
> I am going to take your word for it

i believe it is important to only make accusations one has evidence for

>> ovid merely pointed out the basic fact that you have provided no code that
>> is executable on the official perl distribution
>>
>> if you have it, please provide
>>
>>
>>
>> it is also notable that the non-functional code you DO have on CPAN
>> proposes to provide a string.pm which would violate PAUSE perms, as:
>>
>> $ cpanm string
>> --> Working on string
>> Fetching http://www.cpan.org/authors/id/A/AB/ABERGMAN/types-0.05.tar.gz ... OK
>>
>> something which you have steadfastly refused reply to in any fashion,
>> which makes one wonder
>
> Have you inspected the source code of types.pm"?
>
> It is a 21 year old CPAN squatter package that contains the following code:
> ( direct link, https://metacpan.org/dist/types/source/lib/types.pm):
>
> Note via CPAN, types.pm provides:
>
> * float in lib/types.pm
> * int in lib/types.pm
> * number in lib/types.pm
> * string in lib/types.pm
> * unknown in lib/types.pm
>
> And the code, which is unfortunate:
>
> package types;
> ...
> package unknown;
> our $dummy = 1;
> package int;
> our $dummy = 1;
> sub check {
> return 0 if($_[0] eq 'int' && ($_[1] ne 'number' && $_[1] ne 'int'));
> return 1;
> }
> package float;
> use base qw(int);
> sub check {
> return 0 if($_[1] eq 'string');
> return 1;
> }
> our $dummy = 1;
> package number;
> use base qw(float);
> sub check {
> return 0 if($_[1] eq 'string');
> return 1;
> }
> our $dummy = 1;
> package string;
> use base qw(number);
> sub check { return 1};
> 1;
> __END__
>
> And that's just the facts. "Playing nice" with a clear case of CPAN squatting
> is hard to do. What do you suggest the path forward is for this pickle?

my time is too limited currently to work out suggestions on fixes and i know people already provided suggestions to you which would improve the proposal overall and also address this issue

i am here to provide questions and feedback

that said: is there a known pause policy regarding your identified behavior of squatting?

--
With regards,
Christian Walde

On Wed, Aug 23, 2023 at 12:22?AM Christian Walde <walde.christian@gmail.com>
wrote:

> that said: is there a known pause policy regarding your identified
> behavior of squatting?
>

«Perl reserves all lowercase namespaces for pragmas. That doesn't mean you
can't write a pragma, but you should get the blessing of p5p (
perl5-porters@perl.org).» [1]

So there is a contingency policy for namespaces like these, though I don't
think we've ever used it.

Leon

1:
https://pause.perl.org/pause/query?ACTION=pause_namingmodules#All_lowercase_name

* Leon Timmermans <fawaka@gmail.com> [2023-08-22 23:55:09 +0200]:

> On Tue, Aug 22, 2023 at 8:43?PM Oodler 577 via perl5-porters <
> perl5-porters@perl.org> wrote:
>
> > Mostly True. RPerl is a real subset (R = "restricted"), not "Perl-like".
> > "Perl-like" is something like Qore(.org), which has actual threads
> > and REAL C++ data types. And really does look like Perl. I encourage
> > others to check it out, and always have. The only reason I don't use
> > it is because it's not the One True Interpreter^TM (and never will
> > be).
> >
> > Will even has a full book for free, in PDF form on the website,
> >
> > http://rperl.org/learning/
> >
> > All for vaporware, tho.
> >
>
> No one said rperl is vaporware, I said Perl::Types is. If you don't believe
> me, try running ?perl -e'use Perl::Types; my integer $foo = "L"'?

We're are in the process of extracting it from RPerl. So what.

>
>
> > > It really is a problem with Perl and Perl adoption and I don't know how
> > it
> > > can easily solved.
> > >
> > > But Perl was designed for *developer* efficiency and the Oshun data check
> > > project leans into that, hard.
> >
> > Ironically, what you are doing is extremely similar to Ada's
> > approach, part of which is called "design by contract". Ada has
> > full specifications on that and it's done by actual language
> > designers on US tax payer's dime. It's not bad, just not novel. It
> > seems a first pass on understanding how to apply Ada's approach in
> > describing the kinds of constraints you wish to describe would be
> > well worth the effort - and maybe a few academic papers. Were you
> > aware that Oshun is heading decidely into a space that has been
> > well specified by Ada?
> >
> > The last time I used Ada was in college, and it was for 1 semester.
> > It is an interesting languge, used even in real time systems like
> > avionics. So clearly it can be performant, but it also doens't have
> > the limitations perl does.
> >
> > Anyway, I suggestion you suggest you call Oshun what it is, "design
> > by contract", not only would more people understand at what level
> > it sits; but it would assist in the internal and external designs
> > by the mountains of existing implementations and specifications.
> > It might be novel in Perl, but it is not novel.
> >
>
> No, Oshun is not design by contract. Design by contract is fundamentally
> about checking code/transitions, not values.
>

Nobody actually knows what Oshun is proposing yet, even at this year's
TPFC, Curtis was still admittedly in the design phase. This is also indicated
by the nature of the discussion. I am not sure a specification even exists.

FWIW, I found this module linked on the Wikipedia page for DsC, which is from
the early 2000s. It is by Damian and I assume is an apple that falls not
far from the tree. Though Oshun is decidedly declarative, I suspect this
very old and experimental (looking) module might serve as some yard stick
to see if once a spec is fleshed out, how much DbC we can say it is.

https://metacpan.org/pod/Class::Contract#A-complete-example

Regardless, look at the Ada standard for declaring DbC and constraints on
data types and objects. This is what originally lead me to even see that it
might be called DbC. Best you can probably assert is that it's not DbC because
the spec is not on a firm foundation and it can't yet be determined.

It's not a bad thing Oshun is still in the design phase. But it also can't be
used to beat Perl::Types over the head because Perl::Types is a real thing (yes
currently tied to RPerl) and Oshun is not. It's also apples and oranges. I've
aleady linked the code in the RPerl. It's real enough that we are getting real
feedback outside of this thread, which I do very much appreciate.

So all y'all just need to stop gaslighting people into saying Perl::Types is
vaporware. Because this is the word that is being used, like I said in dark
echo chambers of ther perl-verse.

Cheers,
Brett

> Please stop acting like you're the one here to school people.
>
> > We do not make promises of code performance. We make promises of developer
> > > performance and data correctness. The amount of code you would have to
> > > write to manually verify all of these assumptions is ridiculous, so many
> > > developers skip that entirely.
> >
> > Ignoring actual performance unwise. I am not suggesting pre-mature
> > optimizing the tricky stuff, but the obvious stuff, yes. It also
> > immediately loses most of your potential users. So what's the point
> > in hedging AGAINST performance? Makes me think you're not really
> > serious.
> >
>
> Are you?
>
> Leon

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

* Leon Timmermans <fawaka@gmail.com> [2023-08-23 00:29:39 +0200]:

> On Wed, Aug 23, 2023 at 12:22?AM Christian Walde <walde.christian@gmail.com>
> wrote:
>
> > that said: is there a known pause policy regarding your identified
> > behavior of squatting?
> >
>
> ?Perl reserves all lowercase namespaces for pragmas. That doesn't mean you
> can't write a pragma, but you should get the blessing of p5p (
> perl5-porters@perl.org).? [1]

Or as it were, for 21 years, PAUSE.

>
> So there is a contingency policy for namespaces like these, though I don't
> think we've ever used it.
>
> Leon
>
> 1:
> https://pause.perl.org/pause/query?ACTION=pause_namingmodules#All_lowercase_name

Sure let me know when you do something about types.pm.

Cheers,
Brett

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Wed, 23 Aug 2023 00:37:20 +0200, Oodler 577 <oodler577@sdf-eu.org> wrote:

> * Leon Timmermans <fawaka@gmail.com> [2023-08-23 00:29:39 +0200]:
>
>> On Wed, Aug 23, 2023 at 12:22?AM Christian Walde <walde.christian@gmail.com>
>> wrote:
>>
>> > that said: is there a known pause policy regarding your identified
>> > behavior of squatting?
>>
>> ?Perl reserves all lowercase namespaces for pragmas. That doesn't mean you
>> can't write a pragma, but you should get the blessing of p5p (
>> perl5-porters@perl.org).? [1]

that is a quite different thing from a squatting policy, but very applicable here, thanks leon :)

> Or as it were, for 21 years, PAUSE.

what does this mean?

>> So there is a contingency policy for namespaces like these, though I don't
>> think we've ever used it.
>
> Sure let me know when you do something about types.pm.

the order of operations here is somewhat different

optimally you would've presented a proposal, gained concensus on it, and with agreement have uploaded a distribution to CPAN, thus grabbing the namespaces will did already grab ( https://pause.perl.org/pause/authenquery?ACTION=peek_perms&pause99_peek_perms_by=a&pause99_peek_perms_query=wbraswell&pause99_peek_perms_sub=Submit )

(you did not do that, you just grabbed them without asking anyone)

then, as well with said concensus, contacted pause admins to enact said concensus on the permissions of items conflicting with yours

if you are asking for pre-concensus unilateral action, then your perl-types dist would currently also be a target

otherwise you will need to ask for this to be enacted, and once concensus has given the go-ahead, you will receive the appropriate replies

--
With regards,
Christian Walde

On Tue, Aug 22, 2023 at 5:34?PM Oodler 577 via perl5-porters
<perl5-porters@perl.org> wrote:
>
> Nobody actually knows what Oshun is proposing yet, even at this year's
> TPFC, Curtis was still admittedly in the design phase. This is also indicated
> by the nature of the discussion. I am not sure a specification even exists.
>

Pardon me for asking, but are you calling Curtis a liar? Otherwise, I
must assume you are behind on your emails as I was able to find, only
slightly upthread, where Curtis says:

> We offer:
> [...]
> A full, draft spec which needs to be updated when we agree on syntax

After a brief conversation with a web-search tool about "perl Oshun
specification", I was quickly reading:

https://github.com/Perl-Apollo/oshun/blob/main/lib/Data/Checks/Specification.pod

What sort of research did you do before making the above statement?

I ask because you have recently reminded us of our responsibilities
toward quality of discourse, here on p5p.

> FWIW, I found this module linked on the Wikipedia page for DsC, which is from

Thanks.