Good point about fill-table. I didn't think of how easy it is to give this function a newly created table. It still kind of feels like a shortcoming that (table) doesn't accept values like (list) does. And I don't want to define a different function to behave like this. If it's a good idea, it should be in the main table constructor. PG seems to have thought of this already because there's a comment in ac.arc with a definition that involves fill-table. I do, however, see that this would slightly bloat the constructor.
table-w/keys is useful for counting. After creating the table in icemaze's exemple you can for instance do
(++ (h 'cars))
Even more useful, however, is to specify a default value for keys not yet in the table, so you can do the above without first initializing for the keys you intend to use. PG mentioned in Arc at 3 Weeks that lookup failure should return the global value * fail* , in which case you would be able to do
which returns a table where red is 1, blue is 2, green is 1, and no other keys exist. The example is kind of stupid, but the concept is quite powerful.
I think the reason is that returning the concatenation would be very expensive. It would basically require a temporary write stream just to put together the return value. In the majority of cases, the return value is probably not even used.
To get the effect you want, simply concatenate as a separate step:
