TSa wrote:
IOW, I fear this could only be put to work with two subset
declarations
subset ab of Str where /^a.*b$/;
subset aabb of ab where /^aa.*bb$/;
and the notion that the second subset by virtue of constraining
the possible values further produces a more specific subtype for
dispatch
HaloO,
Jonathan Lang wrote:
At its core, a type is nothing more than a constraint on the objects
that a given variable is allowed to handle; this would put C
clauses at the center of the type system, with roles coming in a very
close second due to the implicit use of ".does()" in the compact
syn
HaloO,
Jonathan Lang wrote:
Larry Wall wrote:
But I'm still somewhat set against the notion of using logical ops to
do set theory. (Even if you put parens around them.)
Understandably so. Perhaps "(u)" and "(n)" would be better ASCII
equivalents for the union and intersection operators...
On Saturday 28 October 2006 09:15, Larry Wall wrote:
> My initial inclination is to say that "where" clauses in a signature
> are only there for pattern matching, and do not modify the official
> type of the parameter within the function body. However, on a "subset"
> the "where" clause is there
Larry Wall wrote:
But I'm still somewhat set against the notion of using logical ops to
do set theory. (Even if you put parens around them.)
Understandably so. Perhaps "(u)" and "(n)" would be better ASCII
equivalents for the union and intersection operators...
--
Jonathan "Dataweaver" Lang
Trey Harris wrote:
Trey Harris writes:
> chromatic writes:
>> When you specify a type to constrain some operation, you specify that the
>> target entity must perform that role.
>
> That statement is very concise and direct. If the fuzziness I observed about
> the identity of the basic building bl
On Thu, Oct 26, 2006 at 03:17:27PM +0200, TSa wrote:
: HaloO,
:
: I wrote:
: >2) We have A&B and the A B juxtaposition to mean $_ ~~ A && $_ ~~ B
: > which is an intersection (sub)type of A and B.
:
: Is the A&B form a legal alternative for the juxtaposition?
Not in a signature. It's ambiguou
My initial inclination is to say that "where" clauses in a signature
are only there for pattern matching, and do not modify the official
type of the parameter within the function body. However, on a "subset"
the "where" clause is there precisely to contribute to the typing,
so if you want the extr
In a message dated Sat, 28 Oct 2006, Trey Harris writes:
In a message dated Sat, 28 Oct 2006, chromatic writes:
When you specify a type to constrain some operation, you specify that the
target entity must perform that role.
That statement is very concise and direct. If the fuzziness I observe
In a message dated Sat, 28 Oct 2006, chromatic writes:
When you specify a type to constrain some operation, you specify that
the target entity must perform that role.
That statement is very concise and direct. If the fuzziness I observed
about the identity of the basic building block of type w
On Wednesday 25 October 2006 03:04, Trey Harris wrote:
> I'll let @Larry speak for @Larry, but at one point I was told that when
> C or C appear in signatures, those are roles, not classes; if
> you examined a particular Array or Hash, the class would be some
> implementation of the Array or Hash
HaloO,
I wrote:
2) We have A&B and the A B juxtaposition to mean $_ ~~ A && $_ ~~ B
which is an intersection (sub)type of A and B.
Is the A&B form a legal alternative for the juxtaposition?
--
HaloO,
Jonathan Lang wrote:
2) We have A&B and the A B juxtaposition to mean $_ ~~ A && $_ ~~ B
which is an intersection (sub)type of A and B.
Not according to my reading of S06: if you want to force a parameter
to match both of two different roles, you must use a where clause.
In sectio
TSa wrote:
I want to summarize what we have so far.
1) In type constraint position we can say things like A|B to effectively
mean a supertype of A and B by virtue of $_ ~~ A || $_ ~~ B.
Right. This would be equivalent to "Any where {.does(A) or .does(B)}".
2) We have A&B and the A B jux
HaloO,
Trey Harris wrote:
In other words, I agree that it's fuzzy, but I personally read the
fuziness as intentional, so as to allow implementations flexibility and
prevent bad dependencies on particular "inner workings" of the type system.
Thanks for the support. I figured that I've asked th
In a message dated Wed, 25 Oct 2006, TSa writes:
from the recent threads 'class interface of roles', 'set operations for
roles' and 'signature subtyping and role merging' I wonder how typish
roles actually are. Some seem to consider roles as lightweight particles
that serve to compose classes.
HaloO,
from the recent threads 'class interface of roles',
'set operations for roles' and 'signature subtyping
and role merging' I wonder how typish roles actually
are. Some seem to consider roles as lightweight
particles that serve to compose classes. I see them
as the heavyweights in the type d
17 matches
Mail list logo