Some special cases of method dispatch in Julia | Hacker News Reader

Some special cases of method dispatch in Julia

bkamins.github.io

30 points2pEXgD0fZ5cF17 comments

Dispatch ambiguity can really bite you, particularly if you start extending methods from other packages. An issue I often run into at the same time as method ambiguity is a stack overflow from self-calling constructors. If you try to define an outer constructor with default arguments, it's really easy to end up just calling that constructor from itself.

The metaprogramming trick for defining a set of methods at once is useful, but I wish there were a more compiler-level solution to sorting out ambiguities or determining what's more "specialized".

These don't really color my view on multiple dispatch, however. I find it to be a really useful tool and I don't run into dispatch issues very frequently. If you're meticulous about your typing it's usually easy to avoid these pitfalls, but sometimes they still crop up.

I wonder if there is some principled way of making Julia-style method dispatch statically checkable?

JET.jl does a surprisingly good job of statically checking julia type errors as well as other classes of errors using only type-level code analysis.

https://github.com/aviatesk/JET.jl

It does catch method ambiguities like those shown in this blog post:

  julia> using JET
  
  julia> f(x, y::Int) = x + y
  f (generic function with 2 methods)
  
  julia> f(x::Int, y) = x - y
  f (generic function with 2 methods)
  
  julia> g(x, y) = f(x, y)
  g (generic function with 1 method)
  
  julia> @test_call g(1, 2)
  JET-test failed at REPL[13]:1
    Expression: #= REPL[13]:1 =# JET.@test_call g(1, 2)
    ═════ 1 possible error found ═════
    ┌ @ REPL[12]:1 Main.f(x, y)
    │ no matching method found for call signature (Tuple{typeof(f), Int64, Int64}): Main.f(x::Int64, y::Int64)
    └──────────────
  
  ERROR: There was an error during testing

method overloading is a horrible language feature that papers over the absence of other, more useful language features like optional arguments, etc.

i worked on a JVM programming language back in the day, and that damned feature screwed up everything: method resolution was obviously a pain, but it got involved in generics, class compatibility, it even ends up worming its way into bytecode, since methods names are really the name plus the fully qualified type name of every argument (even if there isn't any method overloading for a given method, just awful)

i wrote an old blog post on this:

https://guidewiredevelopment.wordpress.com/2009/05/22/i-am-h...

in conclusion: things should have unique names

It might be annoying to implement well, but there's a reason no widely used programming languages (other than assembly) have add_int and add_float as separate functions.

I don't know GScript, but wouldn't it be enough to know which methods are declared in GScript (and not allow overloading for these)? Then type inference can work fully most of the time and only give up when calling non-Java code.

Also, why does this complicate the parser? It looks like you're interfering some type information from later usage (the `foo( someVar )` example), so handling typing in the parser seems a bit strange.

As for the bytecode, it's not just methods: Fields likewise are identified by name and type and can be overloaded. I'm just happy that Java itself doesn't allow field overloading - I'm not the biggest fan of method overloading either.

the parser gets more and more complicated as you score methods, this gets really, really, really nasty once generics get involved

just an awful feature that solves no problems that can't be better done with other features that, for whatever reason, just aren't as popular

How else would you implement addition? What is another API that can handle adding objects of various types, (Int8,16,32,64, BigInt, Complex for all of these, rational for all of these, and Float16, 32, 64) that doesn't totally suck?

union types

First of all, Julia does have union types. But how does that help when the caller gives you a user-defined type?

w/ proper union types, you just chuck another type, user defined or not, in the method signature and type cast via whatever syntax you have available in the implementation

So you live in a world where there's a fixed number of built-in types hard-coded into your library?

I'm afraid that doesn't cut it in a modern programming context.

that only works if the method knows about all the types that might exist. The reason overloading is necessary is that the person that writes + for your programming language doesn't know all the types that people will want to call + on. As such, you need a way to define new implementations of + when people add new types in the future. This forces you to have some form of overloading.

Multiple dispatch with external methods isn't a 'feature' of Julia, it is the central organizing principle that the whole language is built on. And among everyone who actually uses the language there is consensus that it is what makes it good.

Sorry to hear that you failed to implement it back in the day, but that doesn't mean there's anything wrong with multiple dispatch in and of itself. It's just hard to get right. But when it works, it is without doubt the best paradigm for a language that I can think of.

BTW, optional arguments are not 'absent' in Julia, they are absolutely present, and are, in fact, implemented using multiple dispatch.

Dynamic dispatch is not the same thing as overloading. You can't achieve the same thing by fully qualifying the name of everything statically.

s/principals/principles in the post

i wrote the post 13 years ago and no longer have access to that blog

i'm shocked it's still up, tbh

Reply on news.ycombinator.com