On Jul 30, 2013, at 09:32 , Graydon Hoare <[email protected]> wrote:
> On 13-07-29 04:29 PM, Wojciech Miłkowski wrote:
>> Hi,
>>
>> I'm observing rust development for some time, and I must say it slowly
>> encourages me to use it. Especially the progress from Perl-like syntax
>> to more sane and quiet form is enjoyable.
>> That said I wonder why the function definition has form:
>> fn name(var: type, ...) -> return_type {...}
>> instead of more unified:
>> fn name(var: type, ...): return_type {...}
>
> Sigh. Speaking of Perl!
>
> "Larry's First Law of Language Redesign: Everyone wants the colon."
>
> We get this question every now and then, which is perhaps an indication that
> we're attracting more people from Scala-land than I expected. I can't imagine
> it's converts from Pascal! Let's tally up some function tycons from the world
> of languages:
>
> In the "->" column:
>
> Normal Mathematics[1]
> Simply Typed Lambda Calculus[2]
> C++11 alternative function syntax[3]
> Typed Racket[4]
> Typed Python[5]
> The term-rewrite languages (OBJ, Maude, Q, Pure)
> The ISWIM languages (Miranda, Hope, Clean, Haskell, ML, Ocaml, F#)
>
> In the ":" column:
>
> Scala
> One older Pike language (Limbo)
> The Wirth languages (Pascal, Modula-3, Oberon)
> Eiffel and Sather
> Our extremely worthy competitors Clay and Nimrod
Let a lurker nitpick on a false dichotomy in this comparison. There are three
separate things going on that the current discussion seems to confuse:
1. The syntax of type annotations.
2. The syntax of function types.
3. The syntax of function definitions.
ML, Caml, Haskell, Coq, Agda, as well as Scala, and practically all
higher-order languages with strong roots in type theory consistently use ":"
for (1) and "->" for (2) (sometimes lexical variations like "::" or "=>").
Moreover, function definitions tend to be viewed as a special kind of
equational pattern match where the pattern happens to be a function
application. So in all these languages, a fully-annotated function definition
would be written with a _colon_, too, contrary to what the above list seems to
suggest. That's because it's just another type annotation of a pattern:
f(x : t1) : t2 = exp
annotates "f(x)" with the type t2. The type of f itself, on the other hand,
would be written f : t1 -> t2. And
g(x : t) : u -> v = exp
is the definition of a function that results in a function, so that g : t -> (u
-> v).
This is pretty much the standard notation in type-theoretic literature or
related languages (although some, notably Haskell, place more restrictions on
function definitions and don't allow an inline return type annotation at all).
Note how it's both readable and internally consistent. The Rust syntax arguably
less so, although it's probably not worth changing.
The arcane horrors of C-style type and declaration syntax are another topic
altogether that I refrain from touching. :)
/Andreas
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
