Thanks for the clarifications, and I now agree that it's not about genericity.
I think it's about scripts to programs, though. In a script, not having to type `(in-range ....)' or `(in-list ....)' feels worthwhile. You make a good point that those scriptish shortcuts can make understanding the code a little harder, and using `in-range' or `in-list' can good for long-term maintenance. Still, I think it's better to allow the shortcuts. At Mon, 18 Apr 2011 08:58:32 -0500, Robby Findler wrote: > On Mon, Apr 18, 2011 at 8:52 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > > At Mon, 18 Apr 2011 08:34:34 -0500, Robby Findler wrote: > >> FWIW, I don't like that any of these 'in-*' thigns are optional. I was > >> recently reading over a script that was used to build web pages from > >> the output of testing runs for my compilers class and there were > >> several nested for loops without in-* thingies and it was painfully > >> difficult for me to reconstruct what the contracts of the functions > >> were because of that. > > > > Was the contract just "sequence", or did the values that were used as > > sequences in `for' also flow to places with more specific contracts? > > These were not generic. The program didn't work unless the input was > an sexp with a particular structure (a table mapping names to outputs > and outputs and names were something specific too). > > > (We probably agree that generic programming is good, so I'm trying to > > understand why it seemed counterproductive in your example.) > > > I agree about generic programming a general sense, but I'm not sure > about generic programming in this particular place: do you think that > there are many for loops out there there is no specific 'in-*' to put > in there? (And if there were, maybe it would be better to use a > keyword to say that explicitly?) > > Matthias even says this implicitly in his message: I doubt he lets > lists be bound to "N" for example. So I don't think that this is about > generic programming. > > I also don't buy Sam's implicit argument for my example. If I had > tried to port this to code to typed racket to just read off the types, > I would have spent far longer as debugging via TR's error messages is > going to be less productive than debugging via tracing the flow of > values in the program. > > Robby _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
