Re: [julia-users] Re: Julia 0.5 Highlights
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 > 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: > Got it, thanks! I want method signatures for documentation, debugging, and as constraints or hints for the compiler, which are exactly what your two things provide. Are these are what you call 'interfaces' in your JuliaCon 2016 keynote, discussed here https://github.com/JuliaLang/julia/issues/6975? > 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. >
[julia-users] Re: Julia 0.5 Highlights
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.
[julia-users] Zero indexed arrays
Hi, I saw in the release notes that Julia added support for different array indexing methods. I decided to try my hand at implementing zero indexed vectors, and started with the instructions here http://docs.julialang.org/en/latest/devdocs/offset-arrays/ I found this part of the documentation to be unhelpful compared to other parts of the Julia docs (is that just me?), but with a bit of hacking I came up with this immutable ZeroIndexedVector{T} <: AbstractArray{T, 1} data::Array{T,1} end Base.linearindices{T}(A::ZeroIndexedVector{T}) = 0:(length(A.data)-1) Base.getindex{T}(A::ZeroIndexedVector{T}, i::Int) = A.data[i + 1] Base.setindex!{T}(A::ZeroIndexedVector{T}, v, i::Int) = (A.data[i + 1] = v) Base.indices{T}(A::ZeroIndexedVector{T}) = (0:(length(A.data)-1),) Base.endof{T}(A::ZeroIndexedVector{T}) = length(A.data) - 1 Base.show{T}(A::ZeroIndexedVector{T}) = show(A.data) function Base.display{T}(A::ZeroIndexedVector{T}) @printf("%d-element ZeroIndexedVector{%s, 1}:\n", length(A.data), string(T)) for elt in A.data @printf("%s\n", string(elt)) end end Apart from some obvious failings (eg, not copying he backing array) it seems to work. What's the best way to write this code? How does one extend this to multidimensional arrays? IMO, the explanation of how to do these two things would have served as good examples on the doc page. -- Brian
[julia-users] Re: Get the red out!
Thanks Simon, way better, way more Julian. -- Brian On Saturday, September 24, 2016 at 5:12:52 PM UTC-7, Simon Danisch wrote: > > How about something like this: > > function showtypetree(T, level=0) > println("\t" ^ level, T) > for t in subtypes(T) > (t != Any) && showtypetree(t, level+1) > end > end > > This is still not type stable, since *_subtype *seems to use untyped sets: > https://github.com/JuliaLang/julia/blob/master/base/reflection.jl#L283 > > Not sure if this is an oversight, or if there are actually corner cases > making it impossible to type as Set{DataType}(). > Fact is, with that change subtype is 10x faster and doesn't return > Vector{Any} anymore. > I opened a PR: > https://github.com/JuliaLang/julia/pull/18663 > > Best, > Simon > > > Am Sonntag, 25. September 2016 00:12:16 UTC+2 schrieb Brian Rogoff: >> >> ... of @code_warntype output. >> >> I was reading >> https://en.wikibooks.org/wiki/Introducing_Julia/Types#Investigating_types >> and I came across the following code, described as "not very elegant": >> >> level = 0 >> function showtypetree(subtype) >> global level >> subtypelist = filter(asubtype -> asubtype != Any, subtypes(subtype)) >> if length(subtypelist) > 0 >> println("\t" ^ level, subtype) >> level += 1 >> map(showtypetree, subtypelist) >> level -= 1 >> else >> println("\t" ^ level, subtype) >> end >> end >> >> showtypetree(Number) >> >> >> Being unable to leave well enough alone, I decided to try to make it more >> elegant. After replacing the inelegant global variable with a nested >> function, I first noticed that the function returns '0', which is ugly. So, >> the increment operators return a value, which is unfortunate (any reason >> there's no increment with doesn't do that?) and the two branches of the if >> return different types. A special 'ignore' function patches that. map also >> builds and returns a value that's discarded. In OCaml we'd use an 'iter' >> instead of 'map', but Julia's 'for' can be a one-liner too. I left the >> print alone even though there's no need to repeatedly build those strings >> (print_nchars_before is easy) .In the end I got here >> >> ignore{T<:Any}(value::T)::Void = return >> >> function showtypetree(subtype::DataType)::Void >> level::Int64 = 0 >> function nested(st::DataType)::Void >> subtypelist = filter(asubtype -> asubtype != Any, subtypes(st)) >> if length(subtypelist) > 0 >> println("\t" ^ level, st) >> level += 1 >> for s in subtypelist nested(s) end >> ignore(level -= 1) >> else >> println("\t" ^ level, st) >> end >> end >> nested(subtype) >> end >> >> >> I still notice that when I do @code_warntype showtypetree(Number), I get >> some 'red', notably, level is shown as Core.Box, even though I explicitly >> type it. Is there some way to reduce the red in the @code_warntype for this >> function? Here's what I get in 0.6.0-dev.749 >> >> julia> @code_warntype showtypetree(Number) >> Variables: >> #self#::#showtypetree >> subtype::Type{Number} >> level::Core.Box >> nested::Core.Box >> >> Body: >> begin >> level::Core.Box = $(Expr(:new, :(Core.Box))) >> nested::Core.Box = $(Expr(:new, :(Core.Box))) >> SSAValue(0) = Main.Void >> (Core.setfield!)(level::Core.Box,:contents,0)::Int64 # line 3: >> SSAValue(1) = $(Expr(:new, :(Main.#nested#2), :(level), :(nested))) >> (Core.setfield!)(nested::Core.Box,:contents,SSAValue(1))::#nested#2 >> # line 16: >> return >> (Base.convert)(SSAValue(0),((Core.getfield)(nested::Core.Box,:contents)::Any)(subtype::Type{Number})::Any)::Void >> end::Void >> >> >> and I'm not sure how to remove the red and make the code more elegant. >> Ideas? >> >>
[julia-users] Get the red out!
... of @code_warntype output. I was reading https://en.wikibooks.org/wiki/Introducing_Julia/Types#Investigating_types and I came across the following code, described as "not very elegant": level = 0 function showtypetree(subtype) global level subtypelist = filter(asubtype -> asubtype != Any, subtypes(subtype)) if length(subtypelist) > 0 println("\t" ^ level, subtype) level += 1 map(showtypetree, subtypelist) level -= 1 else println("\t" ^ level, subtype) end end showtypetree(Number) Being unable to leave well enough alone, I decided to try to make it more elegant. After replacing the inelegant global variable with a nested function, I first noticed that the function returns '0', which is ugly. So, the increment operators return a value, which is unfortunate (any reason there's no increment with doesn't do that?) and the two branches of the if return different types. A special 'ignore' function patches that. map also builds and returns a value that's discarded. In OCaml we'd use an 'iter' instead of 'map', but Julia's 'for' can be a one-liner too. I left the print alone even though there's no need to repeatedly build those strings (print_nchars_before is easy) .In the end I got here ignore{T<:Any}(value::T)::Void = return function showtypetree(subtype::DataType)::Void level::Int64 = 0 function nested(st::DataType)::Void subtypelist = filter(asubtype -> asubtype != Any, subtypes(st)) if length(subtypelist) > 0 println("\t" ^ level, st) level += 1 for s in subtypelist nested(s) end ignore(level -= 1) else println("\t" ^ level, st) end end nested(subtype) end I still notice that when I do @code_warntype showtypetree(Number), I get some 'red', notably, level is shown as Core.Box, even though I explicitly type it. Is there some way to reduce the red in the @code_warntype for this function? Here's what I get in 0.6.0-dev.749 julia> @code_warntype showtypetree(Number) Variables: #self#::#showtypetree subtype::Type{Number} level::Core.Box nested::Core.Box Body: begin level::Core.Box = $(Expr(:new, :(Core.Box))) nested::Core.Box = $(Expr(:new, :(Core.Box))) SSAValue(0) = Main.Void (Core.setfield!)(level::Core.Box,:contents,0)::Int64 # line 3: SSAValue(1) = $(Expr(:new, :(Main.#nested#2), :(level), :(nested))) (Core.setfield!)(nested::Core.Box,:contents,SSAValue(1))::#nested#2 # line 16: return (Base.convert)(SSAValue(0),((Core.getfield)(nested::Core.Box,:contents)::Any)(subtype::Type{Number})::Any)::Void end::Void and I'm not sure how to remove the red and make the code more elegant. Ideas?
Re: [julia-users] Proposed solution for writing Enums
What's an example of a good Julep? I did some searching and couldn't find much. Is there a document somewhere about writing and submitting Julia Enhancement Proposals? On Tuesday, August 23, 2016 at 11:09:25 AM UTC-7, Stefan Karpinski wrote: > > On Tue, Aug 23, 2016 at 12:39 PM, Brian Rogoff <bro...@gmail.com > > wrote: > >> It's a bit surprising that Julia doesn't have built in enums and a >> case/switch form. I'm glad that there's open >> issue https://github.com/JuliaLang/julia/issues/5410 >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fjulia%2Fissues%2F5410=D=1=AFQjCNGQ278eIdJcTAsQPvyraltYcTf1bg> >> >> to address the lack of case/switch. Is there any hope that >> we may see these (or at least the built in case/switch) in 1.0? >> > > It's certainly possible. The best way to make it happen is to write a good > Julep for how case/switch should behave and once there's general agreement > on the plan, make a PR to implement it. >
Re: [julia-users] Proposed solution for writing Enums
It's a bit surprising that Julia doesn't have built in enums and a case/switch form. I'm glad that there's open issue https://github.com/JuliaLang/julia/issues/5410 to address the lack of case/switch. Is there any hope that we may see these (or at least the built in case/switch) in 1.0? On Tuesday, August 23, 2016 at 5:57:20 AM UTC-7, Stefan Karpinski wrote: > > Oh, I see that you have: > https://groups.google.com/forum/#!topic/julia-users/fgzVlbGcw-o. > > On Tue, Aug 23, 2016 at 8:55 AM, Stefan Karpinski> wrote: > >> The formatting on that came out pretty garbled. Can you repost with line >> breaks and such? >> >> On Mon, Aug 22, 2016 at 5:03 PM, Paul Sorensen > > wrote: >> >>> The following is my idea of writing enums that are better than the macro >>> because they give you a typesafe way of passing them to a >>> functionbaremodule EnumNameimmutable enumnamex::UInt8end >>> const Value_A = enumname(0)const Value_B = enumname(1)end# usage >>> examplebaremodule Colorimmutable colorx::UInt8endconst >>> Red = color(1)const Green = color(2)const Blue = color(3)const >>> White = color(4)const Black = color(5)endfunction >>> testColor(c::Color.color)println("A color was >>> passed")endtestColor(Color.Red) >>> >> >> >
[julia-users] Why aren't multiple const definitions allowed on a line?
julia> global x = 2, y = 3, z = 5 5 julia> const u = 7, v = 11, w = 13 ERROR: syntax: invalid assignment location "11" Is there a rationale for this difference in behavior? Version 0.6.0-dev.364 -- Brian
[julia-users] Re: using statement with for loop inside if statement
In what way doesn't it make sense to evaluate it in a local scope? It's true that Julia modules don't behave that way now, but other languages support local modules; D and OCaml come to mind. On Wednesday, December 9, 2015 at 7:22:51 AM UTC-8, Steven G. Johnson wrote: > > A using statement affects the global scope, so it doesn't make a lot of > sense to evaluate it in local scope. That's why it's not allowed. The eval > function evaluates in global scope, so it can execute a using statement. > > In general, though, if you are eval'ing a using statement, you should > probably reorganize your code to do the using directly in global scope. For > example, put your code into a module if you want to keep the using > statement isolated from other code. >
[julia-users] Re: Style Guideline
IMO the main reason for (33) is that Julia presently lacks any local import feature. At least a few languages with module systems add these; see for instance OCaml http://caml.inria.fr/pub/docs/manual-ocaml-4.01/extn.html#sec225 and also Ada, which allows with/use inside of blocks. Is there a reason that a similar feature wouldn't work well with Julia too? -- Brian On Tuesday, December 31, 2013 7:01:23 AM UTC-8, John Myles White wrote: One of the things that I really like about working with the Facebook codebase is that all of the code was written to comply with a very thorough internal style guideline. This prevents a lot of useless disagreement about code stylistics and discourages the creation of unreadable code before anything reaches the review stage. In an attempt to emulate that level of thoroughness, I decided to extend the main Julia manual’s style guide by writing my own personal style guideline, which can be found at https://github.com/johnmyleswhite/Style.jl I’d be really interested to know what others think of these rules and what they think is missing. Right now, my guidelines leave a lot of wiggle room. — John