I've been reading the threads about multiline strings and using {} for arrays, and I'm thinking that the header is going to look rather messy given that's it's not uncommon to have multiline statements there.
Rebol [
Title: "Your module title here"
Type: module
Name: your-module
Rights: -{
Copyright 2012 REBOL Technologies
Copyright 2017-2021 Ren-C Open Source Contributors
}-
License: -{
Licensed under the Apache License, Version 2.0
See: http://www.apache.org/licenses/LICENSE-2.0
}-
Description: \{
Weirdly this does not look as good, despite dropping a character.
printf("The char is } and it need not be escaped\n");
So that's good. And here we can do \n\n\n for escaped lines.
}\
]
As an alternative I quite like the way yaml is written, it's very clean without a lot of funny distracting escape characters. Can we consider using a yaml dialect for the header?
Rebol -{
Title: Your module title here
Type: module
Name: your-module
Rights: |
Copyright 2012 REBOL Technologies
Copyright 2017-2021 Ren-C Open Source Contributors
License: |
Licensed under the Apache License, Version 2.0
See: http://www.apache.org/licenses/LICENSE-2.0
Description: |
This would be YAML-based.
printf("The char is } and it need not be escaped\n");
So that's good. And here we can do \n\n\n for escaped lines.
}-
So the header would be scanned and loaded as Rebol, from the YAML. Hmm.
Putting a YAML parser in the box, and having it available to call it up in places where Rebol is weak by comparison, is actually a pretty compelling idea.
YAML's success shows that the Rebol-inspired JSON isn't always a fit, and even with FENCE! we'll probably not match up in some cases.
The parser could have options to assume that if you said field: [a b c] or similar, to treat that as a BLOCK! instead of raw text. (Though it should be able to do "pure Yaml" if that's what people want.)
It's a bit of a sacrilege in the "all is Rebol" groupthink, but we should take this idea seriously.
Not sure I agree. YAML syntax in many ways strikes me as almost the opposite of Rebol conventions, for instance:
It’s indentation-sensitive
Its syntax is fairly rigid, not free-form at all
Each data structure can be written in numerous different ways
Parser needs to do a lot of work, e.g. to resolve cross-references between elements
If anything, Rebol strikes me as being a lot better than YAML. I often see people complaining about how confusing YAML is to read and write; there’s no need to import that confusion into Rebol when we already have perfectly good ways of writing data structures.
Well… insofar as I understand the concept, dialecting in Rebol amounts to reusing the constructs of the language in new ways, to create context-dependent sublanguages for solving specific problems. As @hostilefork put it:
This is quite a different concept to ‘create your own totally separate language’. Rather, dialects are about giving different semantics to things which already look like Rebol programs. You can use dialects to help implement other languages (e.g. the Whitespace interpreter), but it’s not the same thing.
So, if you wanted to integrate YAML into Rebol, the natural way to do that is to add YAML as a new literal syntax, which you can then use as the basis for dialects. But I’ve already explained why that’s a bad idea. The alternative is putting stuff in strings, which immediately loses all the advantages of Rebol’s rich set of datatypes.
You're right that the principal win comes from accepting the parts in the box, and parsing BLOCK!s (not kicking into a custom text parser for your language and parsing TEXT!s...)
But the new binding model does make it more feasible to mix and match, where your mini-language does evaluations with escaped bits that LOAD and bind as code. And it's doing a great job in CSCAPE...
So I think we should lean into empowering it where possible, even if it isn't the primary pitch.
So the concept I was thinking was that it would be possible to detect Rebol types, along the lines of:
>> obj: yaml.load/rebolish -{
Title: String " With } No { Delimiters "
Description: |
YAML lets you get away with this kind of thing.
You don't } worry " about ' escaping
Modes: [read write]
}-
== make object! [
Title: -{String " With } No { Delimiters "}-
Description: -{
YAML lets you get away with this kind of thing.
You don't } worry " about ' escaping
}-
Modes: [read write]
]
>> type of obj.Modes
== &[block!]
Basically if it saw something like a bracket at the beginning of the content for a value, it would kick over into the Rebol interpretation...if you specified you wanted that mode of interpretation.
Rebol has a lot going for it representationally, but losing plain braced strings does hurt a bit... when they were already a little ugly.
But maybe that's just life. It's hard to say when something first pops up if you'll get used to it or not... so I think it needs to be given time.
Hmm, this is interesting; I hadn’t quite realised this is already used. It does make me nervous though, since it means we can no longer use our usual tools for structuring programs.
(If I may philosophise for a moment… I feel there’s a big, gaping hole in my understanding of how we decide ‘what Rebol syntax is’, so to speak. Perhaps my caution around sigils and TYPE-BLOCK!s are a manifestation of that hole, as is this. I’ll make a new thread about it if I can figure out any clearer way to articulate my concerns.)
Losing plain braced strings does hurt, indeed… but compared to all the messiness YAML brings, it’s a very minor thing.