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