[racket-dev] exact nonnegative integers as sequences?

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