(Replying to PARENT post)

How in the world do typeclasses work in Hoon?
๐Ÿ‘คtel๐Ÿ•‘10y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

I don't think Hoon's type system actually has a typeclass analogue. As far as I could tell, what it has is something like generics, but in a world where everything is ultimately a noun. IIRC, a previous iteration of the docs explained that "wet gates" (generic functions) are actually required to compile down to the same Nock when "instantiated" at a particular argument, modulo dead code elimination. Didn't look much like ad-hoc polymorphism to me.

A good example is Hoon's maps[1]. They're parameterized on type, but I'm pretty sure those types can't affect the runtime behavior by, say, specifying their own hash or comparison function. Instead, the map implementation[2] hardwires a couple of specific comparison functions[3] that effectively toss the type information and work in terms of the raw underlying nouns.

It is kind of weird that every type carves out a subset of nouns, even function types (or function "molds" or "spans" or whatever... I'll stop calling them types when the Urbit people stop calling it a type system). Hoon's C-flavor really shows when it makes the likes of strlen((char*)strlen) expressible in a purely functional way.

[1]: https://github.com/urbit/urbit/blob/7186219/urb/zod/arvo/hoo...

[2]: https://github.com/urbit/urbit/blob/7186219/urb/zod/arvo/hoo...

[3]: https://github.com/urbit/urbit/blob/7186219/urb/zod/arvo/hoo...

๐Ÿ‘คloqi๐Ÿ•‘10y๐Ÿ”ผ0๐Ÿ—จ๏ธ0