Higher order functions vs. function arity and calling conventions
Languages like CL or Scheme may have complex lambda lists, but still have a single "calling convention."
OTOH, Haskell, just for example, supports multiple arity functions via a single tuple argument or via curried function definitions.
So now we look a some function like map, or say map/2 if arity overloading is not allowed. Let's presume that map/2 is a curried function. We might call it like this.
Now, should plus here be a curried function or a function that takes a tuple of two arguments?
This is NOT a "factual" question about Haskell specifically.
I'm more interested in how higher order functions might or might not support functions of multiple "calling conventions" (more below) in some more or less elegant manner. Should the "calling convention" be considered part of the type of the function and a kind of "type parameter" of higher order functions like map/2 above?
Just for the sake of argument, imagine that we supported a variety of calling conventions typical of the Windows and some C compilers - fastcall, c, pascal, stdcall, etc. - that are language level keywords.
Can we imagine a function type signature such as:
Presumably this is no longer "really" a curried function, and we might devise some other syntax to make this more clear, something like:
My point is to show that a more flexible language with regard to calling convention, here facilitating direct integration with OS supported calling conventions, further complicates cleanly implementing simple higher order functions like map or filter or any? or every? or foldl and so on - unless I'm missing something (which I hope I am).
Any words of wisdom on defining/implementing higher order functions (and compiling these) in the face of multiple language supported calling conventions?
Active forum topics
New forum topics