[loup-vaillant]

Vararg functions also have limited use. Especially considering that most of the time, your args will all have the same type, and therefore could just be passed in an array or similar. The one mainstream exception I know of is print functions, and we have* ways to statically check those.

Your toy example, even generalised, has no practical use. If I can write this:

  compose(f, f1, f2, f3)

Then I can write that instead (Haskell):

  f . f3 . f2 . f1

Or this (F#):

  f1 |- f2 |- f3 |- f

And now we’ve reduced the problem to a simple function composition, which is very easy to define (Ocaml):

  let (|-) f g = fun x -> g (f x)
  (|-): (’a -> ’b) -> (’b -> ’c) -> (’a -> ’c)

This generalises to any fold where the programmer would provide the list statically (as they always would for a vararg function): instead of trying to type the whole thing, just define & type the underlying binary operation.

[skrimp]

This still technically reduces the generality of the given function since you are specifying that each function cannot have multiple overloads.

let f be a overload set matching the signatures {a -> b, i -> j} let g be a overload set matching the signatures {b -> c, j -> k}

compose(g, f) could be given a to return c or i to return k

[loup-vaillant]

> This still technically reduces the generality of the given function

My point was that we are almost never hurt by that reduction.

> you are specifying that each function cannot have multiple overloads

Haskell has type classes, and if we restrict ourselves to local type inference it's fairly easy to have C++ style overloads without even that. So no, I'm not specifying such a thing.

[fiddlerwoaroof]

> Vararg functions also have limited use.

This is only because people are using statically typed language that place arbitrary restrictions on such functions and make them harder to use. In dynamically typed languages, vararg functions are widely used and enable patterns that are pretty nice.

[loup-vaillant]

Perhaps. But then I want to know what those patterns are, what are their actual benefits compared to not using them, and most of all I want to know if such benefits outweigh the significant costs that comes with the lack of static analysis¹.

[1] The need to test much more, the need for a better, more accurate documentation, the higher cost of refactoring, even the higher prototyping times (I prototype faster with a REPL that has static typing, because I don't to debug type errors).

[fiddlerwoaroof]

> I prototype faster with a REPL that has static typing, because I don't to debug type errors

On the other hand, because Common Lisp has resumable exceptions and on-the-fly redefinition of just about everything, I prototype significantly faster in CL because I can just let the debugger stay open until I fix the issue and then hit “continue”.

I no longer believe the “static faster for development than dynamic” thesis because I think a lot depends on how the programmer thinks about programming and which tools are available.

[loup-vaillant]

Yeah, I've heard about image based programming, that enables editing your program as you run it. It scares the shit out of me.

See, if I have an unexpected error, that's because I fucked up my program. And because of that, my runtime state is likely screwed as well. So not only do I have to correct my error, I have to correct its consequences before I restart the program. I can't just resume its execution and hope for the best, I need to know that whatever state I keep is not rotten.

On the other hand, that way of doing things is not exclusive to dynamic languages. There's thing things called "dynamically loaded libraries", that you can use even in C. Game programmers routinely recompile & reload specific dlls just so they can correct their mistakes without restarting the whole game. And those who have written in-game editors have a very powerful stop-debug-restart cycle. On top of a statically typed language.