AltME: Ren - Data Exchange Format


Given the API though, it's not inconceivable that you could actually coalesce a specification there and generate a specification page based on the contents of a column.
Re. AltMe, I don't believe I'm the only one to find it ornery. Might be that it's just so awkward on OS X--even when you bundle it. Other things too.
OS X, ah yes. Ornery indeed. And there are other chat systems out there, but I really want to hear from a champion who knows one works really well, rather than just hoping it will be better.
The way I see it, BNF is an implementation. Need the design first.
Too much discussion about a non-problem?
I can tell, what I've done in the World language regarding date/time input. The date part defines a precise time also (midnight), so seconds from the Epoch can be calculated. Then I allow any time value for the time part, and World convert that to the actual seconds from Epoch, and a final date/time is shown to the user, if you're in the prompt. Examples:
w> 27-5-2015/-24:00:00
== 26-May-2015
w> 27-5-2015/100:00:00
== 31-May-2015/04:00:00
I see no need to put special restrictions on the time part of a date/time value. The final point in time is not ambiguous.
Doc's point from earlier is that, for Ren, that implies a computation rather than just a representation of a value.
Doc's point from earlier is that, for Ren, that implies a computation rather than just a representation of a value.
If we follow REBOL's lead, you can enter nonsensical values (though it errors on some).
Yes, and some systems using Ren might not be able to do, what e.g. World does. Is it really a problem? If you put invalid data into a system, it fails. Let it fail! (It's the Erlang philosophy again.) Users will then learn to put valid time valus into their date/time data. And if you some day need to talk to a system using time on Mars (where there are more than 24 hours in a day), you can still do that.
valus -> values
Judge the time used discussing this compared to the possible time spent in actual applications dealing with this potential problem. Don't waste too much time.
What is the strongest argument against a spec of:
    opt sign  int ":" int ":" int opt frac
whether as just time or part of date-time?
This is just how data is exchanged, perhaps with suggestions for useful, standardized semantics.
I would allow this also:
    opt sign int ":" int
meaning hour:minute. Some systems don't care about the seconds, and the format will be bloated, if that's the case.
My spec does that currently, but it is potentially ambiguous. Just looking at data, you don't know if it's hh:mm or mm:ss. Not sure requiring :ss qualifies as bloat. :-)
The biggest reason I support opt seconds is for REBOL compatibility. It is convenient.
Yes, convenient, and I think also easier to read for those, who never operate with seconds. "Meeting at eleven hundred."
Users of the format just have to know, it's always hours:minutes in such cases.
Right, the spec being:
    opt sign hours-minutes opt seconds
Actually, I'm never sure if 10:20 in Rebol is HH:MM or MM:SS.
About my point regarding bloat, I do mean it. :) Figure a system with thousands of hour:minute data being exchanged. If you force seconds in, which will always be 00 in such a system, and it will look like XML with end-tags. It is unnecessary bloat.
If you use Ren to exchange data between systems, where it means MM:SS, and you allow the first part to be any value (larger than 23 also), then it should work too, shouldn't it?

Last message posted 268 weeks ago.