On Thu, Oct 13, 2016 at 12:26 PM, Brian Rogoff <brog...@gmail.com> wrote:
> Great summary, thanks so much!
>
> Being a fan of typeful functional programming, I really like the return
> type annotations and FP performance improvements. Is there a way to
> describe a precise return type for a higher order function? The examples of
> Function I've seen have neither the arguments type/arity or return types.
>
No, Function doesn't have signatures, arity or return type as part of its
type. The signature of a function is the union of its method signatures,
which is potentially very complicated. Type parameters are not
contravariant, so they can't be described without massively complicated
Julia's (already complicated) type system. Worse still, adding any form of
contravariance would almost certainly make important predicates like
subtype and type intersection undecidable. There are still things that
could be done to get some of the features that you probably want from
function types, but dispatching on the return type is unlikely to ever be
allowed. Two things that may happen are:
1. Constraining the type signature of a generic function, raising an error
if any method returns something that doesn't match:
convert{T} :: (T, Any)-->T
or whatever syntax makes sense. This would implicitly mean that any call to
convert(T,x) would be translated to convert(T,x)::T so that we know convert
always returns the type one would expect for it. This is what I was
alluding to above.
2. Intersecting a function signature on an argument with a generic function
to extract a "sub-function" that will either behave the way we expect it to
or raise an error:
function mysort!{T}(lt::(T,T)-->Bool, Vector{T})
...
end
This would mean that any use like lt(a, b) in the function body would
implicitly be wrapped as lt(a::T, b::T)::Bool or something like that. This
extra type information could potentially allow the compiler to reason
better about the function's behavior even in cases where it otherwise can't
figure out that much. Of course, in the case that's already fast, we don't
need that information since the type of function calls can already be
completely inferred.
Note that neither of these allow you to dispatch on the type of lt.
