> > Maybe you'll need to clarify what Racket2 is? I am not familiar.
Racket2 is the (unofficial) name of what Racket could hypothetically be if we made lots of breaking changes to the existing APIs. It's named that because it would likely mean creating a `#lang racket2` language with all of the new APIs instead of breaking existing code that uses `#lang racket`. (define tuple/c list/c) > The key to list/c and listof is that the code inside of > functions contracted with either of them can use map > and filter and everything else to process the arguments. Due to the kind of data that would go in tuples - namely, a fixed-sized heterogeneous collection of values - a function probably *shouldn't* use map and filter to process tuples. A program that calls filter on an x-y-z coordinate tuple is likely incorrect and not what the programmer intended. The same is true for a function that calls map on a tuple containing many wildly different kinds of data. Well also, I thought `list/c` already means "tuple"? > > (listof number?) is a list of many numbers. > (list/c number?) is a list of one number. > And this has tripped me up numerous times. I often forget which is the one I meant to use and have to look it up in the docs, assuming I even notice I used the wrong one. With distinct list and tuple types, these two contracts could be named `list/c` and `tuple/c` and we wouldn't need this strange "foo-collection/c vs foo-collectionof" distinction in our contract combinators. Tables are pretty cool! > https://www.pyret.org/docs/latest/tables.html I love this idea. On Thu, Jan 24, 2019 at 11:20 AM Matthias Felleisen <matth...@felleisen.org> wrote: > > (define tuple/c list/c) > > The key to list/c and listof is that the code inside of > functions contracted with either of them can use map > and filter and everything else to process the arguments. > > > > > On Jan 24, 2019, at 8:33 AM, Gustavo Massaccesi <gust...@oma.org.ar> > wrote: > > > > I also like the idea of a contract like "tuple/c", perhaps with a more > rackety name. > > > > Gustavo > > > > On Wed, Jan 23, 2019 at 12:02 PM Greg Hendershott < > greghendersh...@gmail.com> wrote: > > >> - A separation between using lists as homogeneous collections and > using lists as fixed-size tuples. So there'd be a separate `tuple?` data > type that's structurally equivalent to a list but meant to be used > differently. For example, `(list/c number?)` would mean a list of many > numbers, but `(tuple/c number?)` would mean a tuple of size 1 containing a > number. > > > > > > "It is better to have 100 functions operate on one data structure than > 10 functions on 10 data structures.” > http://www.cs.yale.edu/homes/perlis-alan/quotes.html > > > "It is better to have 100 transducers operate on one data structure > interface than 10 functions on 10 data structures.” Rich Hickey, History of > Clojure > > > > Well also, I thought `list/c` already means "tuple"? > > > > (listof number?) is a list of many numbers. > > (list/c number?) is a list of one number. > > > > > > I think it's within the Racket spirit to make a little #lang for > > certain audiences or projects. At some org, "tuple/c" might be a > > helpful alias. Or, for some other team, it's not, and in fact even > > "list/c" is redefined to raise an error, "Please use structs instead > > of ad hoc tuples." > > > > -- > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
