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.
"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.
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.
Does anyone object to this group being [web public]?
web-public: Fine with me.
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...
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.
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.
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.
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.
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." .
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.