AltME: Ren - Data Exchange Format

Messages

Gregg
Literals for inf and NaN?

DocKimbel
Gregg
Ah, thanks! I'm not sure of how useful they'll be, but if we're talking about passing messages and results around, they could be important in some fields.

Gregg
Should time! values be restricted in number of digits and signs? REBOL allows integer values for hours and minutes, which is converts to sexagecimal values. Minutes can be negative, as can hours of course, but second can't. Negative minutes are subtracted from hours. Also, if you only specify two segments, they are HH:MM if both ints, but if the second is a decimal, it becomes MM.SS.s. And scientific notation is not supported for seconds, nor are decimals for hours or minutes.
The main thing for Ren is that values need to be unambiguous. But what other limitations should be imposed? And should similar rules apply to other segmented numbers (tuple and pair/point)?

DocKimbel
For data exchanges purposes, I think you can stick to a more restricted format for time! than the one allowed by Rebol at runtime, like HH:MM:SS.s and only positive values.
Gregg
That was my original thought as well, and what Ren specs today, with negative hours allowed. That implies that the entire time is negative, which I use today. Consider time ranges. e.g.,  a target time +/- N minutes. I think we can live without mixed sign time values. Mixed sign values aren't intuitive, though their results make sense if you think about them.
On the number of digits, if we limit it to HH:MM:SS.s, do we also say the values have to be valid sexagecimal (00-59)? It complicates the grammar just a bit, and does it provide value over allowing any integer value in a segment?
DocKimbel
I am for sexagecimal values in Ren, as Ren is about representating data, not carrying on computations which could benefit from some extended format for temporary time representations (like negative values).
Gregg
OK. Let's see if anyone else has an opinion.
We'll make a decision in T minus 0:0:5..0:0:4..0:0:3..
DocKimbel
:-)
Rebolek
I agree with limited specs.
Gregg
One of the other nice things about limiting it is that we can later loosen the restrictions if a strong argument can be made to do so.
DocKimbel
If you want to have a wide support for Ren in non-Rebol languages, the smaller the specification, the easier to support it.
Rebolek
Exactly.
Gregg
Agreed, but more limiting, in this case, doesn't mean a smaller spec.
i.e., having to specify sexagesimal rules.
Gregg
What about leap seconds (23:59:60)?
Again, it could be extended later.
DocKimbel
I wouldn't allow it either. Only stricly valid time values.
Rebolek
I vote for later. When someone is going to use Ren for running an atomclock, we can extend the specs ;)
Gregg
Agreed.

Last message posted 408 weeks ago.