Re: [racket-users] Collections and data structures wishlist?

[Jesse Alama]

On 26 Jan 2019, at 15:39, Hendrik Boom wrote:


On Sat, Jan 26, 2019 at 09:19:11AM -0500, Matthias Felleisen wrote:


On Jan 26, 2019, at 9:03 AM, Sorawee Porncharoenwase 
 wrote:


Matthias, where can I find this "History of Clojure"? I searched for
"It is better to have 100 transducers ..."


I'd love even to know what he *meant* by that.  I always thought 10x10
made for more modularity.


I'm pretty sure he was just riffing on the same Perlis theme we know, 
repackaged for a Clojure audience 
(https://clojure.org/reference/transducers). IIRC the Clojure community 
went through a phase a few years ago where transducers were all the 
rage.


--
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.

Re: [racket-users] Collections and data structures wishlist?

[Hendrik Boom]

On Sat, Jan 26, 2019 at 09:19:11AM -0500, Matthias Felleisen wrote:
> 
> > On Jan 26, 2019, at 9:03 AM, Sorawee Porncharoenwase 
> >  wrote:
> > 
> > Matthias, where can I find this "History of Clojure"? I searched for 
> > "It is better to have 100 transducers ..."

I'd love even to know what he *meant* by that.  I always thought 10x10 
made for more modularity.

> > and found no result (besides this very thread). I also searched for 
> > "History of Clojure" and only found this tweet 
> >  from Rich 
> > Hickey in Nov 2018, and it seems he was still writing it back then. 
> > Is it available for public to view now?
> > 
> 
> 
> Unpublished notes. But I believe he said something like that during 
> his StrangeLoop presentation of transducers in Clojure. 
> 
> 
> > 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?
> 
> 
> Functions are infinite data, lists are finite.

The theoretical difference between the two lies in the Turing 
undecidability theorems.
Functions in Racket are, however, finitely represented.

The practical difference lies in efficiency.

> You need to develop good taste for good compromises. 
> 
> I am the one who pushed PLT Scheme/Racket into the static corner 
> (e.g., structs). But the place in the middle is where the sweet spot 
> is. 

The Buddha's middle way.

Everything in moderation, even moderation in moderation.

-- hendrik

> 
> — Matthias, radical centrist with nuanced opinions often stated in 
> provocative ways :) 
> 

-- 
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.

Re: [racket-users] Collections and data structures wishlist?

[Matthias Felleisen]

> On Jan 26, 2019, at 9:03 AM, Sorawee Porncharoenwase 
>  wrote:
> 
> 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 
>  from Rich Hickey 
> in Nov 2018, and it seems he was still writing it back then. Is it available 
> for public to view now?
> 


Unpublished notes. But I believe he said something like that during his 
StrangeLoop presentation of transducers in Clojure. 


> 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?


Functions are infinite data, lists are finite. You need to develop good taste 
for good compromises. 

I am the one who pushed PLT Scheme/Racket into the static corner (e.g., 
structs). But the place in the middle is where the sweet spot is. 

— Matthias, radical centrist with nuanced opinions often stated in provocative 
ways :) 

-- 
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.

Re: [racket-users] Collections and data structures wishlist?

[Sorawee Porncharoenwase]

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 
 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 > 
> 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  > wrote:
>
>>
>> > On Jan 25, 2019, at 3:46 PM, Thomas F. Burdick > > wrote:
>> > 
>> > 
>> > 
>> > On January 25, 2019 8:33:09 PM GMT+01:00, Jack Firth <
>> jackh...@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.

Re: [racket-users] Collections and data structures wishlist?

[Matthias Felleisen]

> On Jan 26, 2019, at 8:31 AM, Hendrik Boom  wrote:
> 
> On Fri, Jan 25, 2019 at 07:50:56PM -0500, Matthias Felleisen wrote:
>> 
>> Yes. See Clojure history. — Matthias
> 
> Given the amount of text you have quoted, it's not clear what you are 
> saying yes to.


Hickey: "we tweak Perlis one final time - "It is best to have 100 functions 
operate on NO data structure”.” 

[[ He means to have 100 transducers on Interfaces, instead of 10 x 10 functions 
on concrete data structures. ]]

-- 
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.

Re: [racket-users] Collections and data structures wishlist?

[Hendrik Boom]

On Fri, Jan 25, 2019 at 11:33:09AM -0800, Jack Firth 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.

There are often times I want to process the elements of coordinate tuples 
uniformly, and oftern times I want to treat them separately.  This seems 
like a case where I'd want both tupe operations and list operations on 
the same data.

-- hendrik

-- 
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.

Re: [racket-users] Collections and data structures wishlist?

[Matthias Felleisen]

Yes. See Clojure history. — Matthias



> On Jan 25, 2019, at 4:21 PM, Jack Firth  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  > wrote:
> 
> > On Jan 25, 2019, at 3:46 PM, Thomas F. Burdick  > > wrote:
> > 
> > 
> > 
> > On January 25, 2019 8:33:09 PM GMT+01:00, Jack Firth  > > 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.

Re: [racket-users] Collections and data structures wishlist?

[Jack Firth]

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 
wrote:

>
> > On Jan 25, 2019, at 3:46 PM, Thomas F. Burdick 
> 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.

Re: [racket-users] Collections and data structures wishlist?

[Matthias Felleisen]

> On Jan 25, 2019, at 3:46 PM, Thomas F. Burdick  wrote:
> 
> 
> 
> On January 25, 2019 8:33:09 PM GMT+01:00, Jack Firth  
> 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.

Re: [racket-users] Collections and data structures wishlist?

[Thomas F. Burdick]

On January 25, 2019 8:33:09 PM GMT+01:00, Jack Firth  
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.

-- 
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.

Re: [racket-users] Collections and data structures wishlist?

[Jack Firth]

>
> 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 
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 
> 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.

Re: [racket-users] Collections and data structures wishlist?

[Matthias Felleisen]

(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  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  
> 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.

Re: [racket-users] Collections and data structures wishlist?

[David Storrs]

> When it comes to collections and data structures, what would you all like to 
> see in Racket2? New APIs? Changes to existing APIs? Whole new paradigms? 
> Something else?

I wrote the struct-plus-plus module
(https://docs.racket-lang.org/struct-plus-plus/index.html) because I
wanted some additional features around structs, most of which were
available somewhere but not integrated together.  struct-plus-plus
implements the following:

- keyword constructors (already doable with Greg Hendershott's
'struct/kw' code
https://www.greghendershott.com/2015/07/keyword-structs-revisited.html)

- contracts on individual fields (already doable, but complex:
https://docs.racket-lang.org/guide/contracts-struct.html)

- defaults for individual fields (the #:auto keyword on fields does
not accomplish this, since it only allows one default for the entire
struct)

- wrappers around fields -- e.g., accept either symbols or strings but
normalize to strings- Functional setters and updaters for all fields
(doable with Alexis's struct-update module
https://docs.racket-lang.org/struct-update/index.html except her
version does not enforce contracts on the fields and mine does)

I have a few more things I'd like to add:

- A 'pre-transform' function that acts as the complement to the
wrapper function.  The wrapper modifies the data after it's passed
through the contract but before the struct is constructed.  The
'pre-transform' would modify the data before it goes to the contract.

- A way for fields to default based on the values of other fields.

Low priority:

-  mutation-setter/updaters for structs that are marked mutable  (not
a super high priority for me, since I've come around to thinking that
mutable structs are a bad idea in most cases, although I can grant
some exceptions)

-  a keyword for 'don't generate the setter/updaters' for when they
aren't desired


On Thu, Jan 24, 2019 at 8:34 AM Gustavo Massaccesi  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  
> 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.

-- 
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.

Re: [racket-users] Collections and data structures wishlist?

[Gustavo Massaccesi]

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 
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.

Re: [racket-users] Collections and data structures wishlist?

[Greg Hendershott]

>> - 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.

Re: [racket-users] Collections and data structures wishlist?

[Stephen De Gabrielle]

Tables are pretty cool!

https://www.pyret.org/docs/latest/tables.html


On Fri, 18 Jan 2019 at 22:22,  wrote:

> When it comes to collections and data structures, what would you all like
> to see in Racket2? New APIs? Changes to existing APIs? Whole new paradigms?
> Something else?
>
> I've got my own wishlist and maybe someday I'll implement a few things on
> it as packages, but I'm curious what everyone else thinks. For some
> examples, here's a few things on my list:
>
>
> - Distinct data types for pairs and lists, and more intuitive names for
> the pair APIs (so `pair?` and `list?` would be mutually exclusive
> predicates and you'd make and access pairs with `(pair 1 2)`, `(pair-first
> p)`, and `(pair-second p)`.
>
> - 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.
>
> - Something better and simpler than structs. Throw out mutable fields,
> subtyping, struct type properties, etc. Just the basics: a tuple-like type
> with named fields and a constructor that can enforce invariants on all
> instances.
>
> - Lots more stuff.
>
> --
> 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.

Re: [racket-users] Collections and data structures wishlist?

[Jack Rosenthal]

On Fri, 18 Jan 2019 at 14:22 -0800, jackhfi...@gmail.com wrote:
> When it comes to collections and data structures, what would you all like
> to see in Racket2? New APIs? Changes to existing APIs? Whole new paradigms?
> Something else?

Maybe you'll need to clarify what Racket2 is? I am not familiar.

> - Distinct data types for pairs and lists, and more intuitive names for the 
> pair APIs (so `pair?` and `list?` would be mutually exclusive predicates 
> and you'd make and access pairs with `(pair 1 2)`, `(pair-first p)`, and 
> `(pair-second p)`.
> 
> - 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.

While these changes may make the language easier to read (slightly,
easier to discern programmer intent in some cases), as well as slightly
more reliable (harder to write incorrect programs), you'll have to
consider the negative impacts as well.

Programmers would often want a way to accept what was previously
considered just a list, so we might see collection/c (or a similar name)
come to be defined to (or/c list/c tuple/c ...). And, to work with these
collections comes generic operations (collection-first ...). This may be
the paradigm in other languages like Python, but Racket is not Python.
My hunch is that this would make the language harder to write in, and
create potential constraints when it comes to optimization.

Jack

-- 
Jack M. Rosenthal
http://jack.rosenth.al

No, sir... clicking on 'Remember Password' will NOT help you remember
your password.

-- 
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.


signature.asc
Description: PGP signature

Re: [racket-users] Collections and data structures wishlist?

[jackhfirth]

On Friday, January 18, 2019 at 11:50:48 PM UTC-8, Matthias Felleisen wrote:
>
>
> On Jan 18, 2019, at 10:22 PM, jackh...@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 
>

100 functions on one data structure is how you end up with unreadable 
function names like list* and cadadr.

-- 
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.

Re: [racket-users] Collections and data structures wishlist?

[Matthias Felleisen]

> On Jan 18, 2019, at 10:22 PM, jackhfi...@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 



-- 
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.