Array methods

[dfellis]

The remaining array methods depend on generic functions and interfaces being implemented, for the most part. (The implementation could be done and tested without it, but it would require declaring a binding for each sub-type for the array, which isn't usable for user-defined types.) The "Vec" types should also be converted to the Array type at this time, including the parallel map functionality. Since Arrays are just Rust Vectors under the hood, this may not require any actual changes to the bound code.

The functions desired for a first v0.2.0 are:

• [x] map
• [x] filter
• [x] reduce
• [x] find
• [x] join
• [x] every
• [ ] delete
• [ ] set (maybe done inside of the automatic type generation)
• [x] concat
• [x] repeat
• [x] len
• [x] has

[dfellis]

After thinking about it for a bit, each may not make any sense for the new Alan. (I'm also not 100% sure it did for the old one, either). The issue is that each only runs side-effect functions, and is often used to mutate outer state via a closure. This makes it impossible to parallelize in any logical way and it would be a single-threaded-only API.

I'm not sure I want to encourage that sort of thing when often a reduce assigning to the variable you want to mutate and initializing with the original value will accomplish the same thing but can be parallelized.

So for now, I'm going to strike it from the list. I might put it back in later, but unlike most of the rest, it's 100% sequential and encourages "knotty" code that is harder to refactor and harder to parallelize.

[dfellis]

Hmm... has that accepts a function is identical to some in behavior. Now I'm not sure if I want to include some as an alias or just remove it from the list of functions or rename the function-using has to some to match what people expect.

[dfellis]

some as an array method also collides with some as a Maybe/Option term.

I currently have Fallible using the ok term to create a wrapped version, though I am not sure if I want to keep that. It's longer to write, but I think Fallible(val) will do the same thing (if it doesn't I should fix that).

I am also thinking of having functions that accept a sum type automatically accept each component type and auto-wrap for you (and maybe also if a return type is a sum type you can return the component types and get the right thing, but that could produce unexpected compilation success when combined with inferred return types where you accidentally returned a sum type instead of the type you thought you were returning, so I'm not sure about that one. Probably better to force wrapping the output).

In any case, this makes the ok/err/some/none functions to create these sum types unnecessary, so I could keep some around for array methods to make it easier for the JS crowd to adapt, but a language with an optional type and a some function that doesn't involve the optional type feels like it could also be confusing.

So, to conclude, since has now does the same thing some does for Array methods, I'm going to drop some from this list, too. And I'm also going to look into dropping the sum-type functions as unnecessary.