[racket-dev] Fancy application/automatic anonymous functions
Four hours ago, Sam Tobin-Hochstadt wrote:
> I prefer this over `scut' for two reasons. (1) It makes the simple
> cases simpler: you don't have to name anything. (2) It doesn't try
> to handle the more complicated cases, which I think is a good thing.
> Things that are implicit should either always do the right thing, or
> just do something simple.
That's a cute point (couldn't avoid the pun), which might work if it
really covers the majority of cases. (That is, it works if 90% of the
uses of `cut'/`cute'/`scut'/`scut*' are covered.)
But:
1. `_' is IMO too commonly used for a "dummy", and it's probably only
a matter of time before it's used as such in function arguments so
you can do (λ (_ _) (+ 1 2)). Technically there is no
contradiction, but it'll make (λ (_) (+ _ 1)) extremely confusing.
2. Worse, this is already used now in macros, so something like
(define-syntax-rule (foo _) (+ _ 2))
((foo 3) 10)
already suffers from this.
*. Given those two, I think something other than `_' should be used.
3. But a much worse problem is that it works only for applications.
Right now, I can do:
(define-syntax my+
(syntax-id-rules ()
[(_ x 0) x]
[(_ 0 x) x]
[(_ . xs) (+ . xs)]
[_ +])) ; (yes, that's not consistent, just making a point)
and pretend that `my+' is a plain function. But with your
extension the implementation as a macro is exposed in a bad way.
If that looks too cooked, consider this:
(define f (new frame% [label "Foo"]))
(send f show _)
(And while you're here, consider also (new frame% [label _]).)
*. Given these, I think that something more primitive is needed, like
a reader syntax. (For example, that's what I did when PG wanted
something similar for arc.)
4. Redefining `lambda' is easy. Remembering to redefine `λ' too adds
a small overhead. Dealing with the `define' syntactic sugar makes
it a major PITA, that in most cases is just not done. Even if you
do, you really need to also deal with other define forms if you
have any, further complicating it.
This is relevant here, since your extension leads to another layer
of headaches. For example, it could lead to plain lambdas leaking
into lazy code. So your extension is not free -- it means that any
code that redefines `lambda' should be modified `lazy' should be
modified, it means that my class languages need to be modified,
etc.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!