Functional Module: Map/Reduce/Filter

[BraedonWooding]

Motivation

Just felt the library needed this. It is super simple shouldn't really be too major.

Side Note

Also kinda shows how Zig needs lambdas of some sort most likely just the ability to declare inline functions like;

var pow = mapAlloc(fn(a: i32)i32 => { a*a; }, list, allocator);

Instead of currently requiring you to predeclare that function somewhere else and use it like;

var pow = mapAlloc(pow, list, allocator);

IMPORTANT

To make it easy I've made two commits; if you like the first one then please say and I'll reverse the second commit. The second commit just doesn't require types however it does make the code a bit more complicated.

FOR EXAMPLE;
The first commit would require; mapAlloc(i32, i32, add, list, allocator);
The second just requires; mapAlloc(add, list, allocator);. Now while in most cases I think having explicit types helps, this is all about functional programming so I think requiring to have the types could be quite annoying.

However maybe some nice @compileerrors should popup if you do things really wrong? But then again it would give you pretty good errors anyway.

Currently for example if your types mismatch it gives;

/Users/<USER>/.../<FILE>.zig:<LINE>:<COL>: error: expected type '[]const i32', found '[]bool'

That is it looked at my array of integers being passed in and saw that the function returned a boolean and went those don't match!

IF you give a non-function, it'll tell you;

/Users/<USER>/.../<FILE>.zig:<LINE>:<COL>: error: expected function, found '(integer literal)'

Which is real nice (integer literal cause I used '3' as a testing example).

So I think error wise it probably even gives nicer errors, then again the code is harder to understand due to a lot of builtins everywhere but it is such short snippets maybe that is acceptable?

[thejoshwolfe]

Some discussion about lambdas has been done here: #229 (comment)

[andrewrk]

map, filter, and reduce are functional concepts that are going against the grain in an imperative language. In my experience, for loops lead to more maintainable, more optimal code. I think that there is value in leaving these out of the standard library, to encourage a more uniform, imperative style of writing code.

According to the release notes of Python 3:

Removed reduce(). Use functools.reduce() if you really need it; however, 99 percent of the time an explicit for loop is more readable.

[andrewrk]

See also #239

[BraedonWooding]

While I don't particularly agree I understand your view :).

[lambdina]

I'm a bit disappointed ngl

[terremoth]

I'm a bit disappointed either, reading this