Investigate `InternalListFunc`

[B-rando1]

I was looking again at the List typeclass of GOOL/GProc, and just wondering if we could simplify how it's implemented.

Take, for example, Java's implementation of listAppend:

• Java's listAppend calls G.listAppend
• G.listAppend calls Java's listAppendFunc from InternalListFunc typeclass
• Java's listAppendFunc calls G.listAppendFunc

All that for a simple method call! E.g. an alternate definition could be listAppend l v = objMethodCall void l "add" [v]

This happens for a lot of the implementations of a lot of the List API. It feels like it goes in circles, making it pretty hard to understand how a very simple piece of code is actually created. I'm not saying we shouldn't abstract from the exact implementation (e.g. we shouldn't have to use objMethodCall in every renderer), but I feel like we might have gone too far.

I wonder if we would be better off getting rid of InternalListFunc (or at least most of its methods), and instead do something like:

In CommonPseudoOO.hs, add a listAppend n l v = objMethodCall void l n [v], and in Java have listAppend = CP.listAppend "add"

That still gives the level of abstraction and flexibility that we want, without having the function calls bounce back and forth as much as they currently do.

Is this a change that would be helpful? It might also apply to sets, as the set implementation was heavily based on the list implementation.

[JacquesCarette]

Indeed, the high-level APIs have suffered from too much ad hoc evolution. I think this is because "lists" are rendered in all sorts of different ways in different languages. For languages where lists are objects, I'm sure your suggestions above are good.