Qi Xiao

> When introducing compile time attributes for variables wouldn't it be better to use an extensible mechanism that doesn't require an open ended number of special builtins that can't be...

Well, if I need to choose between 13m9.123456s and 13.2 m, I'd say the former is actually closer to the human-readable form. @zzamboni's proposal can already be expressed in Go...

Two questions: - How does behave for value-outputting commands? In your PR the value outputs would be joined by `\n` but is that intended? - Should this preserve trailing newlines?...

Completion files can be installed like other modules into a global module search directory (https://elv.sh/ref/command.html#module-search-directories). There is no automatic discovery of completion files though; the user would have to import...

Sorry, but no. Optimizing `order | dedupe` is indeed desirable, eventually. But it can and should be done transparently - the compiler can recognizing the pattern `order | dedupe` in...

I don't see any substantial advantage in adding an option to `order`. Adding another command after it is simple enough - `order &uniq` isn't any shorter than `order | uniq`....

It's fine living in the builtin namespace for now. Most of the commands that operate on streams are in the builtin namespace.

> I'm inclined to prefer dedupe rather than compact as the name of both a standalone command and the order option. Googling "dedupe" returns significantly more relevant matches, such as...

Here is a system to judge command names: - A good name reveal what a command does unambigously to people who've never used it. - An OK name may not...

> A quick suggestion, similar to `compact` but perhaps marginally better: `tighten`. I don't have a very strong opinion between them, but since https://pkg.go.dev/golang.org/x/exp/slices#Compact uses "compact", the terminology is likely...