Create a gist now

Instantly share code, notes, and snippets.

Embed
comments of blog post 'The Selector Pattern'
@sviperll

This comment has been minimized.

Show comment
Hide comment
@sviperll

sviperll Jan 28, 2014

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

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

@forax

This comment has been minimized.

Show comment
Hide comment
@forax

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

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.

@terje7601

This comment has been minimized.

Show comment
Hide comment
@terje7601

terje7601 Jan 28, 2014

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.

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.

@forax

This comment has been minimized.

Show comment
Hide comment
@forax

forax Jan 29, 2014

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

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

This comment has been minimized.

Show comment
Hide comment
@mjafari

mjafari Feb 4, 2014

  • This comment is for testing github.io blog commenting.

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