I have a question regarding the application operator (space). One the
one hand, this notion is quite neat, but on the other hand - it can
introduce closures - perhaps unintended ones. I'm not sure where you are
going with all of this, but I think it is important to notice that this
feature brings in things that is not obvious from the code.
In a C-like syntax, the OCaml function
let f x y : int -> int -> int = ...
Really should be thought of as (curried)
int f(int x)(int y) { ... }
and not as:
int f(int x, int y) { ... }
Since it is perfectly fine to write "f 2", creating the closure:
let g = fun y -> f 2 y
Would it not be possible to insist on the non-curried syntax, but
instead introduce some syntax in order to create these closures? If that
syntax was not too intrusive, I would think that we could live without
the curried application. As for an example, if one used wild cards:
f 2 _ => fun y -> f 2 y // y would be a generated identifier.
f _ _ => fun x y -> f x y
Another benefit (besides having better control of where closures are
created), is that the arity is known. As a matter of fact, now the
argument really is just like a tuple, or even a record with labeled
arguments, hence greatly simplifying syntax and type-checking. Has
anyone taken a piece of code that uses higher order functions and tried
to see what an impact it has on the code? It occurs to me that optional
arguments and labeled arguments is quite trivial with fixed procedure
arguments.
Thanks,
PKE.
--
Pål-Kristian Engstad ([email protected]),
Lead Graphics & Engine Programmer,
Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.
"Emacs would be a far better OS if it was shipped with
a halfway-decent text editor." -- Slashdot, Dec 13. 2005.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
