[racket-dev] Fancy application/automatic anonymous functions

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
right. 

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