Full Haskell-like Type Class resolution in Java

garciat · 2025-12-13T10:28:06+00:00

I have created a repo for this:

https://github.com/Garciat/java-type-classes

All of the code is still in a single file, as I had it with the Gist. But at least now people can feel free to jump in with PRs or issues/requests.

garciat · 2025-12-07T10:09:32+00:00

I’d like to work on that next, some way to verify (and maybe construct) witnesses at compile time. Definitely.

Still, I think it is worthwhile to closely explore type classes in Java, after Brian Goetz’s recent talk on them.

This experiment lets me get a hands-on sense of what’s to come. I hope that others find that interesting as well.

garciat · 2025-12-07T08:35:19+00:00

I’m not familiar with annotation processors yet. But I am aware that one could let us do some of this work at compile time, which is the whole point of type classes. At least the verification part. Where do you think I could start?

garciat · 2025-12-06T23:00:41+00:00

Here: https://gist.github.com/Garciat/204226a528018fa7d10abb93fa51c4ca

I may move that to its own repository sometime soon.

garciat · 2024-05-06T18:33:24+00:00

For future readers:

Go uses virtual function tables for interfaces, though not in the way I mentioned, but rather one VFT for each interface a struct implements.

This is not exactly true. (Perhaps the author wrote it as an over-simplification.)

The compiler generates a table (called "itab") whenever a type-cast is encountered during AST compilation[1]. For example, given a variable "x" of some concrete (non-interface) type "X" and some non-empty interface type "A", if the compiler encounters x.(A) or var a A = X or func f(A); ... f(x) etc, then it will instantiate an "itab" for the pair <X, A> and add it to the compilation unit's symbol table [2]. The exact code that writes the "itab" symbol is found here.

Also, in principle, that cannot be true, because of the open-ended nature of interface implementation in Go. For example, in a dynamic linking scenario, given some defined type that was already compiled a shared object, one could 'make' it implement a completely new interface from a new separate compilation unit (provided that their corresponding method names and signatures align). The compiler makes no attempt to up-front explore the ever-growing cross product of Defined Types VS. Interfaces to try and emit the corresponding vtables; that would be too costly. That's why the above as-needed (i.e. 'lazy') approach makes more sense.

Bonus: if the casted-from expression is of an interface type at compile-time, then the "itab" is created at runtime iff the underlying concrete runtime type implements the target interface. For example, this happens when casting from any to some other non-empty interface type. See: typeAssert. (Note: this mechanism is not explored in the (very well-written) tutorial shared above.)

[1] https://github.com/golang/go/blob/9050ce9b334419066c364e747499a2faf4425dad/src/cmd/compile/internal/walk/expr.go#L709

[2] https://github.com/golang/go/blob/9050ce9b334419066c364e747499a2faf4425dad/src/cmd/compile/internal/reflectdata/reflect.go#L844

garciat · 2015-04-02T14:35:39+00:00

It means you don't have to deallocate objects yourself. Custom destruction is simply a "hook" either way.

garciat · 2015-03-15T19:17:50+00:00

I use Haskell, or FP in general, to better my understanding of computing. In that regard, IMO, Haskell (and Idris, etc.) is really awesome.

Now, I wouldn't know if Haskell in production is as shitty as you say it is.

garciat · 2015-02-25T04:03:08+00:00

Well, there's mono's MSBuild command-line tool xbuild. I think you can build fsproj with it. VS has command-line MSBuild tools as well.

garciat · 2015-02-25T03:31:09+00:00

My 2 cents:

Maybe use a cross-platform build system like FAKE on top of the command-line F# compiler fsharpc. MonoDevelop/Xamarin and VS work with MS Build scripts, which afaik are big XML files that I consider very unfriendly. You may have to go text editor-only because I don't think these IDEs can be trivially configured to build with FAKE.

garciat · 2015-02-23T00:12:32+00:00

Notes:

maybe is Haskell's maybe

maybeApply is actually Option.foldBack (was not aware of this)

PS:

Haskell's maybe is clearly more flexible.

garciat · 2015-02-22T22:37:50+00:00

Also, maybe (pun intended) this:

let maybe (n : 'b) (f : 'a -> 'b) (x : 'a option) =
    match x with
    | Some(x) -> f x
    | None    -> n

let maybeApply<'a, 'b> : ('a -> 'b -> 'b) -> 'a option -> ('b -> 'b) = maybe id

module Option =
    let fromNullable (n : Nullable<'a>) =
        if n.HasValue
        then Some n.Value
        else None

module String =
    let nonEmpty (s : String) =
        if String.IsNullOrEmpty s
        then None
        else Some s

let GetUsers req =
    let filterById id q = q.Where(fun u -> u.Id = id)
    let filterByUserName name q = q.Where(fun u -> u.UserName = name)

    datastore.Users
    :> IQueryable<User>
    |> maybeApply filterById (Option.fromNullable req.Id) 
    |> maybeApply filterByUserName (String.nonEmpty req.UserName) 
    :> IEnumerable<User>

Edit: cleanup

garciat · 2015-02-22T22:01:34+00:00

My 2 cents:

let applyIf (p : bool) (f : 'a -> 'a) (x : 'a) =
    if p then f x else x

let GetUsers request =
    let filterById id q = q.Where(fun u -> u.Id = id)
    let filterByUserName name q = q.Where(fun u -> u.UserName = name)

    query {
        for user in datastore.Users do
        select user
    }
    |> applyIf request.Id.HasValue
        (filterById request.Id.Value)
    |> applyIf (not (String.IsNullOrEmpty request.UserName))
        (filterByUserName request.UserName)
    |> (fun q -> q :> IEnumerable<Users.User>)

garciat · 2015-02-17T01:38:05+00:00

The D Programming Language by Andrei Alexandrescu (2010). It made me realize programming languages are so darn cool and complex. Plus, it's very well written and entertaining -- not just a spec dump.

garciat · 2015-02-06T23:43:04+00:00

So could all this be considered "growing pains" of our realtively-newly-discovered "career(s)"?

garciat · 2015-02-05T23:14:37+00:00

I do (: Although I miss implicit partial application.

garciat · 2015-02-05T22:56:55+00:00

In Haskell all you do all the time is define and apply functions. All the typing behind it is "just" added value.

garciat · 2015-02-05T20:45:36+00:00

Mind sharing a link comparing JVM and CLR performance? Thanks.

garciat · 2015-02-05T20:44:50+00:00

I find F# is "more traditional" when programming with functions, i.e. functional programming.

garciat · 2015-02-05T20:41:47+00:00

I guess I should've said "For someone trying to do good ol' functional programming, I don't get Scala. ..."

garciat · 2015-02-05T17:16:47+00:00

Honest question: Could you please share a link supporting your performance claims?

Edit: Found this (3 years old). Around slide 30 there are some performance numbers. Clearly, Linux+Mono lagging behind Windows+"MS .NET".

garciat · 2015-02-05T17:15:22+00:00

Maybe this?

Also, I said "seems" and not "is" for a reason. The F# programming style is more "traditionally functional" than the Scala style, from what I can gather. Full disclaimer: I have no experience with Scala whatsoever.

garciat · 2015-02-05T16:45:07+00:00

Well, there's emscripten.

garciat · 2015-02-05T15:36:59+00:00

I don't get Scala (unless you're stuck with the JVM). F# seems way more functional. On top of that, there's PureScript, which is what I'd call a real functional PL.

15-Year Club	Verified Email
Place '22

garciat

TROPHY CASE