

Cons is your friend - ayberkt
http://kaygun.tumblr.com/post/96866991234/cons-is-your-friend

======
bshimmin
This probably won't be well received, but I think posts like this, with lines
like "a list of objects of type X is an element from the free monoid generated
by the set of elements of X where the monoid structure (a unital associative
binary operation) is given by concatenation", go some way towards explaining
why functional programming won't ever become mainstream.

~~~
enupten
I know jargon looks unsurmountable at first, but if you pay close attention to
definitions, they are usually extremely simple. To wit, the example you quote
is just the set of strings on X.

~~~
nice_uname_nerd
It's more than just strings though, it's all lists on a set of atoms. (a b c)
is treated differently from (a (b c)).

EDIT: Actually you're right, it's all strings on X. I thought the author
wanted all lists on X.

------
sedachv
tl;dr If you change the way you use data structures a little bit you can come
up with parallel algorithms to work on them.

This idea is something that Guy Steele has been promoting well before his 2009
ICFP presentation - one of my favorite papers is this one he coauthored with
Danny Hillis in 1986: [http://cva.stanford.edu/classes/cs99s/papers/hillis-
steele-d...](http://cva.stanford.edu/classes/cs99s/papers/hillis-steele-data-
parallel-algorithms.pdf)

------
mrspeaker
I'm can't speak authoritatively on this subject: but I'm pretty sure that
telling Guy Stelle "don’t get rid of [Cons], use it correctly!" is a very
ballsy move ;)

------
mindslight
Actually, generic protocols and parametric polymorphism are my friends.
Representation is quite important, but that doesn't mean I want to hang out
with it every day.

~~~
riffraff
AFAIR one of the lessons from the Fortress development was in fact that
choosing a suitable fundamental representation led to better protocols

i.e. if you assume that "the list" is implemented with conc (i.e. it's a tree)
it's more natural to come up with "the loop" as parallel by default, while
starting with a cons list you may more likely end up with a sequential one.

------
kazinator
What you need is something slightly better than the CONS: the lazy CONS:
LCONS.

The LCONS is a binary cell which has an associated function. It begins life in
a "promised" state. When the CAR or CDR of a LCONS is accessed for the first
time, the LCONS is "forced": the function is called, and stuffs values into
the CAR and CDR. Then it is dissociated from the LCONS, which behaves like a
CONS after that.

In the Lisp dialect built into the TXR tool, I have conses as well as lazy
conses. Lazy conses satisfy the consp function, and behave like conses for
most intents and purposes.

Lazy conses give you structures that you can feed to functions that expect
ordinary conses. Many of those functions instantly become empowered for lazy
processing; suddenly they can handle infinite lists.

For some functions, you can easily provide lazy equivalents. A lazy mapcar
returns a lazy list, which applies a function to tuples of other lazy lists.

Add the infinite sequences {0, 1, 2, ...} and {10, 11, 12, ...}, then take the
first ten elements of the result:

    
    
        $ txr -p '[[mapcar* + (range 0) (range 10)] 0..10]'
        (10 12 14 16 18 20 22 24 26 28)
    

If you use regular mapcar, it will hang in a loop up trying to construct the
whole list as it fills memory.

~~~
jerf
Adding all numbers in strict cons-based list is O(n). Adding all numbers in
lazy cons-based list is O(n). Adding all numbers in a strict cons-based tree
can be O(log n). Adding all numbers in a lazy cons-based tree can be O(log n).
Laziness is an entirely different problem from the one the author is talking
about.

I see many people here in the sibling replies appear to have also so
thoroughly internalized that "cons is for a list" that they appear to have
entirely missed the point of the article.

~~~
kaygun
The author of the post here. It seems Steele might be vindicated at the end,
not on the technical level but on the social level: get rid of cons, and all
the mental assumptions coming with it, for truly parallel solid data
structures and algorithms that would go with them.

