...and you could still use as alternative: #[image! 1x1]
Oldes
which is imho the best:)
Gregg
The CC ticket has good discussion on the space-significance issue. On construction syntax, Ladislav's suggestion (map![a: 1 b: 2 c: 3]) is cleaner than the current syntax (#[map! [a: 1 b: 2 c: 3]]), but we don't commonly need construction syntax for most datatypes. Map! is the big one. In that case, Using the # sigil aligns with it being used as a special content marker (#[ ], #{ }, #" ").
I can see why Carl used the construction syntax he did, with blocks as the foundational structure, but I like the feel of #(...) more as I think about it, because of the paren semantics.
The `<datatype>[...]` syntax doesn't grab me right now.
A key question is whether Ren should support construction syntax of any kind. The other key issue in the CC ticket is path values, which Ren only supports a simple version of so far, in the spec, i.e., no parens allowed.
Geomol
If a construction #[<value1> <value2> ...] is simply interpreted as make <value1> [<value2> ...] , should this then be allowed: o: make object! [a: 1] #[o [a: 2]]
Geomol
Another thing to consider is, if the output from the contruction interpreter is sent to a code generator, how is MAKE constructed? Using the work, MAKE, isn't good enough, as the meaning of that word could have changed, so maybe something like:
#[native! make] or #[function! make] or #[native! 55] or something
Is it possible to create natives with constructions today, or is it beside the point of this format?
The end of a word is marked by a space, a new line, or one of the following characters: [ ] ( ) { } " : ; /
Maybe these shouldn't be in the list to open up for new future syntax rules: [ ( { "
It's hard to keep it simple! :)
Geomol
"I can see why Carl used the construction syntax he did, with blocks as the foundational structure, but I like the feel of #(...) more as I think about it, because of the paren semantics."
I agree on that one. Please, those who work on this and similar formats, consider this deeply! I'm not saying, I'm 100% sure, but it's worth given a great deal of consideration.
Geomol
And taking the space discussion and construction to the extreme, should these also be considered?
bitset!#{10101010 ...} bitset!"abc"
or is it better to create all such constructions with equal syntax, #( ... ) or #[ ... ]
Geomol
Benefit of equal syntax for all such constructions is, that they become easy to recognize, while given the other possibility too adds flexibility and often less to write. (There are no constructions in the World language yet. I see benefit in equal syntax across these languages. It will be easier for developers to switch between them for different tasks and/or benefits, each language deliver.)
Gregg
- `#[o [a: 2]]` doesn't seem worthwhile to me. - Native construction is outside the scope of this. - I don't want to take anything to the extreme. Let's stay focused if we can.
The question is still what basic construction syntax should look like. If there is value in adding other syntaxes later, we can look at that. For Ren, it's about data exchange. In that context, if it is to support an opaque construction syntax, there should be only one. If we can stick to just that question...
All those in favor of #[...] as literal map! syntax and #(...) as construction syntax, say +1. All those against, say -1.
Gregg
Please don't take this to mean that I'm ignoring other points. Ladislav's CC ticket on space significance raises a lot of good questions. I don't know that we need to change anything, but we do need to document it. e.g., in Ren, 'name is defined as [word space] currently, but all Redbol langs, AFAIK, allow a block or paren to omit the trailing space.
Andreas
Gregg, I think using #[..] as literal map syntax is no longer on the table.
I think the most agreed upon proposal at the moment is to just leave construction syntax as it is, and use either @[...] or @(...) as syntax for maps.
Replace "agreed upon" with "widely supported".
Andreas
So, -1 from me on shuffling things around to use #[...] as map! syntax and #(...) as construction syntax.
While I still like the idea of parens for construction syntax, I don't think the compatibility issues are worth the hassle. Neither is it necessary (or worth it) to free up the literal space for map, because we have a similarly nice-looking but non-breaking proposal on the table, which is @[...] or @(...).
AdrianS
+1 for @[...] or @(...) - I used to be for #[...] too, but for map in particular, the @ is more meaningful for me
Geomol
I need to implement and use a dedicated map! syntax in World to really have an opinion. Practical use sometimes reveal some issues. I like @[...]Êbetter than @(...) for map! , as I like #(...) better than #[...] for contructions, but as I haven't used constructions much, leaving it as it is for now is ok. When I come to implement constructions in World, I will have to figure it out, maybe even implement both syntaxes for a period as a test of usage.
Gabriele
I'm not sure map![a: 1 b: 2] is that much better than #[map! a: 1 b: 2] (ie, just drop the unnecessary inner block).
if we deem map to be important to be used literally in scripts, then a shortcut makes sense; it's just syntax sugar, nothing else.
I can imagine it being useful, however, since I never used it in practice, it's hard to tell.
Gregg
I must have missed where #{...] fell out of favor and @[...] was proposed. I'll write out some samples for myself, as I did before, to see how it looks to me. @ doesn't seem more meaningfull right off, but I'll try to keep an open mind (which still likes # being consistently special).
Gabriele, the literal map notation is important in Ren. That will leak out to Redbol langs if we want them to understand Ren natively.
Gregg
Today, I use spec-blocks in R2, and helper funcs for accessing them, but not as much as objects or straight word-value pairs in blocks. I would use them more if they worked like maps. And because the spec block syntax is much nicer for humans (IMO), I then take the extra steps on loading and saving objects to convert them, so config files and such are all basically literal map bodies.
Gabriele
For REN the extra #[map! ...] is not a big deal though. Is it?
Gregg
I can't say what a big deal it is, but the idea behind #[a: 1 b: 2] for maps was for two reasons:
1) For direct comparison to JSON. Cleaner and shorter wins there. 2) For use in config files and such. Avoiding datatype keywords for humans seems like a good idea.
:[...] came up as well, as did ::[...]. Those are nice from the standpoint of the : having meaning, but the single leading colon isn't as visible.
Pekr
what about asterisk? Does it imply multiplication too much? *[a: 1 b: 2]
Geomol
@[ ... ] for map! syntax is still on the table.
A map as a construction is #[map! ...] (as Gabriele point out, I think)
There is a distinction between the two. Better not let #[ mean more than one thing, and it is a construction today.
:[ ... ] is a get-block! (which is not a type today, but it's not a good idea to use this syntax for anything else).
::[ ... ] no no no! :) Not very Rebolish as I see it.
*[ ... ] nah, not a map to me. Might be a future syntax for multiplication of the whole block.
Geomol
About #[a: 1 b: 2] , I see no point in having to write all the keys as set-words. Map keys can be other types than words - strings for example.
R2 distinguish between keys of type word! and of type set-word! in hash! (old map! type).
Gregg
The reason for using set-words as keys is, again, for JSON comparison, but also because it makes a lot of sense to normal people. Whether we enforce that strictly in Ren is a good (and hard) question.
I can't imagine what get-block would even mean as a type. Blocks are not evaluated by default.
I will try to make time to write up a comparison matrix of alternatives. But I'm slammed with work at the moment, so will be happy if someone beats me to it.
Geomol
get-block!
This :[a b c] could mean reduce [:a :b :c] (sometime in the future).
Geomol
I'm not for required set-words in maps. Use contexts (objects), if that's more readable. I'm ok with both having words and set-words as keys in maps, and maybe they should be different entries into the map.
Gregg
We don't have objects. This is Ren. :-) We also don't have the concept of reduce.
Geomol
I think, you have objects. Ok about reduce, as it is a format. But I see, set-words are planned, so set-blocks may not be ruled out because of some syntax.
Oldes
"About #[a: 1 b: 2] , I see no point in having to write all the keys as set-words. "
I totally agree!... The main purpose of map! is that key may be any (almost?) datatype, not just word!
Gregg
For Ren, then, we need to consider the "almost" part carefully. I agree that being able to use anything as a key value is powerful. What *can't* you use as a key? This is important because the Ren spec needs to be kept a simple as possible, while still allowing much more expressivity than JSON.
From the perspective of data exchange, should there be anything you can't use as a key in a map?
Andreas
I think once we have the syntax settled, we can conceivably deviate between (base) Ren and full Rebol.
Gregg
And, again we're talking Ren here, is this a good thing?
Andreas
In Ren, it may be very useful to restrict potential keys slightly further, to ease interop with other languages.
For full Rebol, we could have slightly more relaxed restrictions.
In particular, I think that compound types as keys should be carefully considered for Ren.
Gregg
Yes, Ren is separate, and not only good for interop, but also a helpful constraint to require keys to be set words.
Andreas
Compound types: blocks, (parens?), maps.
Gregg
Potentially helpful. It's a tough call, because we think in terms of Redbol, and want to exchange all data seamlessly.
Agreed on compound types.
Enormous power there, if you allow anything.
Andreas
And enormous potential for problems as well, because you then need to carefully define a equivalence story as well.
But I think for primitive types, most if not all of them should be allowed as keys.
Gregg
Right.
And much more complex for interop, as you said.
Andreas
I also think that a relaxed restrictions on keys may actually be something of a "selling point" for Ren.
JSON decidedly represents "objects", which entails strong restrictions. But in practice, most implementations don't really exchange "objects" through JSON, but rather a generic associative datastructure (maps, hashtables, dictionaries). Also, because JS objects don't really fit that closely to objects in other languages.
So if we start with maps instead of objects in the first place, with relaxed restrictions on keys, we have a much closer fit to reality than JSON does.
Gregg
Agreed.
Lua comes to mind, because anything can be a key in a table, correct?
And the complexity of allowing them is offset by the consistency.
Oldes
"Ren spec needs to be kept a simple as possible, while still allowing much more expressivity than JSON."
So you should first of all not think about map! datatype, and use block! (without set-words) or object! (if you want set-words as keys), but map! with just set-word! key is a nonsense.
Oldes
One of real life examples why to use map! (or hash!) instead of block! or object! would be unicode collation http://unicode.org/Public/UCA/6.3.0/allkeys.txt - I don't see any usage there for set-word! keys. But I probably don't understand the main purpose of REN :-)
Rebolek
Actually, it doesn't matter that much, if it is map! or object! -- the thing is not to write "make map! [...]" or "make object! []" in REN (or use construction syntax). It should be simple and usable by people who do not know anything about Rebol.
Oldes
I just wanted to tell that map! with just set-word keys is not a map! and you should not call it this way as it confusing. Actually I joined this just because I saw map! notation syntax discussion... now I see that it's REN group.
(set-word keys in notation - word! keys should be used in my sentectes above)
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.
PeterWood
I think it would be useful to allow milliseconds, and possibly microseconds. The use cases I see are sharing profiling information, debugging information and logs (of high volume systems) via REN.
Geomol
Hours should be allowed to be more than 23, right? It's not just for clock time values, but also for how much time until some event.
Arnold
Sure I work 40 hours a week, 180 in 4 weeks about 190 a month.. Our project is 200 hours estimated. Etcetera and so on.
that should be 160 in 4 weeks of course, but I declare 180 for sure. No 620 minimal ;-)
Gregg
Any fractional decimal amount should be allowed for seconds.
integer : [00-59] : [00-59 opt frac]
Gregg
I think my current spec, which uses [2 digit] for hours and minutes, was modeled on IETF RFCs where they do the same thing. REBOL's behavior is different for time values that are part of a date, than for pure time! values. It throws an error on date! values with non-sexagesimal clock time values (i.e. > 23:59:59). Assigning a time! to a date/time does a modulo 24:0:0 on it.
Gregg
So we effectively have time! and time-of-day!.
PeterWood
You could sat duration! and time!
Endo
Fraction for seconds is good to be compatible with SQL datetime values (MS SQL Server at least) Duration! is also a good idea. If we don't use it, then I vote for HH bigger than 24.
Gregg
But if duration! is also a valid time!, how do you know which it is?
1) We are representing data 2) We have to keep the rules simple
Q. Should Ren enforce rules about time!, or just define what a time! value looks like?
Gregg
There is also the question of attacks with crazy values. If we allow things like mixed signs, does it make implementations easier or harder to get right? Same for large values (overflow) if we don't restrict it to sexagesimal.
Gregg
I never thought time! would raise so many questions.
PeterWood
One way to distinguish between a time! and a duration would be that a time would need a timezone.
03:00 could be considered ambiguous as a time without a timezone. A duration is indpendent of timezone.
PeterWood
The counter argument would be a use case, where you wish to distrubute a time of day independent of timezone e.g the time of a nightly back up being 02:00
Geomol
time-of-day is a subset of a time! value. So defining time!, where hours can be > 23, and the format can cope with time-of-day. Is it up to the format the put restrictions in this case? Isn't it up to the user of the format to assure, hours <= 23, if it's a time-of-day value? And putting time from a date value in Rebol/Red/World/what-ever-language into REN will just work, and no checking is needed.
Gregg
Right. For example, JSON says what a number looks like but doesn't specify limits on number of digits.
The case of date-time values is a little tricker. Should Ren allow you to specify an invalid time of day? If so, behavior may vary by implementation (unless we provide guidelines). If not, the spec becomes more complex.
PeterWood
I feel that the REN standard should be specific and that a time associated with a date needs to be valid. Implementations may differ. After all, browsers have always rendered "invalid" HTML, libraries handle "invalid" XML and, to a lesser extent, libraries handle "invalid" JSON (even eval() can if some circumstances).
Gregg
Consider http://www.ietf.org/rfc/rfc3339.txt . The ABNF for hours is: time-hour = 2DIGIT ; 00-24 But also refs ISO8601 in 3339, where it says time-hour = 2DIGIT ; 00-23
The text says this: "Although ISO 8601 permits the hour to be "24", this profile of ISO 8601 only allows values between "00" and "23" for the hour in order to reduce confusion."
One of the things I want to do is provide a grammar for Ren, to bootstrap implementations and reduce confusion. Is it OK to have a simple informative grammar in the intro, which hides details, and a strict grammar for the real deal? Or is that "bait and switch" (luring people in with false advertising)?
And will a more complex grammar and stricter spec scare people off, or be worth it in the long run, for consistency?
Gregg
Or can we safely say the informative grammar *defines* the normative rules, even if the BNF cheats a bit, like 3339? That is, are we allowed to strictly say that hours in date-time MUST be 00-23, but the reference BNF says 2DIGIT to keep it simpler?
PeterWood
I think unambiguous, concise and simple win everytime when it comes to specs. People seem to spend hours (if not days) arguing over an ambiguity I can just imagine the arguments "the time in a date cannot be 25!" "Yes it can the BNF only specifies 2DIGIT).
PeterWood
In terms of simplicity, wouldn't syntax diagrams, as used by Douglas Crockford, be a good alternative to a BNF?
While I've stated my position before on what I see as the follies of separation of Ren from the Rebol format (a topic for another time, another day), I still have an interest in the formalisation of the Rebol/Ren/Red format and am eager to share any efforts I produce to this end. As such, I'd also like express disappointment that there is a whole body of discussion on this topic in a closed space (AltMe) that is ornery to access with no public reflection. It's not my wish to open another [web-public] debate, rather just a request to reconsider this place as the main repository of thought on the formulisation of the Ren format (if indeed this is Ren HQ). Looking here and on SO Chat, I see two discussions that seem oblivious to the ideas of the other (and no, SO Chat would not be my preferred choice either).
Chris
'will a more complex grammar and stricter spec scare people off[?]' I'm of the opinion that it's better to get as close as possible to a precise spec. It'll lack the concise representation that JSON has, but then it's never going to beat JSON for brevity anyway. Ever.
I agree a central place to chat would be great, but I don't find SO effective either. Do you have another suggestion? And who else wants to take part that finds altme ornery to access? My intent is not to be private, but to make the best use of my time.
Good point on never beating JSON for brevity. The hard part is not knowing how far out to push before we hit a point that turns people away.
We all seem to agree that specific is good. Unfortunately, specifically "what", WRT time for example.
And I am oblivious to chat elsewhere about it. Where is it?
Pekr
Well, on one hand, it is good, that the community got to more public space, as SO serves as a stop-by channel for occassional lurkers, potentially interested in Rebol. On the other hand, it caused altme, which is much better for separated/private discussions, to almost die off. I don't understand the obstacle, it takes 1 minute to set-up and few secs to log-in. I will not even answer to the stubborn argument as of BrianH for eg. - I have not alme installed anymore and I will not do so :-)
SO definitely is much worse for a structured chat, cause of the nature of everything-fits-one-channel. And with various topics, the noise is quite high. I think there might be several options:
- new chat/talk system ... we speculated about some, but never tried anything else imo ... - google groups + wiki - it is public, can have threads/topics related to Ren, more formal proposals/summaries being written into wiki - altme + wiki - dtto
As for Google groups - it is like a forum. We can have several named threads there. Those might get long in nature, but we can continue with Topic name 2, 3, 4, etc. Rebol google group kind of died off, maybe it could make it lively again and Rebol would benefit, because if someone looks there nowadays, it seems like Rebol has zero activity there ...
Chris
Trello was one option I was thinking of that certainly would suit the endeavour, but may or may not be a conduit for free-flowing ideas--not sure.
Wrt. railroad diagrams: my point was that if you specify first in BNF, then the Railroad diagrams come for free...
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:
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.
Gregg
Right, the spec being: opt sign hours-minutes opt seconds
Rebolek
Actually, I'm never sure if 10:20 in Rebol is HH:MM or MM:SS.
Geomol
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?
Isn't Ren about what you allow users to write. How they interpret it, is up to each case. A string in one human language might mean something else in another human language, but it's still valid text.
Gregg
It's an interesting problem, because whether hh:mm or mm:ss is expected is based on context. The only way around that is to require all fields. Of course, REBOL made a good call, and it's right most of the time, but I've been tripped up by it a couple times myself. More importantly, you have to explain it to everyone that needs to use it. hh:mm:ss is unambiguous.
But if it can be either, and we only allow decimals on seconds, it gets trickier still.
Geomol
In a language with computation, you need to explain, yes. But in a data format, couldn't you let it be up to the user, how to interpret two integers separated by a colon?
The argument to mee is like sending just one integer telling the receiver, it's the number of days until some event. If the receiver choose to interpret the integer being number of weeks, we have a problem. But I wouldn't restrict the format because of just misinterpretation.
mee -> me
Gregg
My point about context, yes. BUT (all caps), what does your spec look like now? Ugly is what.
Geomol
:) Date and time is some of the hardest datatypes to implement.
Rebolek
I think the REN data format should be self-explaining. XX:YY isn't.
Gregg
Now we know why JSON left out date-time. :-)
If we make seconds optional, the onus is on the user to make things unambiguous if they want. If we say two segments are hh:mm, that's what they are, even if we sometimes forget. :-\
Geomol
World goes a bit further. Examples:
w> 12:00 + 1 ; Here 12:00 is HH:MM == 12:00:01 w> 12:00.1 ; Here it's MM:SS.1 == 0:12:00.100000
So if you just have two numbers separated by a colon, it is minutes and seconds, if you have fraction also.
Gregg
REBOL does that as well, which I think Ren should NOT do.
Geomol
Ah yes, Rebol does it too.
Geomol
Maybe you need Loose Ren and Strict Ren?
Gregg
Nope. Need to keep it simple.
Geomol
agree
Gregg
That doesn't mean people can't write tolerant loaders though.
So if we start with hh:mm:ss all being required, and everyone writes loaders that allow just hh:mm, changing the spec to allow that won't invalidate any existing Ren data.
Geomol
It's almost mission impossible. Easiest then is to skip date and time, so users need to use strings. But this is probably not, what we see as a useful format coming from Rebol.
Good point, Gregg.
Gregg
If we leave out date-time, we're not much better than JSON.
It's just "mission compromise".
But if REBOL, Red, and World all allow just hh:mm, we're incompatible
No perfect answers.
Rebolek
There won't be 100% compatibility anyway. No construction syntax, etc.
Chris
Gregg, "rather than just hoping it will be better"--don't misunderstand me, Trello is better than AltMe. Hands down. Works on mobile, syncs across multiple systems. Despite this not being single-threaded chat, it is still chat with most of the negatives you associate with SO Chat.
Chris
However, y'all seem unconcerned with opening the process beyond a private AltMe channel. Can't say I'm not disappointed and would request again that you reconsider.
Gregg
What's the benefit Chris? As in "What's in it for me?", since altme is a very effective tool for me.
Chris
Assuming Trello as a for instance, you get an organised collaborative space that works across platforms, allows controlled access yet public viewing, has an api (Brett has an API script, I have some non-api scripts) where, for example, you could actually arrange and pull the specification itself. It allows for chat (via comments) but is geared more to the long view--ideas are not lost because they were missed in the chronology and collected information/reference can be placed in context. It also is accessible for those for whom AltMe is not a very effective tool.
Rebolek
+1 for Trello.
Arnold
(+1 for AltME) I fail to see the benefit of public view if all discussing the topic are on AltMe, unless you really need to hold your handheld all day. What I see from the two Red Trelloooos I am not impressed. About the hour and minutes and seconds, hh:mm vs mm:ss In this notation indeed the difference will not be determinable from data that is filled in the fields alone. But in practise there is an agreement about what is in the designated place and how the data must be interpreted. Else we have to come up with an alternative that will distinguish between 12:30 (hh:mm) and 12:30 (mm:ss).
Gregg
So it's not designed for chat, which is an important collaborative element, ren-data.org is public and the system of record. Trello solves problems I don't have. However, point me to the best example on Trello for a use-case like this, and I'll re-evaluate. Red uses it, so I'm semi-familiar with the UI. Just need a good example to convince me it's worth the effort.
I should say ren-data.org is *my* current public site and *my* current system of record. Bolek has his stuff on Humanistic, and I don't mean to imply that I an Ren's owner.
It might be nice to have a per-type chat area, which we can do here as well. Heck, we could even set up a Ren world. ;-)
Chris
Arnold: "unless you really need to hold your handheld all day" -- or use a Mac.
And Trello on a tablet is a nice experience.
Gregg: I agree--chat is an important element. That's one reason I hesitate to suggest it. However, chat alone is a very poor way to collaboratively coalesce resources. Too much gets lost.
(and using AltMe again for this brief stint, I miss being able to edit posts, star posts, feeds and oneboxing)
Gregg
At some point I will move my resources to github. I think that's better than Trello.
Trello is about managing a project, right? That's not our problem.
Arnold
Chris, I am on a Mac and I have also access to AltMe on a Windows PC and I have hardly any trouble with ALtME on the Mac, just have to help it scroll and refresh, sometimes I need to reopen the world because my comment is not coming through, but it is still there to add to the group
Chris
Yikes, I'd forgotten about losing messages when it silently disconnects.
Chris
Gregg: Trello is fairly open in how you use it. It could be managing a project, it could be managing the resources of a project, it could be channeling the discussion on aspects of the project. As I suggested, it could also be the project.
Gregg
OK. Show me the best project match on Trello for Ren.
Arnold
Chris, also why I have put some links for Objective-C and Cocoa bindings in the MacOSX group. For the binding has been done for 'competitor' small languages, so why not for Red or R3 and put them on the map too.
Chris
Gregg: I don't know of a project quite like Ren that uses Trello. Perhaps the closest project in recent times is CommonMark that uses a combination of GitHub and Discourse.
Arnold: Mac OS X--another private group that requires logging into AltMe to view.
Gregg
I'm familiar with CommonMark. The initial spec was solidified before Discourse, correct?
Pekr
Altme losing messages is mostly a myth
Rebolek
Gregg, just a clarification, Humanistic on GitHub is organization with ten members including you, so feel free to update the stuff there.
Gregg
Thanks.
Pekr
Rebolek - 10 members? Oh my, that is almost more, than Rebol and Red counted together :-)
Chris
Gregg: I don't know--do you have a reference for the origins of the original specs? Seems beside the point though--to reiterate, there is already more than one island of discussion happening on the formalisation of Rebol (whether that is Ren--if you think of it as such--or just a formalisation of Rebol). Perhaps that's for the best, all told. Just felt it worth pointing out and trying to suggest an alternative.
Petr: rediculous--I've been using AltMe as long as anyone, I'm painfully aware that it's more than 'mostly' a myth.
-- Ridiculous, argh: where's the edit button?
Petr: SO Chat room for [Rebol and Red] (and none of which are Brian D.)
...has 12 owners...
PeterWood
Perhaps the discussion about using an alternative to AltME could be continued in a more relevant channel. Perhaps self would be appropriate.
Gregg
Thanks Peter.
Gregg
Ren isn't just a formalization of Rebol, since it isn't compatible, though it is in a sense. ren-data.org says what it is, with a strong influence being a desire for interchange between REBOL-like languages.
Pekr
Well, if my understanding is correct, REN has nothing to do with Rebol/Red, apart from being implemented first for the Rebol like languages ....
I have looked at ren-data.org for the first time, and only now I realised, how bad it is :-( Who is this site for? Apart from being aesthetically displeasing (yellow bg color? common), it seems like it is written for the programmers, who know parsers and are supposed to port it to other languages? Not sure this is aproach, which is going to sell the ideas. Such stuff should be imo put into some subsection and front page should be more "marketing" oriented, showing some examples, dialects, without any grammar info ...
Ah, I just got to the json.org site, all clear now. It is terrible, how such popular technology can dare to be represented by such "web site" ... but - that's a different discussion ....
Gregg
Sorry you don't like it Petr, it's all me, but you understand the target audience it's directed at.
Chris
Gregg: despite different end-points, it's likely that 95% (a made-up number) of Ren would be cross-applicable with any formalisation of Rebol, at least as I see it. Perhaps not?
Pekr
I thought, that in regards to Rebol lang ecosystem, it would be 100%?
Chris
Petr: in my mind formalization would be that as I've always seen Rebol primarily as a data format with an informal specification (with a very definite implementation in l-scan.c and to a lesser extent in the Red source tree--if I'm not mistaken in both Rebol 2 and Red/System(?) that is in turn interpreted/compiled). Formalization to me affords a base to make informed changes to the language and to guide de/serializers in other languages. As I understand it, the goals of Ren are similar but with a sense that there are features of the Rebol format that would make implementations in other languages more prohibitive.
(not lesser 'cause it's Red, just because is still in the works :)
PeterWood
One of the bad parts of JSON for me is the hassle of escaping multiline strings when more often the not the JSON is a multi-line string that mustn't have the newlines escaped.
Is is possible to add {} for multi-lined strings?
PeterWood
One comment and two questions about the definition of strings - "A string is a series of zero or more Unicode characters" 1. It would be better to refer to code points than characters. 2. How will the string be encoded? I presume the straightforward is the same as the REN document. (I see that the JSON standard allows for UTF-8, UTF-16 or UTF-32). 3. Will the ^escaping provided for specifying hex codepoints such as ^(010000) ? If so it will need to be made clear that it the value of the codepoint is to be supplied (so that people don't escape the UTF-8 for the codepoint be accident.)
PeterWood
I've read the "spec" a bit more thoroughly, the answer is yes. I would like to ask for 2 and 6 digit hex strings to be allowed (for convenience). I think it needs to be noted that the hex number is the number of the Unicode codepoint.
One point about encoding. If the standard states that REN documents must be UTF-8 encoded, that makes life easier for implementors as they don't need to worry about handling the endian issues of UTF-16 and UTF-32.
It is also very good for REBOL3 and Red implementors as both use UTF-8 by default. (Not too good for REBOL 2 though.)
DocKimbel
@Chris We have two lexers in Red, one is written in Rebol for the compiler, one is written in Red (and no more in Red/System) for the runtime part (LOAD support).
Gregg
Pekr, It can never be 100%, as R2, R3, Red, World, etc. all differ somewhat.
Chris, right.
Peter, I want multiline strings as well. Initially I tried posting proposals, building up from base types, to try and gain consensus. Didn't work so well. So consider the current spec to have gaps. I will adjust the text to refer to code points. On convenience, which applies to multiline strings as well, Redbol compatibility is a primary concern, but also keeping the rules as simple and unabmiguous as possible. Unicode isn't my area, so I will defer to you and others on cost/benefit.
To Petr's (Pekr) point about hiding the grammar on a detail page, I did just recently think about doing something like that. Not entirely, but leaving out sub-rules like int, frac, exp, etc. since the main page is just informative. That is, just list the top-level types.
However, the page was intended, as Petr so astutely observed, for the people who might implement parsers and generators for it. The idea being to have a single page that offers a description and reasoning for each datatype, with the informative grammar right there as well.
Gregg
I think multiline strings offer so much value that we need them. Any strong arguments against?
On encoding, I'm good with requiring UTF8. Any arguments against?
Rebolek
I agree with both multiline strings and UTF8.
Gabriele
one note about multiline (not just strings, in general): a lot of things assume JSON to always be able t o fit in a single line. Eg. use line terminator as delimiter between JSON objects. (Eg. IPC in node.js is line terminated JSON)
Gregg
Interesting. There is certainly something to be said for mashing things into one line in certain contexts. I have a SINGLE-LINE-MOLD func I use for logging, for example, and having tools that could operate in a mix of line-oriented nix fashion with each line being structured, is a possibility too.
DocKimbel
Gregg, did you miss MOLD/FLAT? :-)
Gregg
It doesn't remove line breaks.
Ah, Red does. So my func is obsolete. :-)
Though mine, IIRC, replaces line breaks with their escaped counterparts.
Ah, Red does that too, on ML strings. You win. :-)
And thank you. :-)
DocKimbel
;-)
Gregg
Back to time!
Gregg
# Use cases - standalone time (point in time) - standalone time (duration) - part of date-time (time of day) - timezone (offset from UTC)
My argument for this is that it keeps the rules simple, and is flexible but still constrained.
Votes? And if you vote No/-1, a short reason please.
DocKimbel
-1 because I think that date! and time! values should be normalized in a data exchange format. Though, specifying such rules would make the spec significantly more complex, but not doing it would just shift the burden onto the implementers, which might result in different interpretations. For the duration use-case, I am for using a different format than time!, maybe resulting in a new datatype.
(I am taking the perspective of people implementing REN in non-Rebol languages)
Gregg
How does the above proposal make it harder for non-Redbol languages?
Anything specific in YAML? I do note it, and other formats evaluated and why Ren isn't them.
DocKimbel
YAML format is getting traction among open source projects, it is nicer and richer than JSON. It provides "heredoc" features for embedding other formats (like XML or JSON). It's a very good human-readable format. OTOH, the specification itself is rather long and complex, but that is not a show-stopper for YAML adoption among many languages. I think we have to learn from it.
Maybe providing a C-level library for Ren would be a good way to simplify the integration with non-Rebol languages.
Gregg
I looked at YAML in depth many years ago, and even started a parser for it at one point, thinking it looked OK on the surface, but I quickly gave up on it. Aside from a couple JS tools using it for config/proj files, I didn't know it was gaining wider traction. What looks simple and readable really has complex rules that can leak through to users. I'm happy to have someone point out specific things we can learn from it though.
I mentioned a C Ren lib as an important piece to aid adoption in another group, so I very much agree.
Interesting. I hadn't seen that. It's not just a format though, it defines a lot of behavior as well. I think we may offer some guidelines for Ren library behaviors, but I don't want to head down the path Hocon has. And some things just seem like a bad idea. e.g.:
// this is an array with one element, the string "1 2 3 4" [ 1 2 3 4 ] // this is an array of four integers [ 1 2 3 4 ]
Gregg
It did remind me of something on a Units type format. They talk about n^2 vs n^10 byte values and, e.g. the kilo vs kibi prefix or kB vs Ki. For byte units, my thought was to do something like binary! where you would do KB2 or KB10.
I wish there was a page with side by side JSON vs this for example.
Gregg
Map comments (also posted in Gitter)
I'm considering both [] and () as list and map brackets for Ren. What I haven't considered is the newer concept of allowing any value as a key. If Ren supports that, does it even need a separate map type? If Ren requires set-word keys, Red can directly support Ren maps, but not the other way around. Red maps would have to become Ren lists. If we do that, we lose the ability to distinguish them from parens when exchanged via Ren.
The idea of allowing () for lists is that it makes Ren more Redbol compatible, as well as flexible for those not used to square brackets. We may decide that more constraints are better, at least to begin with.
There is nothing that says Ren has to require pairs of values either, though there is certainly merit in that. We could just as easily say that a leading # before a list is just a hint.
e.g., if there is no map hint, the loader should never try to coerce the result to a map, if there is a hint, the loader decides what type to coerce to based on contents. If there is no outer list, as in a streaming scenario, there is implicitly no hint.
Remember that map! in Red is just a specialized version of hash!.
And hash! is as flexible as block! is.
Gregg
Understood. The question is not what Red can do, but what Ren should support.
DocKimbel
Well, if you move too far from Redbol syntax, I'm not sure where you want to go with Ren.
Gregg
I would love for Ren to just LOAD in all Redbol langs. But they're not all equal either.
DocKimbel
At the beginning, Ren was about promoting the Rebol data format, so that non-Rebol users could enjoy a more human-readable format. But I'm not sure what are the current goals now?
Gregg
And it needs to balance against a JSON comparison.
My goal is the same. Basically REBOL, perhaps eliminating things to appear simpler, and the need to add a literal map syntax.
DocKimbel
If you don't have the need to support construction syntax in Ren, then it frees the #[...] form.
Or you can use #(...) as in Red now (and in Rebol3 in the future).
Gregg
Right, hence my questions above. Does Ren not care what is in the block structs? If it doesn't enforce name-value pairs in #[] or #(), then old construction syntax and Red maps are both valid.
Pekr
I really hope that we also implement -4 proposal from Fork, as a good consensus to what Ladislav requested as strict space requeirements. That would bring us possibility to come up with more forms ....
Gregg
That's where my thought about # being a hint came from.
Pekr
is there a website for -4 proposal? Or is that just in terms of Ladislav's CC ticket?
Gregg
What are you talking about Petr? Case senstiive map keys?
Pekr
no ... Idon't want to distract chat in this channel, so sorry for that. Ladislav came with the request of strict requirement of spaces even for stuff like [( ....)], should be [ ( .....) ], Fork relaxed it to just 4 cases. But it was supposed to make stuff like 'func(code here) illegal (Doc uses this trick IIRC in R/S, to look more like C func call :-)
>> print("hello") hello >> print["hello"] hello
My understanding was, that it would allow to have various construction forms more easily .... but not sure, if I am not confused :-)
WiseGenius
IIRC, it was just on the ticket and not yet written up, but I could be wrong.
Gregg
We need only a minimal set of forms. I think Ren is at 23 so far. :-)
My thought on simplifying is to reduce most any-string! types to one type (implied string), and collapse both block! and paren! to list. So I would rather not have separate #[] and #() types with very different rules.
:-) I remember the ticket and chat.
I am concerned that if we don't have a clear map type in Ren, it may be seen as a weakness or gap. So we have to be able to clearly state the benefits and limitations.
DocKimbel
"Doc uses this trick IIRC in R/S, to look more like C func call" Only for R/S macros with parameters, to more easily spot them among regular code.
Gregg
You can look at http://pointillistic.com/ren/ to see what I have spec'd at this point. Open questions are path types, exact word syntax, and tag values. Comments or questions on other types are welcome.
Gregg
Does anyone object to this group being [web public]?
Andreas
web-public: Fine with me.
DocKimbel
No problem
Rebolek
no problem
Arnold
No problem
Gregg
Done.
SWhite
Where is this now? Sometimes a person does not understand what he is looking at when he first sees it. I am in an SQL training session and just learned how to export query results into XML. As I looked at the XML results I thought, this is ghastly; someone should make a data interchange format more like REBOL. Then I remembered that someone has...
Gregg
You can see the state of things at ren-data.org.
Still some decisions to be made, and no reference implementations up yet, though I have a mostly done R3 parser for it which should port easily to R2 and Red.
Gregg
Aside from the things that have ??? next to them in the informative grammar sidebar, 'quantity was something I put in there as a reminder to myself but is just a thought right now.
SWhite
Do you have a tool for quick production of those railroad diagrams, or did you have to "brute-force" them?
Sorry, I just now found that link. I always am a bit too quick on the keyboard.
Gregg
NP.
I hope to build one in Red. After that, it would be cool to have an interactive diagram that can be used to go the other way and generate parse rules from it.
SWhite
I got the impression that the REN format is something that is, by happy coincidence, practically "native" to REBOL and can be interpreted with the "load" function. Because of its likeness to REBOL it is easy to read, and then because it is easy to read it should be easy to interpret in other programming languages, and because it is easy to interpret in other programming languages it will be. In other words, REN is easy to use for all, but REBOL has an advantage, because of REN's "REBOL-ish-ness." .
Gregg
Yes. A very happy coincidence indeed.
There are some details to iron out, because getting too detailed will make Ren complex and scare people away. Too simple and the benefits over JSON et al aren't clear. Then there's the question of what each language in the Redbol pantheon can support easily, and what can be done in other languages. It doesn't mean Ren will be a lowest common denominator, but that people might need to not use every feature to its limit if cross language compatibility is important.