HaloO Larry,
you wrote:
: Could you explain what exactly 'run-time lazy type aliasing' is?
: I mean what does it achieve and how does it compare to type
: instanciation and parametric contraint checking?
It achieves guaranteed *late* binding of types, whereas generics/roles
are biased towards e
On Wed, Jul 06, 2005 at 03:29:36PM +0200, "TSa (Thomas Sandlaß)" wrote:
: HaloO Larry,
:
: you wrote:
: >Well, there's something to be said for that, but my gut feeling says
: >that we should reserve the explicit generic notation for compile time
: >processing via roles, and then think of run-time
HaloO Larry,
you wrote:
Well, there's something to be said for that, but my gut feeling says
that we should reserve the explicit generic notation for compile time
processing via roles, and then think of run-time lazy type aliasing
Could you explain what exactly 'run-time lazy type aliasing' is
On Mon, Jul 04, 2005 at 04:09:59PM +0200, "TSa (Thomas Sandlaß)" wrote:
: I think the point is that using a type variable in the signature of a sub
: is too subtle for recognizing it as a type function that produces typed
: subs. Thus---even if it resembles C++ templates---I suggest to put the
: ty
HaloO Larry,
you wrote:
On Thu, Jun 30, 2005 at 09:25:10AM +0800, Autrijus Tang wrote:
: Currently, does this:
:
: sub foo (::T $x, ::T $y) { }
:
: and this:
:
: sub foo (T $x, T $y) { }
:
: Means the same thing, namely
:
:a) if the package T is defined in scope, use that as the
Perhaps type parameters to roles could also be written in (T) notation:
role Tree[(Returns)] {...}
but that would imply the parameter name is "Returns" rather than
"returns". Maybe that's okay, since it's usually a positional
parameter or a special "of" form anyway.
Larry
On Fri, Jul 01, 2005 at 11:51:55AM -0700, Larry Wall wrote:
: So either we need a different sigil for type variables, or a syntax
: for explitly binding and declaring an autovivified type. (Which,
: interestingly, could also be used in rvalue context.)
I neglected to provide an example of this, b
On Thu, Jun 30, 2005 at 09:25:10AM +0800, Autrijus Tang wrote:
: Currently, does this:
:
: sub foo (::T $x, ::T $y) { }
:
: and this:
:
: sub foo (T $x, T $y) { }
:
: Means the same thing, namely
:
:a) if the package T is defined in scope, use that as the
: type constraint fo
Currently, does this:
sub foo (::T $x, ::T $y) { }
and this:
sub foo (T $x, T $y) { }
Means the same thing, namely
a) if the package T is defined in scope, use that as the
type constraint for $x and $y
b) otherwise, set ::T to be the most immediate common supertype
o
