>> Once again, I agree with all your points of view.
>
> I am lulling you into a false sense of security, so you support MY
> terrible ideas later... ;-)

Oh snap :) The plan is working well:

>> If there is interest, I can write a spec about such an encoding, and
>> solicit feedback. The basics are extremely easy to do with varints, as
>> demonstrated.
>
> I'd like that!

Great! I'll have a draft up shortly.

> Rationals? Store them as two integers.
>
> Complex? Store them as two numbers.

Those are the approaches I had in mind also.

> Inexacts are the tricky one, as unlike all the other types, there's no
> procedures to simply split them into parts that we can already represent
> - and we would like to exactly represent inexacts, as it where,
> reproducing them exactly the same way (assuming that the receiving
> implementation's representation isn't less exact then the sending
> one's). But peeking under the hood, one can note that most (all?)
> inexact number representations are IEEE floating points, and either
> provide a "raw IEEE double" (pick an endianness) value format, or avoid
> problems with implementations that have inexact representations that
> aren't a strict subset thereof by sending inexacts as two arbitrary
> integers - mantissa and exponent - with a few special values for
> infinities. Even the "subnormal" numbers very near 0 can be represented
> in that form, but it's a bit of shuffling to convert between that and
> Scheme numbers.

I didn't have any plan for floats, and didn't realize to consider
infinities, NaN and subnormal numbers at all. Your comments are astute.

One cop-out would be to store the binary digits of the integer part,
followed by the binary digits of the fractional part. This is highly
suboptimal.

I also think it'd be good to have support for decimal real numbers,
especially if we do database and currency stuff.

> As for timestamps and stuff - you can store the arguments to make-time,
> by using the accessors in srfi-19, etc!

The problem is, timestamps present at least the following concerns:

- Precision
- Accuracy
- Different epochs
- Different time zones
- Leap seconds (UTC vs TAI)
- YYYY-MM-DD dates vs seconds-since-Epoch timestamps

Most users, programmers, sysadmins and time APIs don't know or care
about that stuff very much. That means that no matter how diligently you
specify all the details about which time encoding you expect people to
use, they will just ignore your prose and stuff whatever timestamps they
have into it without a care in the world. Specifying an unambiguous
encoding is quite hard, but getting people to actually follow it instead
of merely pretending to follow it is ten times harder still.

I've thought about this problem on and off for years, but always come
back to just storing timestamps as integers. Then you don't pretend to
know more about the timestamp than you actually do.

Nevertheless, having a dedicated time datatype is very nice. If someone
has a proposal for how to avoid all the problems and guide people onto
the right path so we get reliable timestamps, I'd love to hear it.

> It would be nice to add it as an input/output format in magic-pipes, my
> sexprs-in-shell-pipelines toolkit:
> https://www.kitten-technologies.co.uk/project/magic-pipes/doc/trunk/README.wiki

That looks great! You even let people use SQL and S-expression regexps
from the command line. I'll try to build and install it.

If we get a binary spec going I'll definitely help you support it.