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

[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 
> 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

[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 type/arity or return types.

[julia-users] Zero indexed arrays

[Brian Rogoff]

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!

[Brian Rogoff]

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!

[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?

Re: [julia-users] Proposed solution for writing Enums

[Brian Rogoff]

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

[Brian Rogoff]

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?

[Brian Rogoff]

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

[Brian Rogoff]

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

[Brian Rogoff]

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