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...
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 Cwhere
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
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
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
CArray or CHash 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
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
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
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 extra
On Thu, Oct 26, 2006 at 03:17:27PM +0200, TSa wrote:
: HaloO,
:
: I wrote:
: 2) We have AB and the A B juxtaposition to mean $_ ~~ A $_ ~~ B
:which is an intersection (sub)type of A and B.
:
: Is the AB form a legal alternative for the juxtaposition?
Not in a signature. It's ambiguous
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 block of
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
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 precisely
HaloO,
Jonathan Lang wrote:
2) We have AB 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 section
HaloO,
I wrote:
2) We have AB and the A B juxtaposition to mean $_ ~~ A $_ ~~ B
which is an intersection (sub)type of A and B.
Is the AB form a legal alternative for the juxtaposition?
--
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
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,
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 the
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 AB and the A B
17 matches
Mail list logo
