On Thu, 2020-05-21 at 11:22 -0500, Kevin R. Bulgrien wrote:
> FILE_SIZES := 5 2 1 4
> TOTAL :- $(math +, $(FILE_SIZES))
>
> 2)
>
> FILE_SIZES := 5 2 1 4
> TOTAL :- $(+ $(FILE_SIZES))
>
> In my mind, TOTAL obviously ends up with the same value, but, 1) is
> more readable in the same way that almost any language is more
> readable than perl with all its non-alpha shortcuts.
Well, I like Perl so there you go! :)
In these simple examples the extra boilerplate is not so concerning but
the more complicated the expression the more annoying it becomes.
5 + (2 * 9 / (7 + 5 + 4)) * (1024 * 1024) / 19
becomes:
$(math +, 5 $(math /, $(math *, $(math /, $(math *, 2 9) $(math +, 7 5 4))
$(math *, 1024 1024)) 19))
versus:
$(op + 5 $(op / $(op * $(op / $(op * 2 9) $(op + 7 5 4)) $(op * 1024 1024))
19))
or:
$(+ 5 $(/ $(* $(/ $(* 2 9) $(+ 7 5 4)) $(* 1024 1024)) 19))
However, I agree these complex operations will be rare and shouldn't be
the most important criteria. And I also agree with your followup
regarding documentation and discoverability: this is actually the main
reason I was thinking that a single function with an operand would be
better than lots of little functions.
If we choose "math" we probably need a separate function for
conditionals like $(cond ...) something, since <,>,etc. don't really
fit into a "math" function.
If we choose a different conditional function I guess we should
consider whether we want to use prefix notation for conditionals. We
don't need to worry about operator precedence here and variable numbers
of operands are not helpful, and I personally find prefix notation
conditionals hard to read... to me:
$(cond $a < $b)
is simpler to understand than
$(cond <, $a $b)
I think there's some useful precedent in shell or eval for something
like $(cond ...) where it takes a single argument which is interpreted
using a different model than other types of evaluated content.
But I could go either way.
