Re: [julia-users] Re: Julia 0.5 Highlights

2016-10-17 Thread Stefan Karpinski
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

Re: [julia-users] Re: Julia 0.5 Highlights

2016-10-17 Thread 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 >

Re: [julia-users] Re: Julia 0.5 Highlights

2016-10-13 Thread Stefan Karpinski
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

Re: [julia-users] Re: Julia 0.5 Highlights

2016-10-13 Thread Steven G. Johnson
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

[julia-users] Re: Julia 0.5 Highlights

2016-10-13 Thread Brian Rogoff
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

Re: [julia-users] Re: Julia 0.5 Highlights

2016-10-12 Thread Steven G. Johnson
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

Re: [julia-users] Re: Julia 0.5 Highlights

2016-10-12 Thread Stefan Karpinski
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

[julia-users] Re: Julia 0.5 Highlights

2016-10-12 Thread Cedric St-Jean
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

[julia-users] Re: Julia 0.5 Highlights

2016-10-12 Thread Jared Crean
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

[julia-users] Re: Julia 0.5 Highlights

2016-10-12 Thread harven
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 >

[julia-users] Re: Julia 0.5 Highlights

2016-10-12 Thread Evan Fields
Thanks for writing this up; it's helpful to see certain things highlighted and explained in more detail than news.md gives!

[julia-users] Re: Julia 0.5 Highlights

2016-10-12 Thread Christoph Ortner
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

[julia-users] Re: Julia 0.5 Highlights

2016-10-12 Thread Christoph Ortner
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

[julia-users] Re: Julia 0.5 Highlights

2016-10-12 Thread Jussi Piitulainen
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

[julia-users] Re: Julia 0.5 Highlights

2016-10-11 Thread Jared Crean
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,