World: r3wp

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.

oh.. my message is reply to Gramam's:

@Ladislav ... the { } only have special significance because the 
interpreter is so written ...  so why not make it user definable 
?
I've not noticed I'm not at the end of the chat :/

Three reasons:

- The { and } are not chosen at random, they are the consequence 
of using those characters to delimit strings themselves.

- There aren't many characters or character sequences that can be 
optional without conflicting with other stuff in the grammar.

- Syntax processors with user-defined stuff in them are much slower 
than ones without them.

Hi, I have a client whose ftp username has an ampersand @ in it. 
I think that's causing a problem accessing it. Is there a way around 
that or should that work?

Try read (write etc) like this:

     read [ scheme: 'ftp host: domain.com user: user-domain.com pass: 
     "password" ]

Or see what other people have tried in the past:
    http://www.rebol.org/ml-topic-index.r?i=ftp

Thanks Sunanda. that was it.

Regarding the "why the heredoc syntax was proposed" question, here 
is another reason, that is important for me, proving, that even users 
not planning to use other languages than REBOL can take advantage 
of it:


In my REBOL script files, I usually write code examples, or code 
tests, that are meant to demonstrate the newly defined functions, 
or to test whether they work as expected. That code is in no way 
meant to be run every time the script is run. Therefore, I use the 
COMMENT function to ensure the example/test code does not run every 
time the script is run.


Since it is a comment, I prefer to use a string to be able to write 
it "free-form" not being bound by the requirement of loadability 
of the text. However, when the code examples in the comment contain 
special "escaped characters", this would look ugly, therefore I rather 
give up the free-formness of the comment gaining the advantage of 
not being forced to escape the special characters, but being forced 
to keep the comment REBOL-loadable. The proposed heredoc syntax can 
solve this, and similar problems nicely and naturally.

(this property just "mimics" the property of the ; single-line comments, 
which does not need any character escaping as well)