On 17/05/2011, at 12:38 AM, David Herman wrote:
>>> How do you get from "lack of compositionality" to "forfeit all other
>>> features"?
>>
>> Lack of polymorphism, not composition.
>
> I'm sorry, I'm just still confused about why you claim we have no
> polymorphism. I mean, we simply do have polymorphism. I think I understand
> why you are saying that polymorphic functions are less general in a language
> with multiary functions, but it doesn't mean we have *no* polymorphism.
I know, but the polymorphism isn't fully parametric, because that implies it is
combinatorial,
i.e. you can just combine anything with anything.
I picked composition as an example, I'm sure it isn't the only time the lack of
a type for
a function domain is a problem. Note that multiple arguments aren't a problem
for
functions like "fold" since that works just fine with the folding argument
having type
fn(A,B)->B
If you want to get theoretical this function has domain of kind
TYPE * TYPE
where TYPE is the category of types. A value of that category is a type tuple
(A,B)
so the function above DOES have a domain: (A,B) but that isn't a type, its a
value of
a different Kind that TYPE (in particular, the Kind TYPE * TYPE).
Note there are no values of style (A,B) in the language. Tuple values are
values of type A * B (a single type) not a pair of types.
This means you can get full polymorphism in Rust by introducing a proper
kinding system .. but that is quite hard I think. And users will not only have
to write polymorphic functions in the library .. they'll have to write
functors as well.
>
> There has been work on making polymorphism more expressive in languages with
> multiple arity functions:
>
> http://www.ccs.neu.edu/racket/pubs/esop09-sthf.pdf
>
> And I think C++0x has some similar functionality.
Yes it does. But it is still incomplete and a hack: look at all that complexity
to do what is
simple in ML. Rather it isn't simple .. its non-existent. There's no machinery
required
to make it work.
The exception is tuples because there are N-ary functors. The point is there's
just one of these nasty things in the language.
> I think it's worth cutting to the chase and recognizing that we are not
> aiming for perfection. We're looking for a good trade-off between many
> competing constraints.
Of course.
> That requires taste, and it requires compromise. Reasonable people can
> disagree about some of the individual decisions we make, but I don't agree
> that this one constitutes an insurmountable failure.
What becomes insurmountable is when you want to change something and you CANT
because you have too many users. C++ is a good example of this. They screwed up
a few things quite badly in ISO C++ and 201x can't fix them now. Its too late.
That's basically why I quit the committee: beyond recovery. Sure C++ is useable
..
but it could have been a lot better.
--
john skaller
[email protected]
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
