I don't intend to make these operations impossible or even difficult. One of the other things on my wishlist is a transducers library, which would IMO be a good fit for a lot of the logic that Racket currently provides as list-processing functions. So if you want to process tuples as generalized streams of values, you'd use transducers on them. But if you want to process tuples as *tuples*, you'd use tuple-processing functions. I think mapping and filtering fit the first category more than the second. This kind of divide makes it much easier to support a wide array of data structures without copying the entire list processing API for each one.
On Fri, Jan 25, 2019 at 12:51 PM Matthias Felleisen <matth...@felleisen.org> wrote: > > > On Jan 25, 2019, at 3:46 PM, Thomas F. Burdick <tho...@burdick.fr> > wrote: > > > > > > > > On January 25, 2019 8:33:09 PM GMT+01:00, Jack Firth < > jackhfi...@gmail.com> wrote: > >> > >> 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. > > > > Funny you should pick that as an example. I work in a CAD environment > where points are two-item lists, and polygon outlines are lists of points. > You'd be surprised how often it's useful to use ordinary list functions on > points. > > > That’s precisely the kind of programming I had in mind. Racket is one of > the few languages where you can eat your cake and have it anyways. Why take > away that strength? -- 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.
