Or you can use #(...) as in Red now (and in Rebol3 in the future).
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.
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 ....
That's where my thought about # being a hint came from.
is there a website for -4 proposal? Or is that just in terms of Ladislav's CC ticket?
What are you talking about Petr? Case senstiive map keys?
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 :-)
IIRC, it was just on the ticket and not yet written up, but I could be wrong.
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.
"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]?