On 15/05/2011, at 2:51 AM, Patrick Walton wrote:
> Hi John,
>
> There is nothing preventing you from writing functions that take one tuple
> parameter instead of multiple parameters.
Yes, that's true, but I can't work with your functions that don't do that.
> If you're faced with library routines with signatures that aren't to your
> liking, it's simple to write macros that tuple, untuple, curry, or uncurry
> parameters.
Is that really the case? In Ocaml etc you can do that, but in Rust can you?
Sorry I don't know Rust well enough but clearly something is lost doing this,
eg if the function
has alias arguments?
> Incidentally, I would be careful with the OCaml comparison; OCaml has
> functions that take multiple, untupled parameters via the named and optional
> parameters feature.
True.
>
> Finally, there's no need for the hyperbolic "[Rust's type system] isn't a
> type system at all" kind of language. Of course Rust has a type system.
> Unless you have found a way in which Rust's type system is unsound (which we
> would definitely like to hear about if so!), that is beyond debate.
The intent was clear I think: if you take "type system", with emphasis on the
word "system" in the modern
sense, then it doesn't. System actually means its an initial algebra.
Functions with multiple arguments can be typed: I mean the domain can be typed,
but in Rust it isn't.
I think you need a kinding system to do it.
Basically if you have type category T, and lets consider a 2 argument
function, then
with a tuple the kind is
T -> T
but with Rust two argument function the kind is
T * T -> T
[ignoring weird stuff like aliases, mutables, and other such things]
In fact the tuple constructor (usually written "," ) is functor
T * T -> T
which is the whole point of it: you have constructor which gets factors away the
extremely difficult to handle multi-argument functions. A multi-argument
function
is a combination tuple constructor and function. It's obviously better to factor
these two distinct kinds of things (in a basic language).
In Rust there's a reason not to do this but it comes at a high price and may not
be necessary.
--
john skaller
[email protected]
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
