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:[email protected]] > Sent: 30 January 2011 23:34 > To: Jukka Tuominen > Cc: [email protected] > 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! _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
