Zbigniew Lukasiak wrote [privately]:
On Wed, Apr 29, 2009 at 10:28 PM, Darren Duncan <dar...@darrenduncan.net> wrote:
Zbigniew Lukasiak wrote:
It seems that in the Moose terminology a Type is just a constraint
with a name. This is different from other languages where the type of
a value does not change in time or in relation to the whole system.
You can copy the value and be sure that the copy has the same type you
can wait and check the value after some time and it's type would not
change, but if a value type is defined by it passing a constraint -
then these invariants do not hold. For example think about a
constraint that checks if a date is in the past.
This is not to criticise this - I understand that it is just a
practical solution - I just want to know if there is a consensus that
it is OK to write Moose types like DateInThePast.
In some languages a type is mostly just a named set of values, and so it is
valid for the same value to belong to more than one type. You see this in
Perl 6 for example; when you define a subtype (eg, UInt is subtype of Int
where ...) or a union type (eg, Scalar is union of Num|Str etc) values
falling under those still belong to their original types but also to the new
ones. That said, even in those cases a value would still have just a single
"root type", which is the type whose declaration allowed you to select (or
"construct") that value in the first place, and any other types would not be
re-introducing the value but just using it. -- Darren Duncan
Hmm - sorry but I don't understand. I was writing about the fact
that a value at one point can pass a particular TypeConstraint - and a
second later the same TypeConstraint on the same value can fail. This
seems to me very different from the way types are used in any other
language - where if a value is of a particular type then it always
will. There was nothing about subtypes in my question - only about
invariants.
Let me clarify, I do believe that all types are / should be invariant. I
believe that a type system is / should be pure and deterministic, and that what
values are part of a type can not change except by changing the program source
code that is the type's definition. So anything that is impure, including
testing what the current date is at runtime, can't / shouldn't be allowed in a
type definition. In other words, there can't / shouldn't be a type or
TypeConstraint called DateInThePast; rather, DateInThePast should be a
constraint applied at variable assignment time, associated with the variable and
not a type. The only thing that should be allowable as a TypeConstraint like
this is, for example, DateBefore2009April, and even that is probably a bad
design, but it is at least pure, and/but I would never do it. But better yet,
keep the TypeConstraint to just be eg "Date", which is invariant. -- Darren Duncan
