On 15. May, 2009, at 4:07 PM, Stavros Macrakis wrote:
> Personally, I'm not a big fan of 'flatten', because I think it
> encourages sloppy programming and subtle errors (what if what are
> logically leaves are represented as lists?).
Could you elaborate on this? What dangers does flatten hide?
> The explicit-n version of flatten is a better idea, except for one
> thing: it should give an error if n > 0 and the argument is not of the
> appropriate type.
>
> Examples:
>
> flatten( [a,b,c], 0) => [a,b,c]
> flatten( [a,b,c], 1) => error: a does not have operator '['
> flatten( f( f( 2 ) ), 0) => f(f(2))
> flatten( f( f( 2 ) ), 1) => f(2)
> flatten( f( f( 2 ) ), 2) => error: 2 does not have operator 'f'
>
> That gives the user appropriate warnings.
>
> -s
If you define 'flatten' as a mathematical transformation
flatten(atom)->atom
flatten(list/..)->elements
Then no errors are needed...
> flatten( [a,b,c], 1) => error: a does not have operator '['
Does this mean,
flatten( [[a],b,c], 1) wouldnt work also? This seems too prohibitive
to me.
My usage of flatten is restricted only to lists - where I don't see
the possible dangers of flatten on general expressions.
Regards,
Ziga Lenarcic