[replies snipped and summarized below] Thanks for all the feedback so far. What I’ve done is create a new project in the Moose repository under the “MooseX-Types-Dependent” namespace where I’ve placed an updated versions of the specification document/idea scratchpad. I don’t know if in the end this will be the best namespace, but it’s a place to put stuff for now.
David, I’ve tried to digest your thoughts and update my ideas about what the different options would be. Since you seem to be very knowledgeable I would appreciate if you could take a look and let me know if you think it’s heading in the correct direction. Here’s a link: http://code2.0beta.co.uk/moose/svnweb/index.cgi/moose/view/MooseX-Types-Dependent/project-management/specification.pod Stevan, I went and did some reading about dependent types. Right now I’m reading about some extensions to ML for dependent types but would appreciate it if you had some links/research papers or other thoughts that could help me get up to speed. I initially have a few question based on feedback I’ve gotten so far, as well as question about how this might overlap or integrate with some other similar projects, such as the Structured Types stuff I am working on and of course how this might fight into what’s going on in MooseX::Method::Signatures, since my understanding is that work going on there will overlap with this type stuff. I guess off the top I am wondering what you might think is the relationship between the Structure Types stuff and dependent types. From my reading so far there appears to be a lot of overlap conceptually. Right no in the repository I have a version of Structured types that will support stuff like: ## Matches [1, 2, {key=>’val1_1’, key2=>’val_2’}] subtype MySpecialArrayRef, as Tuple[Int, Int, HashRef[Str]]; ## Matches [[1,2,3],[4,5,6]] subtype EqualArrayRefs, as Tuple[ArrayRef[Int],ArrayRef[Int], where { $#{$_->[0]} == $#{$_->[1]} }; ## Matches {name=>’John’, age=>39} subtype PersonalInfo, as Dict[name=>Str, age=>Int]; Just FYI, this is currently dependent on the repo version of Moose and MooseX::TypeLibrary, so if you want to play with this, you’ll need to have those in your PerlLib path. The above examples are pretty similar to some you’ll see in the test suite for MooseX-Types-Structured. So for me there is a clear distinction since the Structured type stuff is similar to the Parameterized stuff but just greatly extended, while what I am trying do do here is just extend our ability to hint types. For example, something like: #Matches 'abcde' but not 'abc' subtype AtLeastFive, as Str[MinLength=>5]; Right not I am not sure how syntax wise these hints would play with the current parameterized types or the repo structured types. Maybe something like: subtype Combo, as HashRef[Str, {MinValues=>2}]; Where if the last element in the array is a hashref, that would mean the contained values are hints. Anyway, it may be a bit early to be thinking about syntax. Thoughts about how these project might or might not overlap would be appreciated. A question about constant types. Duncan, you mentioned that the 'EqualsTo' hint would basically be making the type a constant (although they wouldn't be exactly usable as normal constants since they'd stringify to their type registry name, not their value). I've done: package MyApp::Constants; use Sub::Exporter -setup => { exports => [ qw(NAME) ]}; use constant NAME=>'john'; ... package MyApp::Types; use MyApp::Constants qw(NAME); subtype AuthorName as Str, where {$_ eq NAME}; Enough to consider if some tighter integration between types and constants might be warranted. The above is fine in terms of separation of concerns, but doesn't provide the type of meta data about the nature of the constraint to anyone using it that I'd like to give. I also thought some sort of locking ability, maybe based on Data::Lock would be useful, but maybe that's a clear case of a MooseX::Attribute instead of a type. Thoughts? One of the things I was thinking is that it might be nice if the 'where' clause could have some ability to introspect the type it's attached to. I don't know if there is a good theoretical reason to avoid this, and I realize it would raise some compatibility issues but might give you some flexibility in constructing subtypes in a more modular manner. Related to this is the idea that my type structures could in some way be chained together. I think we need something like this for the method body signature work, since I've been told I need to be able to create a constraint like: [Object, name=>Str, age=>Int, HashRef] which is supposed to match: [$obj, name=>John, age=>39, \%opts] Right now the Tuple constraint in MooseX::Types::Structured can't support this since each constraint in the structure is stand alone. What I need is a sort of 'next' statement in type constraints. That way I can do something like (totally contrived syntax): Tuple[Object[next=>Dict[name=>Str, age=>Int, {next=>HashRef}]]] That would work and we could probably make something like: Chained[Int, Dict[name=>Str, age=>Int], HashRef] To make the syntax cleaner. I guess we'd also like: Merged[Dict[name=>Str, age=>Int],Dict[friends=>Object]] Duncan, I had a few questions specifically to your comments: > Precision > Scale These have a problem of being, on the face of it, radix-specific. You should generalize those into versions that also have radix parameters, where 2 and 10 are likely the most common values; or maybe you already had a radix parameter in mind. So I added a Base hint for Num. The intended usage is something like: subtype as Num[Base=>10, Precision=>xxx, Scale=>yyy] With the goal of constraining a number. I lifted this from the SQL types. Let me know if you think I am understanding your comment correctly. So, would like thoughts on all the above and any review of the updated sketch in the repository would be appreciated. Repository Link: http://code2.0beta.co.uk/moose/svnweb/index.cgi/moose/browse/MooseX-Types-Dependent/ Sincerely, John Napiorkowski
