>>17In Haskell, you have to write an
fmap implementation for every datastructure. It's called "typeclasses" -
fmap is a typeclass method and if you want a type to become a member of that typeclass, you provide an implementation of
fmap for that specific type. It's kind of like virtual methods in Sepples but more efficient because static. Most of method resolution happens at compile time as opposed to C++ where there's a runtime v-table indirection for every virtual call.
i.e. its giant switch with all thousands of possible structures and object or its some interface to iterators
More like the latter. Basically, for every type there's a compile-time dictionary of function pointers and when the typechecker figures out the type of the thing
fmap is applied to, it chooses the right dictionary and substitutes
fmap with the function from that dictionary (fmap_hashmap or fmap_treenode or whatever). Then sometimes it has to keep that dictionary until runtime and then it's pretty much v-tables - you can simulate C++ objects in Haskell like that.
If fmap doesn't look mindblowing to you, then I guess you could implement folds too. Then you could do lazy evaluation, obviously. So probably the only thing preventing a Haskell in C macros is that you'd have to write a GC implementation there.