Lambda the Ultimate

>>> def foo(n):

... return lambda i: n+i

Updated: as Manuel Simoni has pointed out, I obviously wasn't paying attention when I wrote this -_- ....

>> Note: (a) that's number, not integer, (b) that's incremented by, not plus. <<

This is an interesting study of solutions to an ill-defined problem.

1. The term "number" is left undefined. If the problem we posed in terms of "integers" or "natural numbers", it would be clear. Are complex numbers, numbers? Are p-adics and reals, numbers? If you define "number" to include all of these different mathematical objects, then the problem is ill-typed because, for example, you can't add a p-adic to a real. The problem doesn't define what should happen in this case; should it crash? Return 7*pi?

2. You can't "increment a number". Adding 2 to 3 doesn't change the value of 3! 3 still remains 3. Numbers, as defined by mathematics sense, are immutable. One might correct this by indicating that your function should take a reference to an integer, and add a certain integer to the value referred to. But is such a function actually a function? Not in the mathematical sense. What about the case where the reference is null, if the language supports such a concept?

What the article did succeed in doing, if you read through the code examples, is highlight the non-portability (across languages) of programs depending on ill-defined concepts like "references" and "numbers". The problem as posed can't be solved minimally (with neither error cases nor behaviour beyond what is specified) in any of the languages shown!

-Tim

BTW somebody from the Mozart team better get a more palatable sample on that page quick. What a mess!

Erlang: Yes! Maybe this will get people to realize just how lightweight their processes are.

> The term "number" is left undefined.

On the companion page, accgensub.html, "number" is somewhat defined: Works for any numeric type-- i.e. can take both ints and floats and returns functions that can take both ints and floats.

It's probably supposed to be an abstract data type that supports the + message, and not a pure mathematical number. It is right that nothing is said about the paradigm used to describe the situation (for example message-passing paradigm.)

> the Python version he has is just plain silly

I do not know Python, but it seems to me that def foo(n): return lambda i: n+i would violate point 3 on the companion page (Generates functions that return the sum of every number ever passed to them, not just the most recent.) because n is never incremented.

A couple of Tcl solutions (http://mini.net/tcl/3520) were turned down (for unclear reasons), so I imagine that the interpretation of the requirements are subject to Graham's tastes.

# let comp x y = x < y;;
val comp : 'a -> 'a -> bool = <fun>
# comp 1 2;;
- : bool = true
# comp 1.2 2.2;;
- : bool = true

# comp 1 1.0;;
Characters 7-10:
  comp 1 1.0;;
         ^^^
This expression has type float but is here used with type int


# 1 + 1.0 ;;
Characters 4-7:
  1 + 1.0 ;;
      ^^^
This expression has type float but is here used with type int

Oh, I see, Ruiner was pointing out that int and float use the same relational operators < > = but use different arithmetic operators: + * for int but +. *. for float

let foo n = let x = ref n in function i -> x := !x + i; !x;;

It would be convenient if operators and functions could be overloaded in ocaml. But at the same time I still have not the feeling that it makes that much difference in practice. However, I understand someone has implemented this. But I can't tell if it will ever be incorporated into the language.

Why would that help with accumlator generator? As far as I can see, int < int is valid, float < float is valid, but int < float is invalid. So even if + supported the same sort of overloading as <, wouldn't int + float be invalid?

   generic plus = case
   | int -> int -> int => (+)
   | float -> float -> float => (+.)
   | int -> float -> float => fun x y -> float x +. y
   | float -> int -> float => fun x y -> x +. float y
   ...