World: r3wp

I think we need to consider what the MOLD output looks like, though 
I'm not sure about Oldes's suggestion of a /heredoc refinement. And 
while I like Ladislav's serialized rebol syntax, I wonder if there 
are other possibilities. Could we leverage the << heredoc standard, 
and would that be better or more confusing with the tag! type as 
a close relative. It also makes me think more generally about where 
it fits in the rebol lexicon. Is it still just a string!, or are 
there wider implications? What do we call it? Is its main purpose 
to make dealing with curly-brace languages easier, and is that just 
a vague "nicer thing" or are there specific cases we have in mind 
(e.g., test cases :-) ? If rebol is still at its heart a messaging 
language, how would we leverage this type of "payload"?

Why can't we redefine chars eg. in some sql dialects you can define 
the terminating character.  So, why can't we redefine the another 
character temporarily so that has the same functionality and then 
{} become ordinary characters?

Could we leverage the << heredoc standard - actually not, <<is already 
taken, it is a word in REBOL

so, that would not be backwards compatible with REBOL syntax

I updated the comment to mention the advantages of the proposed syntax 
as I see them.

 Is it still just a string!, or are there wider implications?
 - of course, this is yet another string syntax

Adding it, we will actually obtain three types of string syntax

Note to the {...} syntax. It actually is a heredoc-type syntax. The 
only trouble with it is, that it does not have the variable part.

...so it has to use escaping for #"{" and #"}"

, which is a problem, since the use of escaping defies the whole 
purpose of it

What do we call it?
 - I propose "the heredoc syntax"

Is its main purpose to make dealing with curly-brace languages easier

 - not, I would use it to transform the core test suite to REBOL (which 
 it actually isn't now)

(that is exactly what you proposed in the Testing and Tools group, 
every test could be)

#[[test
; this is my test
test]]

Moreover, you can easily embed just about any text in REBOL, not 
just the source of curly-braced languages, but even REBOL code examples, 
or any general text that comes to mind without worrying about escaping

REBOL is not just a language allowing computers to communicate (if 
it were, escaping would be enough for every string), but also a language 
allowing humans and computers to communicate. And, I do not find 
escaped strings to be easily writable/readable for me, that is why 
I prefer to have the heredoc syntax available.

So, in general, the usage of the heredoc syntax shall make REBOL 
more readable/writable/handleable for humans, which is a good thing 
(tm), if it weren't there would be no reason to not use the machine 
language still.

#[[Graham

Why can't we redefine chars eg. in some sql dialects you can define 
the terminating character.  So, why can't we redefine the another 
character temporarily so that has the same functionality and then 
{} become ordinary characters?

Graham]] - I do not understand how would such a proposal work. Can 
you be more specific, showing an example?

Generally spoken, I do know what the advantages of the heredoc syntax 
are, and I hope I succeeded to communicate that to you. The syntax 
is used in other programming languages, making them more comfortable 
for humans. Not having the syntax in REBOL is not good, especially 
taking into account, that REBOL, as opposed to the above mentioned 
languages, is not just a programming language, meaning, that in REBOL 
you can write more than just programs.

#[[Carl

Although it can be used for programming, writing functions, and performing 
processes, its greatest strength is the ability to easily create 
domain-specific languages or dialects.
Carl]]

@Ladislav ... the { } only have special significance because the 
interpreter is so written ...  so why not make it user definable 
?

Maybe it's not possible without an extensive modification to the 
parser .. I don't know

OK, Graham, show me, how would you handle this string:

#[[example
'^{<+-*/%([#&$a0:;=\|,.}>)]
example]]

not to mention, that I could have put in all 127 ASCII characters

You would define another character(s) instead of { } to be used .. 
normally most languages have them, so if you switch to that language, 
you would use that character

I would do nothing, I am interested in knowing what would you do.

I presume the idea of this is to easily generate javascript and the 
like

You as in the generic person and not you as in Ladislav

Do not forget, that the string contains more characters that need 
to be escaped, than just the #"{" or #"}"

actually, you as Carl as the rebol language implementor

#[[Graham

I presume the idea of this is to easily generate javascript and the 
like¨
Graham]] - I presume, that I wrote above, that this is not true

I was on the fence about the heredoc proposal, but now that Ladislav 
has come up with a syntax that makes sense (this was missing from 
the previous proposal) I am now all for it. One caveat though: It 
would be best if, like other string syntaxes, the syntax details 
are thrown away after loading. By this I mean that
a
{a}
#[[blah
a
blah]]

should all generate the same string. Once it is loaded, there should 
be no way to determine that it was specified as a heredoc. Heredoc 
should be syntax only, not in any way affect semantics.

I can see many uses for heredoc syntax, not just generating Javascript. 
But it would be good for that too.

Oh, and not just ASCII; full Unicode.

I don't think we can throw away the meta info about it being a heredoc 
string, unless we want to use Oldes's idea of adding a refinement 
to MOLD. And then you have to choose when to use it. While we can 
say that it's easy for MOLD to add escapes to curly braces, that 
doesn't mean it will be easier for humans to read generated strings 
that contain them.


I can't say I've ever needed it personally. The { } syntax works 
well, and is as much support as TCL has for heredoc strings it seems 
(we even have TRIM/AUTO to help with indenting issues).  


I want to like the idea a lot, but I only like it a little so far. 
Mainly I wonder if it's worth adding for the sake of just the curly-brace 
chars. I understand the usefulness for the curly-language and test 
dialect scenarios, I'm just not sure of the cost/benefit ratio.

No refinement to MOLD needed. MOLD should know nothing about heredocs. 
Use a separate formatter function, like this:
mold-heredoc: func [value tag [string!]] [ 

 ajoin ["#[[" tag "^/" either string? :value [value] [mold :value] 
 "^/" tag "]]"] 
]

And once it is loaded, it is a string. There is no escaping in memory.

We *really* don't want to add another string type, since that would 
lead to conversion overhead. Another syntax for the existing, unchanged 
string! type is fine though.

Yes, my point is exactly the same, even without any new datatype, 
etc., having just a new syntax to specify strings will be of advantage.

I hope, that we all agree, that, as opposed to other string syntaxes, 
there will be no escaping in heredoc, meaning, that the two strings 
below will be equal:

{^^}

#[[
^
]]

The proof is in the pudding - even now we do have two syntaxes for 
strings, and no string contains any information specifying which 
syntax was used (it is even possible, that none, since a string read 
from a file was not defined using any of the two.

Interesting, I was assuming that we were going to make the tag required. 
Mention that it is optional (or possibly an empty string, if you 
prefer) in the ticket.

Whether the tag is optional or not - well, I am not firmly at either 
side. Nevertheless, the empty tag can be considered a tag as well, 
just a special one.

Will mention that in the ticket

As long as the constraints I mentioned in the first comment to that 
ticket are kept, I'm all for it. Plus, no MOLD refinements.

That is OK with me

Let's also stick to text. No binary data in our strings.

Some languages have raw binary heredocs, but that doesn't work well 
with Unicode strings, nor does it post in text mode well.

Agreed, I do not see any need to have binary heredocs

maxim - regarding namespaces: Are you kidding? I'm not even going 
to touch those. My excuse is if xml-object.r can't handle it, neither 
will I. :^(

Because it's complicated? Heredoc is enough for me and I'm lucky 
I'm not alone who found it missing.