Roadmap

[happy-barney]

Summary what we want now, what later

Milestone 1 - MVP

• data validation on assignment - :of
• data validation on sub return - :returns
• primitive checks - eg, Int',Str, Undef`, ...
• independent symbol space

Milestone 2

• user defined checks
• export/import checks

Assorted features

• checks on expressions
• performance optimizations
• check utils
• Void subs

[zmughal]

independent symbol space

I agree with this in particular and it would side-step some of the concerns about naming. Do we want to continue discussion of that here or in a different discussion? I was thinking that the types would have fully-qualified names just like things stored in the stash.

export/import checks

Damian's spec also says that user-defined checks would be lexical and can be imported into other lexical scopes if marked as :export, but this is not yet implemented in Data::Checks.

primitive checks - eg, Int',Str, Undef`, ...

performance optimizations

Combining some ideas from both of these points together, why not create checks that use faster low-level checks like:

# Perl internals.
check B::Checks::IV              :isa(DEF) { B::svref_2object(\ $_ )->FLAGS & B::SVf_IOK    };
check B::Checks::UV              :isa(DEF) { B::svref_2object(\ $_ )->FLAGS & B::SVf_IVisUV };

# Any string that looks like a decimal integer in the mathematical sense and could be
# stored in a bigint.
check Data::Checks::INT_LIKE     :isa(STR[/^[1-9][0-9]*$/]);

# Union of the above.
check Data::Checks::INT          :isa(IV | UV | INT_LIKE); 

I'm hoping an approach like this will allow the checks themselves to be thought of as rules that can be reasoned about (by both the developer and tools that may do more advanced checking outside of the core).

[happy-barney]

Re: independent symbol space

I'm preparing spec for this, but little bit more generic, eg also make it usable for attributes and for my project Context::Singleton.
Re INT_LIKE example - Oshun should prohibit regex without qr . as well as it should accept all radix versions (operating on mindset that Oshun will be usable also to validate input data (eg POST request)

[zmughal]

performance optimizations

This is for waaay down the line, but has to do with Cor and how it can interact with types for method dispatch. If certain methods / classes are declared as {static, final, sealed} (various terminology in other languages), then the method dispatch can be known at compile time. An implementation of this idea exists on CPAN as:

• https://metacpan.org/pod/sealed,
  https://www.sunstarsys.com/essays/perl7-sealed-lexicals.

Though even in the absence of that, there are other techniques (though this gets too much into implementation details)...

---

More references for other langauges:

• Smalltalk
  • https://en.wikipedia.org/wiki/Inline_caching
  • https://bernsteinbear.com/blog/inline-caching/
• Dylan
  • https://docs.opendylan.org/books/drm/Sealing_Overview
• Swift:
  • https://github.com/apple/swift/blob/main/docs/OptimizationTips.rst#reducing-dynamic-dispatch
  • https://www.cleevio.com/blog/static-dispatch-swift
• Ruby
  • https://dl.acm.org/doi/10.1145/3486606.3486781
• General
  • https://www.unibw.de/ucsrl/pubs/thesis.pdf
  • https://www.complang.tuwien.ac.at/kps09/pdfs/brunthaler.pdf
  • https://arxiv.org/abs/2109.02958

[happy-barney]

that's why I it only under Assorted features :-)

It has multiple layers

• optimize check execution time
• reduce unnecessary calls
  • eg my $foo :contract (Foo) = ...; my $bar :contract (Foo) = $foo -> $bar is assigned without executing Foo
• partial execution - run only related part (that's one of motivations why I favour fine tuned flexible declarative approach instead of brutal-force where