[racket] Lazy take is the identity?

I'm completely agreeing you on this. In some special cases you might
consider applying it in your own code (and not tell anybody :), but
definitely not in the source functions to be distibuted and documented. It
could get wild after a while.

I was experimenting with it to understand how it works, in case I might need
it when planning on visual programming concept. Doing some things
automatically and hidden from the user
- searching for functions that might be dealing with objects that I'm
interested
- some fault tolerance in the order of how the arguments are to be used
- Suggesting automatic format conversions (e.g. path><string,
celsius><fahrenheit...)
- Composing results from two or more intermediate helper functions to fill
in caps of programs
...

br, jukka

> -----Original Message-----
> From: Eli Barzilay [mailto:eli at barzilay.org]
> Sent: 30 January 2011 23:34
> To: Jukka Tuominen
> Cc: users at lists.racket-lang.org
> Subject: Re: [racket] Lazy take is the identity?
>
>
> About a minute ago, Jukka Tuominen wrote:
> >
> > Hi,
> >
> > a funny coincidence. I was just experimenting with ". args" a few
> > days ago - the number and order of arguments, that is. I tried it on
> > "filter" since I always seem to forget the order of arguments.
> >
> > (define (my-filter . args);; ignores the order of arguments
> >  (filter (car (filter procedure? args)) (car (filter list? args))))
> >
> > (my-filter number? '( 1 a 2 b))   >> (1 2)
> > (my-filter '( 1 a 2 b)  number?)  >> (1 2)
> >
> > I'm not seriously suggesting to use this hack, just a funny
> > coincidence...
>
> I've tried something like this in the past, and overall my experience
> is that it leads to a mess.  Some of the problems:
>
> * People won't rely on both variations working, and will want to know
>   what's the "blessed" way.  Related to this is the problem of
>   documenting it.  (IMO this is a case where the difficulty in making
>   a good documentation corresponds to a bad function design.)
>
> * Much easier to get confusing errors.
>
> * You need to check that you have the right number of arguments, for
>   example -- your code will make this work:
>
>     (my-filter 'bogus number? "bogus" '(1 2 3) 123)
>
> * Also there's a question of how to deal with extending the function
>   -- what if the extension needs two lists?
>
> * Finally, all of this is worse in a lazy language -- where you can't
>   even check the types of the inputs without forcing them, so for
>   something like `take' you won't be able to make it so
>   (take 0 (error)) will not throw an error.
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!