Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
comments of blog post 'The Selector Pattern'

Lets assume that we will use your original select method. In all use cases I can think of there will be only one canonical implementation of this abstract method. Canonical implementation for the List interface will consist of cons and nil. In my opinion all lists will be built from nil and cons, so you don't need an easy way (i. e. lambda-expression) to override select.

I've created an adt4j package bases on similar ideas: https://github.com/sviperll/adt4j

Owner

forax commented Jan 28, 2014

I agree, Lambda expressions as an easy way to implement cons and nil, is not something required. It's just fun.
I'm more interested by the relation that says that there is a bijection between an ADT and a function and the properties of such function. From a language designer/implementor perspective, it means that you can encode an ADT to a function without any supplementary mechanisms.

I believe the implementation of flatMap is incorrect. Given:

List list = cons(1, cons(2, cons(3, nil())));

then:

list.flatMap((i) -> cons(4, cons(5, nil()))).size()

should be 6, imho, but the current implementation gives 2.

I haven't been able to write an implementation that gives 6 yet, so I'm curious to see how it can be done.

Owner

forax commented Jan 29, 2014

yes, it should be fixed now so
list.flatMap((i, tail) -> cons(4, cons(5, tail))).size()
should work !

mjafari commented Feb 4, 2014

  • This comment is for testing github.io blog commenting.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment