Arc Forumnew | comments | leaders | submitlogin
3 points by almkglor 6103 days ago | link | parent

How does Ocaml handle currying and optional arguments? How about "rest" arguments?

I liked currying in Haskell, the only problem I see in a Lisplike is macros. Since macros in Arc are simply functions, then currying must be disabled for them, since (def foo) is obviously an error.



1 point by Loup 6103 days ago | link

Optional arguments in Ocaml are labelled (if I remember correctly). They're not used much.

About "rest" arguments, take a look at this (incomplete) definition of +, where prim+ is the primitive definition of +.

(def + (x y @rest) (foldl (prim+) (prim+ x y) rest))

(Is the "@" to denote "rest"?)

Then: (+) => +

(+ 42) => (fn (x) (foldl (prim+) (prim+ 42 x) ())) => (fn (x) (prim+ 42 x))

(+ 42 24) => (foldl (prim+) (prim+ 42 24) ()) => 66

(+ 42 24 34) => (foldl (prim+) (prim+ 42 24) '(66)) => 100

This principle can be generalized to any function with a "rest", and to any function with optional arguments (provided they are at the end of the argument list).

Yes, currying should be disabled with macros. But they already are. Macro aren't plain functions. They can't be, with their special evaluation scheme. What is true is that macros and functions from list to lists are isomorphic. So, if I define a macro whose result is an integer, I bet the compiler will kindly notify my blunder when trying to make a list from this integer (right?). Same thing if the macro yields a function. So, any partial application in macro will automatically result in an error, and that particular error should be caught at parse/compile time by any descent Arc compiler.

-----

3 points by absz 6103 days ago | link

Except the primitive definition of + is still variadic. Any function declared as

  (def foo args
    (munge (frob args)))
will be uncurriable, which is the problem.

-----

1 point by almkglor 6103 days ago | link

> So, if I define a macro whose result is an integer, I bet the compiler will kindly notify my blunder when trying to make a list from this integer (right?). Same thing if the macro yields a function.

No, it won't. Because a macro returns an object which is inserted into the code. It's usually a list, but not always. It can be an integer, it can be a function object, and unfortunately the underlying mzscheme doesn't allow tables.

-----