3 ms·
> only to find this bad boi: https://www.scala-lang.org/api/current/scala/Function22.html https://www.scala-lang.org/api/current/scala/Function22.html Dang. I
by fmakunbound 6y ago
> only to find this bad boi: https://www.scala-lang.org/api/current/scala/Function22.html https://www.scala-lang.org/api/current/scala/Function22.html
Dang. I just checked in the Common Lisp I use and it's a bit higher. What's the reason for having to have at least 22 concrete function signatures like that?
CL-USER> call-arguments-limit
4611686018427387903 (62 bits, #x3FFFFFFFFFFFFFFF)
- rbonvall 6y agoOriginally there was no way of abstracting over an arbitrary number of type parameters in the language, so a different trait was required for each arity. The choice of 22 was arbitrary, I think. This is no longer true in Scala 3, so there will be no such limit: http://dotty.epfl.ch/docs/reference/dropped-features/limit22.html http://dotty.epfl.ch/docs/reference/dropped-features/limit22...
- lmm 6y agoThe JVM had no support for functions as values (it was designed around the idea of only having objects with methods). So if you want to very closely mirror Java at runtime (e.g. you want Java reflection libraries to work with your language) but you want to use functions as values, you have to bridge that gap with classes whose instances will represent functions.
- didibus 6y agoIt's for optimization, at run-time you could handle functions with more arguments, but with this it can be compiled to directly call the exact function based on the number of arguments statically used at the call-site and their type. To do this though, you need a defined static type for the type of Functions each of a different number of arguments. 22 is just where they stopped to keep defining those types.