[racket-dev] Fancy application/automatic anonymous functions

From: Eli Barzilay (eli at barzilay.org)
Date: Tue May 17 19:38:08 EDT 2011

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!



Posted on the dev mailing list.