[racket-dev] Fancy application/automatic anonymous functions

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Tue May 17 22:52:31 EDT 2011

I second Eli on a second level. 

As much as I think that syntactic simplicity helps a lot of languages, 
I don't think this particular kind of simplicity is a major problem or 
even worth our attention. 

For a while I decided to try point-free programming. You can do it in 
Racket as well as in Haskell. Then I ran across someone's rules for 
writing Scheme and he had written 

 (lambda (n) (+ x n)) 

is just as readable if not more than 

 (curry + x)

and often (not here) it is shorter. I tested it in my project and he's

Let's not play with these little things. Let's get Typed and Lazy and
their interaction with Racket right. 

On May 17, 2011, at 7:38 PM, Eli Barzilay wrote:

> 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!
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev

Posted on the dev mailing list.