Tweak examples: *, apply, and product

[sogaiu]

This PR contains some minor tweaks to examples for *, apply, and product.

Apart from some formatting, some return values and an error message are modified.

[rwtolbert]

@sogaiu I've got mixed feelings about product applied to a table. Just because it works, it feels like an unplanned consequence not a real feature.

Seem if a user really wants to sum or product the values from a table, then forcing this syntax makes it more clear:

repl:11:> (def foo @{:a 2 :b 3})
@{:a 2 :b 3}
repl:12:> (product (values foo))
6

Just my 2c

[sogaiu]

@rwtolbert I felt similarly (^^;

FWIW, I did some digging and learned that the original example was added in this commit (along with a similar example for sum). Given the author of that commit, I suspect that the current behavior is intentional.

[rwtolbert]

In some ways it is good that at least we document this behavior.

the corner case that concerns me is some function that depends on the order of the input that when applied like this then fails in odd ways with the non-deterministic order of the values. But then (values foo) doesn't promise any order either.

[sogaiu]

With respect to product and sum, the underlying functions being applied are * and +, and ordinarily [1] IIUC the order of application across a set of elements shouldn't matter for these(?).

AFAIU, product and sum both currently use each in their implementations, and each in turn uses next along with a succession of keys to traverse various data structures (which include indexed and dictionary types). If we think of indexed and dictionary types as being (typically) different only in the kinds of keys they have [2], may be it's not so strange for sum and product to be able to handle both?

---

[1] Not thinking about floating point and other related errors...

[2] Ignoring that indexed things are stored "sorted" while dictionaries (at least in Janet) are not (at least not according to an agreed upon key-based order).