I don't agree with this rationale, but I do agree with your conclusion. Let me explain.
Here's what I think, wrt to scripting and Racket: the essential parts of Racket are generally biased away from scripting. For example, we have both multiple values and lists as ways to package up results from functions (and the core libraries do both); a scripting language would not have the overhead on the programmer to figure out which is which (a non-scripting language might if there were interesting information conveyed there). We also have, by default, generative structs and we encourage their use. A scripting language would use hash tables with symbols as keys or something instead, both to better encourage generic traversals and to allow things throwing extra stuff into a struct instance without having to change the declaration. There are probably more examples like that where we err away from scriptingy-type stuff (just the idea that we have lists & vectors at all, instead of hashes that map from integer indicies possibly). In this particular case of for loops, I think that the scripty damage has already been done. Since we allow lists, hashes, vectors, etc. to all appear in for loops without an appropriate 'in-*' qualifier, it seems silly to not allow something like that for integer ranges. (Too bad for me.) Which also raises an idea: now that TR is getting going, maybe we should have another step on this scripts-to-programs slope that is _lower_ than Racket. A language where we really only have one single datatype and "everything just works" on it, hashes being the obvious one (altho we probably should not _call_ them hashes; we should call them "the scracket value" or something). Then, you can go from there to Racket by declaring that this scracket value is really that struct, whereas this one is really an array, and do conversion on the boundaries based on these declarations (where we, of course, provide all those declarations for the standard libraries and have a mode in the documentation that renders things as scracket values). Robby On Mon, Apr 18, 2011 at 9:47 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > 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
