AltME: Ren - Data Exchange Format

Messages

Pekr
Isn't Trello just a tasking system? I have to miss on its certain functionality?
Chris
Wrt. other discussions--kind of makes my point. There has been discourse off and on in SO Chat on various issues: none, logic, map, urls, paths, plan -4. Again, wasn't suggesting it as the canonical source. It has flaws as you say...
Pekr, Trello--it's tasking, organising, cork-board, even chat. Also not without flaws--I'd like it better if it had a better resume of updates...
Arnold
Perhaps a bit premature question. Will REN date/time format be prepared for the Mars One project? http://www.mars-one.com/
Chris
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.
Gregg
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.
Geomol
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.
Gregg
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).
Geomol
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.
Gregg
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.
Geomol
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.
Gregg
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.
Geomol
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.

Last message posted 408 weeks ago.