Re: Adding linear interpolation to an array
Thomas Sandlaß
> I don't see why I need the conditional there. If I'm going to copy the
> array, I might as well declare up front the that darget does
> LinearInterpolation:
>
> sub foo (Num @raw_in)
> {
> my Num @in does LinearInterpolation = @raw_in;
> ...
> }
This depends on how initialization works. For the above to work
the 'Array of Num does LinearInterpolation' needs a constructor
that takes a plain 'Array of Num' as parameter. I think that exists
but Aldo just wanted to avoid the dought.
> Or perhaps even
>
> sub foo (Num @in is copy does LinearInterpolation)
> {
> ...
> }
This is my big questionmark on roles: is the above a contraint
or merely a directive. In the former case only Arrays of Num that
do LinearInterpolation are allowed, in the latter case every
Array of Num that is used as argument gets the role attached while
it lingers in foo. I just realized there's a trait_auxiliary:shall
mentioned in A12 which I've not seen in action somewhere. This could
be the second meaning and roles in signatures describe what is *done*
to the arguments not what they shall be able to do.
I still wonder how the type system really works...
--
TSa (Thomas Sandlaß)
Dave Whipp
>> Or perhaps even
>>
>> sub foo (Num @in is copy does LinearInterpolation)
>> {
>> ...
>> }
>
>
> This is my big questionmark on roles: is the above a contraint
> or merely a directive. In the former case only Arrays of Num that
> do LinearInterpolation are allowed, in the latter case every
> Array of Num that is used as argument gets the role attached while
> it lingers in foo.
Perhaps a new keyword/opertor is need to separate the constraints from
the directives. C<that> would read nicely:
sub foo ( Num @in is copy that does LinearInterpolation )
Dave.
Larry Wall
: >Or perhaps even
: >
: >sub foo (Num @in is copy does LinearInterpolation)
: >{
: > ...
: >}
:
: This is my big questionmark on roles: is the above a contraint
: or merely a directive. In the former case only Arrays of Num that
: do LinearInterpolation are allowed, in the latter case every
: Array of Num that is used as argument gets the role attached while
: it lingers in foo. I just realized there's a trait_auxiliary:shall
: mentioned in A12 which I've not seen in action somewhere. This could
: be the second meaning and roles in signatures describe what is *done*
: to the arguments not what they shall be able to do.
One can always mixin a "does LinearInterpolation" at run time in the
body of the sub to get the effect of a directive, so I think the most
useful thing is to treat roles in signatures as constraints where
they can be used to select for MMD.
That being said, it probably depends on the role. A variable that is
intended to be bound to another value presents a view of that other
value that may differ from that actual value in significant ways.
We probably need to come up with a way to mark such instructions to
the container that aren't intended to add constraints.
And we probably need to distinguish view directives from ordinary
mixins anyway, since if you apply a "does LinearInterpolation" as
an ordinary mixin, the object itself is reblessed into an anonymous
class that includes the role, and that effect would persist beyond the
function call. Whereas a view directive would only be in operation
during the call. Maybe we need to work in the linguistic notion of
"pretends to be" somehow.
: I still wonder how the type system really works...
Me too. If it's any comfort, just think of the design of Perl 6 as
a genetic algorithm running on a set of distributed wetware CPUs.
We'll just keep mutating our ideas till they prove themselves adaptive.
Larry
Thomas Sandlaß
> One can always mixin a "does LinearInterpolation" at run time in the
> body of the sub to get the effect of a directive, so I think the most
> useful thing is to treat roles in signatures as constraints where
> they can be used to select for MMD.
Further questions concerning MMD:
1) How are the classes of
a) the container
b) the value
used in dispatch? Note that 'Array of Num' in other languages
is more like a parameter on the template/generic: Array[Int].
Does it hold for Perl 6 in general that the 'of' is syntactic
sugar for (container) class specialisation? E.g. could Damian's
example of Source[Perl] be written as 'Source of Perl'?
Should the programmer get the chance to define if the type parameter
is either covariant or contravariant like the extends/super in Java5
generics?
2) how are the where clauses used in MMD relative to roles and classes?
3) I guess the distance function is not specified yet, right? Is it at
least symmetric, so that it avoids the surprises that CLOS has in store
with its linearisations? The multiple inheritance resolution is also
relying on user intervention and not calculating a class precidence
list as Dylan does. Symmetic means the following:
with
class Base {...}
class Left is Base {...}
class Right is Base {...}
there are at most three binary multis allowed
multi sub foo ( Base $x, Base $y ) {...}
multi sub foo ( Left $x, Left $y ) {...}
multi sub foo ( Right $x, Right $y ) {...}
otherwise a call like foo( Base.new, Right.new ) would be ambigous.
In other words a conflict where one multi is more specific here and
another there is reported and not somehow "resolved".
4) what's the intent of trait_auxiliary:shall?
> : I still wonder how the type system really works...
>
> Me too. If it's any comfort, just think of the design of Perl 6 as
> a genetic algorithm running on a set of distributed wetware CPUs.
> We'll just keep mutating our ideas till they prove themselves adaptive.
At the very heart a type system is something simple: it defines an order.
Or actually two intertwinned ones: the subtype relation and the inheritance
relation. The typechecker, the optimizer and the dispatcher use this order
to enlighten or annoy the programmer, to decide what code to generate and
which method to call respectively.
With junctive values on types it should be easy to define a lattice that
consists of user specified and calculated nodes. This is what I tried
to explain elsewhere---without having clear vision how that fits into the
Perl 6 Genom :)
Last not least the parametric polymorphism should be accompanied by a
constraints system to get CBP (Constraint-Bounded Polymorphism) which
is a superset of F-Bounded Polymorphism. This proposal is polymorphic
as well: some consider it Hell others Heaven---with roles flipped when
it comes to excessive use of (implicit) Any ;)
MfG
--
TSa (Thomas Sandlaß)
Juerd
> Maybe we need to work in the linguistic notion of "pretends to be"
> somehow.
If this needs a keyword, I suggest "plays" :)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Luke Palmer
> Larry Wall wrote:
> >One can always mixin a "does LinearInterpolation" at run time in the
> >body of the sub to get the effect of a directive, so I think the most
> >useful thing is to treat roles in signatures as constraints where
> >they can be used to select for MMD.
>
> Further questions concerning MMD:
>
> 1) How are the classes of
> a) the container
> b) the value
> used in dispatch? Note that 'Array of Num' in other languages
> is more like a parameter on the template/generic: Array[Int].
> Does it hold for Perl 6 in general that the 'of' is syntactic
> sugar for (container) class specialisation? E.g. could Damian's
> example of Source[Perl] be written as 'Source of Perl'?
Always.
> Should the programmer get the chance to define if the type
> parameter is either covariant or contravariant like the
> extends/super in Java5 generics?
The words 'covariant' and 'contravariant' in this context seem like
voodoo math. Please explain what you mean.
> 2) how are the where clauses used in MMD relative to roles and classes?
The type:
Foo where {.meth}
Is a new type, which is a subtype of Foo. That is, values of this type
are always Foos, but you may not be able to change them and keep this
property.
> 3) I guess the distance function is not specified yet, right?
It was specified as simple manhattan. I've been arguing for the past
year to get this changed (to 'pure', where there is no distance
function; two methods, which are both viable, where one's matching does
not imply the other's matching, are ambiguous).
> Is it at least symmetric, so that it avoids the surprises that CLOS
> has in store with its linearisations?
Yes, that's a high priority. My latest proposal has yet to incorporate
that (but I believe it can be done).
> The multiple inheritance resolution is also relying on user
> intervention and not calculating a class precidence list as Dylan
> does. Symmetic means the following:
>
> with
>
> class Base {...}
> class Left is Base {...}
> class Right is Base {...}
>
> there are at most three binary multis allowed
>
> multi sub foo ( Base $x, Base $y ) {...}
> multi sub foo ( Left $x, Left $y ) {...}
> multi sub foo ( Right $x, Right $y ) {...}
That's not true. I don't believe it would be an error to specify
all nine combinations.
Luke
Larry Wall
: > 3) I guess the distance function is not specified yet, right?
: It was specified as simple manhattan. I've been arguing for the past
: year to get this changed (to 'pure', where there is no distance
: function; two methods, which are both viable, where one's matching does
: not imply the other's matching, are ambiguous).
I wonder if it would be practical to let the caller specify how much
"fuzz" they're willing to put up with. If manhattan were the default,
you could then maybe say something like "use fuzz 0" to get pure
dispatch for all your calls at least, without necessarily impacting
anyone else's calls. I'm not sure what the units of "fuzz" would
be though...I suppose standard manhattan's fuzz is actually Inf,
if you're counting allowed degrees of derivation.
In any event, this seems like something that could be a lexically
scoped policy. Except maybe you'd have to write your modules
differently to be called under different policies. Hmm...
But still, maybe we can fudge it like we do with "use fatal" and fail().
Larry
Doug McNutt
>'Co' means together like in coproduction. And 'contra' is the opposite
>as in counterproductive. With instanciating parametric types the question
>arises how a subtype relation between instanciating types propagates
>to the template. E.g with Int <: Num, covariance would result in
>Array[Int] <: Array[Num]. Referential classes are actually quite difficult
>because upon write they are contravariant and covariant when read!
>So a third case of uncomparable types is needed as well, or it is the default
>if nothing else is specified.
A word of caution:
Just as in "vector operators" had their names changed to pacify the mathematicians - thank you - there is a conflict in terms. Covariant and contravariant tensors are the meat of Einstein's formulation of relativity. It all has to do with transformations being in the same direction or the opposite direction as the coordinate differentials. Perhaps there is some similarity.
Einstein's presentation is a whole lot easier to understand than the one above.
--
--> Marriage and kilo are troubled words. Turmoil results when centuries-old usage is altered in specialized jargon <--.
Thomas Sandlaß
you wrote:
> The words 'covariant' and 'contravariant' in this context seem like
> voodoo math. Please explain what you mean.
'Co' means together like in coproduction. And 'contra' is the opposite
as in counterproductive. With instanciating parametric types the question
arises how a subtype relation between instanciating types propagates
to the template. E.g with Int <: Num, covariance would result in
Array[Int] <: Array[Num]. Referential classes are actually quite difficult
because upon write they are contravariant and covariant when read!
So a third case of uncomparable types is needed as well, or it is the default
if nothing else is specified.
> That's not true. I don't believe it would be an error to specify
> all nine combinations.
Ohh, sorry. Of course implementing all is fine as well. But a bit
tedious for larger collections of classes.
Michele Dondi
> 'Co' means together like in coproduction. And 'contra' is the opposite
^^^^^^^^^^^^
^^^^^^^^^^^^
'Streaming of digestive byproducts'? ;-)
Sorry for the OT - couldn't resist! This pun first occurred to me wrt
(cathegorical) coproducts...
Michele
--
SILVIO CLEPTOMANE
- Scritta su un muro,
Via F. Sforza, Milano
David Storrs
> >'Co' means together like in coproduction. And 'contra' is the opposite
> >as in counterproductive. With instanciating parametric types the question
> >arises how a subtype relation between instanciating types propagates
> >to the template. E.g with Int <: Num, covariance would result in
> >Array[Int] <: Array[Num]. Referential classes are actually quite difficult
> >because upon write they are contravariant and covariant when read!
> >So a third case of uncomparable types is needed as well, or it is the default
> >if nothing else is specified.
Thomas,
I appreciate you attempting to explain this, but it remains clear as
mud, at least to me. Could you please try again, using very short,
very non-technical words and not assuming a mathematical or
scientific background on the part of your reader?
Something that would help: We could all look the words up in a
dictionary, so we don't need a definition. What we need is a
clarification, in simple terms, of what *you* mean by them, in this
context.
Thank you.
--Dks
Thomas Sandlaß
you wrote:
> I appreciate you attempting to explain this, but it remains clear as
> mud, at least to me. Could you please try again, using very short,
> very non-technical words and not assuming a mathematical or
> scientific background on the part of your reader?
Ok, second attempt!
The <: is the subtype relation operator. Saying Int <: Num
means Int is a subtype of Num. With generic types like the
Array of ... the question is how this relation shall carry
over to the Array type instances.
Int @i;
Num @n = @i; # type error?
Regards,
--
TSa (Thomas Sandlaß)
Thomas Sandlaß
> A word of caution:
>
> Just as in "vector operators" had their names changed to pacify the
> mathematicians - thank you - there is a conflict in terms. Covariant and
> contravariant tensors are the meat of Einstein's formulation of relativity.
> It all has to do with transformations being in the same direction or the
> opposite direction as the coordinate differentials. Perhaps there is some
> similarity.
Yes, that's what is meant by these two words. But of course the concrete
meaning depends on the subject area. The above is from tensor algebra.
Mine is from type theory.
> Einstein's presentation is a whole lot easier to understand than the one above.
Sorry, I make a second attempt in another reply.
--
TSa (Thomas Sandlaß)
Larry Wall
: Int @i;
: Num @n = @i; # type error?
I think the naive user is going to expect that to work, and I also
suspect the naive user is right to expect it, because it makes sense.
This may be one of those areas where we can successfully hide the
high-falutin' theory from mere mortals simply because it maps onto
what they expect already.
On the other hand, that's an assignment, which presumably copies
value types. Binding is another matter--I wouldn't necessarily expect
this to work:
Num @n := @i;
But these might be made to DWIM since copying is allowed:
Num @n is copy := @i;
Num @n is constant := @i;
On the other hand, the plain rw binding *could* be made to work under the
view that @n is providing a view of @i. It's just that @n could provide
only the Int subset of semantics. As such, it's acting as a kind of tie
on @n, so I expect it wouldn't be allowed unless you declared @n to
be some kind of tyable that allows delegating @n to @i. Plus the variable
type would have to capture the binding semantics and force the delegation
past the compiler (presuming the compiler cares about the type mismatch).
But it's okay to disallow some things now on the basis that they're just
not implemented yet, as long as people don't mistake such restrictions
for strong typing.
Larry
Juerd
> On Fri, Mar 11, 2005 at 03:58:13PM +0100, Thomas Sandlaß wrote:
> : Int @i;
> : Num @n = @i; # type error?
> I think the naive user is going to expect that to work, and I also
> suspect the naive user is right to expect it, because it makes sense.
> This may be one of those areas where we can successfully hide the
> high-falutin' theory from mere mortals simply because it maps onto
> what they expect already.
It'd be great if this were a standard feature you can also use for your
own objects.
I believe $foo.Num in this case should return the Num-ified version of
$foo. And maybe the int method numbers have is redundant, and should
be spelled Int instead. Or, well, if this is the case, int should return
an int (not Int) for consistency.
Maybe +$foo even maps to $foo.Num, and ~$foo maps to $foo.Str and ?$foo
maps to $foo.Bool?
Hm, are charsets representable as classes/roles?
my Str::utf8 $bar = ...;
my Str::latin1 $foo = $bar;
Thomas Sandlaß
> Larry Wall skribis 2005-03-11 8:45 (-0800):
>
>>On Fri, Mar 11, 2005 at 03:58:13PM +0100, Thomas Sandlaß wrote:
>>: Int @i;
>>: Num @n = @i; # type error?
>>I think the naive user is going to expect that to work, and I also
>>suspect the naive user is right to expect it, because it makes sense.
>>This may be one of those areas where we can successfully hide the
>>high-falutin' theory from mere mortals simply because it maps onto
>>what they expect already.
>
>
> It'd be great if this were a standard feature you can also use for your
> own objects.
I fully agree with what Larry said about constant and copied parameter
types. There we can easily go with covariant subtyping. OTOH the idea
of a container providing a view of the values is a very high ideal. I think
it is worthwhile to implement in the standard library for ubiquitous
value types like Str, Num and Int. But I doubt that it can be achieved
such that the Array class does respect any (future) value type!
One idea that formally pushes the problem out of the Array class is to
require a role ArrayEntry from every entry. But that would need very
neat defaults to have a chance to be acceptable in the community---I hear
people say: "What? I need to implement that complicated role just to put
my Blahh into an Array?". OK, would could go with independend types when
the entry doesn't ArrayEntry, but then we might hear a slightly different
complain: "I can't mix my Blahhs with other objects in an array!".
So I'm at a loss here.
> I believe $foo.Num in this case should return the Num-ified version of
> $foo. And maybe the int method numbers have is redundant, and should
> be spelled Int instead. Or, well, if this is the case, int should return
> an int (not Int) for consistency.
>
> Maybe +$foo even maps to $foo.Num, and ~$foo maps to $foo.Str and ?$foo
> maps to $foo.Bool?
>
> Hm, are charsets representable as classes/roles?
>
> my Str::utf8 $bar = ...;
> my Str::latin1 $foo = $bar;
In my mindset that would read as
my Str[utf8] $bar = ...;
my Str[latin1] $foo = $bar; # type error? Or dynamic compatibility test?
$bar = $foo could be allowed if the typechecker knew
that latin1 subtypes utf8. More interesting is actually
the typing of string constants:
$foo = "äöü"; # Str[latin1]
my Str[ASCII] $ascii = "äöü"; # type error?
Hmm, since "what is compile to you is runtime for the compiler"
it might by a normal store attempt that is then rejected by the object
and caught by the compiler---cool. Is there also an unchecked store
operation that can be used when the typechecker knows the assignment
is (type-)correct?
Larry Wall
: Hmm, since "what is compile to you is runtime for the compiler"
: it might by a normal store attempt that is then rejected by the object
: and caught by the compiler---cool. Is there also an unchecked store
: operation that can be used when the typechecker knows the assignment
: is (type-)correct?
I think any routine with a fancy signature with potential run-time checking
also has an entry that assumes the checking was done by the caller or
the compiler. The trick will be to discourage people from bypassing
the necessary type checking when they think they know better but don't
really.
Larry