5 ms·

Thanks for these interesting thoughts. One quick question: how is rule 2 a special case of the general rule? I think I'm missing something in your explanation o

Thanks for these interesting thoughts. One quick question: how is rule 2 a special case of the general rule? I think I'm missing something in your explanation of rule 2. Is it just the scalar+array version of rule 3, for a function f(x, y) of two scalar arguments? Could you then say that one of the big ideas of APL is to define a canonical way of extending functions of scalars f(x, y, ...) to take one or more array arguments, and then baking those ways into the syntax, so you don't have to use zip and map? I agree there's something to that. It seems like a feature that other languages could benefit from. Maybe a decorator symbol could be used to tell the language when you want to do this, or a setting so it's turned on by default in a particular module. We probably wouldn't want it as an immutable universal language rule, since entering an array to scalar argument is a common programming mistake that you could want your compiler or runtime to throw an error for.

adrian_b 5y ago
The rules 2 and 3 are how to derive a function with array arguments from a function with 2 scalar arguments. You can replace one scalar with an array by rule 2 and both scalars with arrays by rule 3. This should be extended to an arbitrary number of scalar arguments, where you should be able to replace any scalar with an array whose elements have the same type as the scalar and any combination of scalar and array arguments should be valid. This is the first step in using APL, by defining only scalar functions, but using them also with array arguments. This only works with arrays of the same dimensions, where the function arguments are elements in the same positions, i.e. which would have had the same indices in a "for" loop. This already covers the most frequent uses. Only when you need more complex ways of combining arrays, you begin to need specific APL operators, e.g. reduction which transforms an array into an array whose rank is 1 less, e.g. like when you sum the elements of a vector into a scalar value, but the APL operators are completely general, so with the reduction operator you can apply any function of 2 arguments to a vector or to the subvectors of a larger array. Reduction operations are one of the places where it is obvious that the APL order of evaluation is better than the traditional, because it provides useful operations for the non-commutative functions, e.g. reduction with subtraction is the sum with alternate signs and reduction with division is the product of the fractions obtained from pairs of consecutive elements. Both operations are frequently useful, unlike to what would have been obtained with the traditional order of evaluation. The same happens with the other APL operators, they are generalized versions of the traditional operations, e.g. the inner product operator can do dot products or matrix multiplications, but it can be used with any pair of functions, not only with addition and multiplication. Like any use of overloaded functions, you are right that this would no longer flag as an error when you use an array of e.g. int instead of an int, but usually this would be caught eventually, e.g. if you try to assign the result to a scalar, unless you do this in an initialization with auto inference of the declared type, which would probably still give a type conflict later. I agree that this is a possible disadvantage, but I have never encountered an error of this kind, with overloaded functions or operators, that was not flagged eventually as a type error, even if possibly not in the first place where the error was introduced.
- civilized 5y ago
  Thanks, this is great and much more meaningful to me than the generic "tool of thought" hype I'm used to. APL is extending scalar functions with implicit map and reduce operators, and doing it in a way that's more general, consistent, and concise than, say, MATLAB or R's system of rules for scalars/vectors/arrays, or NumPy's array broadcasting rules.
  - adrian_b 5y ago
    Yes, you have expressed the facts very well.

adrian_b 5y ago

The rules 2 and 3 are how to derive a function with array arguments from a function with 2 scalar arguments. You can replace one scalar with an array by rule 2 and both scalars with arrays by rule 3. This should be extended to an arbitrary number of scalar arguments, where you should be able to replace any scalar with an array whose elements have the same type as the scalar and any combination of scalar and array arguments should be valid. This is the first step in using APL, by defining only scalar functions, but using them also with array arguments. This only works with arrays of the same dimensions, where the function arguments are elements in the same positions, i.e. which would have had the same indices in a "for" loop. This already covers the most frequent uses. Only when you need more complex ways of combining arrays, you begin to need specific APL operators, e.g. reduction which transforms an array into an array whose rank is 1 less, e.g. like when you sum the elements of a vector into a scalar value, but the APL operators are completely general, so with the reduction operator you can apply any function of 2 arguments to a vector or to the subvectors of a larger array. Reduction operations are one of the places where it is obvious that the APL order of evaluation is better than the traditional, because it provides useful operations for the non-commutative functions, e.g. reduction with subtraction is the sum with alternate signs and reduction with division is the product of the fractions obtained from pairs of consecutive elements. Both operations are frequently useful, unlike to what would have been obtained with the traditional order of evaluation. The same happens with the other APL operators, they are generalized versions of the traditional operations, e.g. the inner product operator can do dot products or matrix multiplications, but it can be used with any pair of functions, not only with addition and multiplication. Like any use of overloaded functions, you are right that this would no longer flag as an error when you use an array of e.g. int instead of an int, but usually this would be caught eventually, e.g. if you try to assign the result to a scalar, unless you do this in an initialization with auto inference of the declared type, which would probably still give a type conflict later. I agree that this is a possible disadvantage, but I have never encountered an error of this kind, with overloaded functions or operators, that was not flagged eventually as a type error, even if possibly not in the first place where the error was introduced.

civilized 5y ago
Thanks, this is great and much more meaningful to me than the generic "tool of thought" hype I'm used to. APL is extending scalar functions with implicit map and reduce operators, and doing it in a way that's more general, consistent, and concise than, say, MATLAB or R's system of rules for scalars/vectors/arrays, or NumPy's array broadcasting rules.
- adrian_b 5y ago
  Yes, you have expressed the facts very well.