Reduce syntax clarification

[TheLoneWolfling]

A couple of related questions about how reduce should work, in your mind.

Currently the syntax is essentially (reduce array_or_func_returning_array acc_var cur_var func [optional_init_val]). 4 or 5 arguments.

• Should a function be allowed for acc_var / cur_var (that returns a variable), or should they be required to be literal variables?
• What if acc_var or cur_var are already let-ed elsewhere?
• What if acc_var is the same as cur_var? Syntax error? (Eg. (reduce [2,1] a a (/ a a)))
• What if func isn't a function? Syntax error? Or do you want to treat a non-function as a function returning that value? (Actually: in general you could do this. Makes some things simpler, but can disguise other errors. Your call, of course.)
• What if reduce has more than 5 arguments? Syntax error?
• Should reduce be able to be called over a zero-length array? If so, what should it do? Turn into a no-op?
• Should reduce work over strings as well? (Actually: in general should strings be just considered arrays of characters for language purposes? It would make some things simpler...)

[incrediblesound]

OK let me try my best at these:

1. I don't think functions make sense for acc curr. The idea behind those is that you are just telling the interpreter what you are going to call the accumulator and the current item inside the function body. I could have done it automatically but I thought this way was better because it's explicit. I've also been contemplating whether or not to do the same with the i variable in a for loop, I could give the for loop function an implicit i variable but that has the same problem, what some people call "magic".
2. The way populate_reduce_function works is that the variables you chose for the accumulator and current item will be replaced with the actual values before the function is executed, which means that if there is some global variable that collides with one you chose then it will be overridden by populate_reduce_function before execute has a chance to pull its value out of the let_map. That behavior seems OK to be, but it calls to mind another issue which is that there is only one let_map and Huo cannot differentiate between local and global variable. I'll open an issue for that.
3. Yes that should definitely be an error.
4. I think this should also be an error. The idea of literal values being interpreted as functions that return those values is definitely interesting but I think the mechanism I added for that (the return function) is good because it is more explicit and fits better with the syntax.
5. Again, you've found another error condition. Are you a QA engineer? You're really good at finding error conditions.
6. This case I think should just return the empty array.
7. This is a good point. I think some of the iterator functions should work on strings as well as arrays. Map, each, and filter definitely should (I will add filter soon), but I'm not sure if reduce in particular makes sense for strings.

[TheLoneWolfling]

Thank you!

Running through:

1. I don't think functions make sense for acc curr.

I fully agree. But I know some people would disagree with me, hence the question.

one let_map

It's actually worse than that... Think of what currently happens with variables in nested functions, for instance...

3/4/5

OK. I'm a programmer right out of university who is currently looking for work, including in QA, if that answers your question.

reduce (empty array) -> empty array?

This will mess up many things - suddenly your return type changes! (I would prefer if it was "error if no initializer value, else initializer value".)

operating on strings as well as arrays

There's a pretty easy generic method to do this, once we start encapsulation.

[incrediblesound]

Hey look, you were right! At least in JS, and I'm guessing other languages, the behavior is to return the initializer or throw an error if there is none. Good call. We can emulate that behavior.

[TheLoneWolfling]

Sounds good.