[racket-dev] exact nonnegative integers as sequences?

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 <mflatt at 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