Yes, that's essentially it – except that since we haven't converged on a
particular design, it's hard to say exactly what interfaces are at this
point. But yes, it's something that provides a first class representation
of some protocol/interface.
On Mon, Oct 17, 2016 at 11:33 AM, Brian Rogoff
On Thursday, October 13, 2016 at 1:00:21 PM UTC-7, Stefan Karpinski wrote:
>
> 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
>
On Thu, Oct 13, 2016 at 12:26 PM, Brian Rogoff 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
On Wednesday, October 12, 2016 at 9:40:27 PM UTC-4, Steven G. Johnson wrote:
>
>
>
> On Wednesday, October 12, 2016 at 9:26:54 PM UTC-4, Stefan Karpinski wrote:
>>
>> That's a fair point. It seems like it could/should be handled by the same
>> (not-yet-implemented) mechanism that ensures that
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
On Wednesday, October 12, 2016 at 9:26:54 PM UTC-4, Stefan Karpinski wrote:
>
> That's a fair point. It seems like it could/should be handled by the same
> (not-yet-implemented) mechanism that ensures that `convert(T,x)::T` is
> true. Of course, we could choose to enforce this fact via
That's a fair point. It seems like it could/should be handled by the same
(not-yet-implemented) mechanism that ensures that `convert(T,x)::T` is
true. Of course, we could choose to enforce this fact via lowering in this
case, independent of enforcing it for convert.
On Wed, Oct 12, 2016 at 7:40
Very nice summary!
I assume that there's a mile-long issue discussing this somewhere, but why
doesn't the return type also assert that convert returns a value of the
correct type?
type A end
Base.convert(::Type{Int}, ::A) = "hey"
foo()::Int = A()
foo() # returns "hey"
On Wednesday, October
Perfect, thanks.
Jared Crean
On Wednesday, October 12, 2016 at 2:40:03 PM UTC-4, harven wrote:
>
>
>
> Le mercredi 12 octobre 2016 01:45:25 UTC+2, Jared Crean a écrit :
>>
>> Very nice summary, thanks for posting. One question I had was what
>> should the signature of a function be to
Le mercredi 12 octobre 2016 01:45:25 UTC+2, Jared Crean a écrit :
>
> Very nice summary, thanks for posting. One question I had was what should
> the signature of a function be to receive a generator? For example, if the
> only method of extrema is extrema(A::AbstractArray), is that too
>
Thanks for writing this up; it's helpful to see certain things highlighted
and explained in more detail than news.md gives!
However,
g(n) = sum( i^2 for i = 1:n )
julia> g(0)
ERROR: MethodError: no method matching zero(::Type{Any})
Closest candidates are:
zero(::Type{Base.LibGit2.Oid}) at libgit2/oid.jl:88
zero(::Type{Base.Pkg.Resolve.VersionWeights.VWPreBuildItem}) at
pkg/resolve/versionweight.jl:80
f(n) = [ i^2 for i = 1:n ]
julia> f(0)
0-element Array{Int64,1}
On Wednesday, 12 October 2016 07:10:37 UTC+1, Jussi Piitulainen wrote:
>
> Does that mean that an empty array comprehension is always Array{Any}?
>
> that array comprehensions are now type-inference-independent. That means
>> that
Does that mean that an empty array comprehension is always Array{Any}?
that array comprehensions are now type-inference-independent. That means
> that the type of the resulting array only depends on the actual types of
> values produced, not what the compiler can prove about the expression in
Very nice summary, thanks for posting. One question I had was what should
the signature of a function be to receive a generator? For example, if the
only method of extrema is extrema(A::AbstractArray), is that too
restrictive?
Jared Crean
On Tuesday, October 11, 2016 at 1:05:03 PM UTC-4,
15 matches
Mail list logo