I am not really happy with this, because the type is not really
something that end-users should use (although they can), it's more for
the typechecker internally. How to explain this nicely?
I'm leaving the Zed extension pointing to the older commit of the
Tree-sitter grammar, I'll update that after this version bump. It's
a bit awkward to do it this way around, but there are circular
dependencies that can't be avoided. Maybe with an attack on SHA1 it
can be done in theory, but let's not go there.
At first I also wanted to support rounding to a negative number of
decimals (so rounding to a positive power of 10), but scope creep,
complications ... I don't need it, and we can always add that later.
RCL is now truly -- for all practical purposes, yeah yeah pedantics
surrogate pairs and a file with 20 GiB of zeros are technically valid
json but let's talk about documents used in the real world -- a json
superset!
Also I think I should try to make the readme and index pages a bit more
attractive to people who discover this. I wrote them from my niche
perspective and I had a lot of background about what I was building, but
probably it needs to be explained more to new users.
Also improve a few other things, e.g. as a quick hack, add a
"Playground" link in the website header to make the feature more
discoverable. We can extract it into a separate page at a later stage.
This enables us treat numbers with an exponent losslessly. We don't
conflate the decimal point with the exponent in case they get in the
way of each other.
It also greatly simplifies the formatting. We can mechanically format
the representation now, without having to use heuristics for when to
switch to scientific notation. The catch is of course that the
heuristics will need to move elsewhere. We'll have to normalize the
numbers after arithmetic operations.
This is part of updating the implementation to have a single number type.
I have to admit, doing this, I'm hesitant again. I would really like len
functions to return Int, or to clarify in the types that std.range
accepts only integers. But let's experiment, implement this, and get a
feel for it before I make a call.
I decided, after going through a few iterations of a blog post that
explains the trade-offs, to have only a single Number type, and to
remove Int. This is an invasive change, let's start with the docs
because those are somewhat easier.
I thought I was close to having a finished design, but re-reading what
I wrote before ... there are still some loose ends, like the comparison
operator now behaving very unexpectedly. Maybe I should ban cross-value
comparisons after all, and move that to a different function?
I realized yesterday, the interaction between Int and Float creates a
rabbit hole of subtleties. I wrote down some thoughts on GitHub, but
important decisions like these are best kept under source control.
It's not really needed, sets are currently implemented as BTreeSets, so
they are sorted anyway, you could also just use a list comprehension.
But I do want to change that in the future, and also symmetry with List
is nice, so let's add it.
I realized today that I want this. In particular, the API of my music
player Musium returns albums with a numeric playcount and discovery
score, and I want to sort on that. Finally that is possible now that I
am adding support for floats. But I need a way to sort on one field of
a dict! Arguably this is more important than the bare sort itself.
While I do this for lists, we can do the same for sets.
Inspired by Cue, the `cue` commands without arguments prints somewhat
useful basic usage. I suppose `git` does so too. RCL used to print the
full reference help, which ends in the details for the color mode, which
is useful to have somewhere, but not that helpful as the first thing you
see when you run `rcl` (because the rest is too far up in your window).
So print the brief help if you run `rcl` without commands, and the full
help when requested with --help.
Document help text change in the changelog as well.
In a real-world use case, I had dates as ISO-8601 strings, and I wanted
to filter any entries after a given date, but the comparison operators
were not allowed on strings. Lift that restriction.
It started to get annoying to have to define it myself every time, so
let's just add it properly now. This also resolves the longstanding
issue in the RCL pretty-printer that we have no good way to print the
empty set -- now we do!
I just encountered "Reduce Cognitive Load" in a comment on Hacker News
and it fits the acronym very well, I'm going to keep a list of possible
meanings of the name "RCL".
Previously we named the file "build.rcl", but now that that is the
default name for "rcl build", let's name the Ninja meta build file
"ninja.rcl". Also, clarify that Make is able to use the depfiles too,
just in a way that I personally try to stay far away from.
As expected, the golden tests fail to run under Nix because the test
directory is not writable. And it's better to not write in my opinion,
let's not hack that and have a dry run output mode.
For now the output format is not structured, this is good enough for the
thests. It could be nice to do structured output in RCL format, but we
can do that later if needed.
I don't like this distinction that in the build file, we don't
implicitly add a newline, but on the command line we do. But making
users specify a trailing newline on the command line is annoying. So
then the RCL build spec will have to match the CLI, and append the
newline. But then empty string cannot be the default, so let's accept
null too.
