Matthias, where can I find this "History of Clojure"? I searched for "It is better to have 100 transducers ..." and found no result (besides this very thread). I also searched for "History of Clojure" and only found this tweet <https://twitter.com/richhickey/status/1058083678029537283> from Rich Hickey in Nov 2018, and it seems he was still writing it back then. Is it available for public to view now?
If we take an argument that we can encode a tuple with a list and get all benefits from list operations, why don't we (define-values (bool/c true false) (values int/c 1 0))? Why don't we (Church) encode everything to lambdas? On Friday, January 25, 2019 at 4:51:10 PM UTC-8, Matthias Felleisen wrote: > > > Yes. See Clojure history. — Matthias > > > > On Jan 25, 2019, at 4:21 PM, Jack Firth <jackh...@gmail.com <javascript:>> > wrote: > > 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 <matt...@felleisen.org > <javascript:>> wrote: > >> >> > On Jan 25, 2019, at 3:46 PM, Thomas F. Burdick <tho...@burdick.fr >> <javascript:>> wrote: >> > >> > >> > >> > On January 25, 2019 8:33:09 PM GMT+01:00, Jack Firth < >> jackh...@gmail.com <javascript:>> 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.
