World: r3wp

Ah, I had forgotten about that (thanks).

Plugins vs plugin blog - make your vote .... http://www.rebol.net/r3blogs/0230.html

Sunanda, latest R2 should be limited at 32k words.

Thanks Gabriele. 32K is getting useful. Sadly, for me. I support 
an elderly View system with a limit of 4100 (or so) words. It gets 
tricky at times :) (I guess we;re off topic for R3 here)

I just discovered that rebol3 can escape a forward curly brace as 
in  str: {text^{}

Is there any way to get  ^{ as an escape comparable to ^}  into rebol2.7.6 
?  2.7.7 ?  Otherwise generating string comtaining both dbl-quote 
" and curly-braces seems quite maddening ...  when using REBOL on 
server-side what is easy in PHP or PERL is suddenly a challenge ... 
or am I missing something about wrapping strings in curly braces 
?

My problem   token:  join  { ^{ text color = "red", name = "test1" 
}  [ token2 token3 ] ; when first value has many options and is spread 
across multiple lines for readability, the string value requires 
curly braces; token  is ok to be   token3:  { some text  values and 
then clsing escaped curly brace^} }

I see no change recorded at http://rebol.com/r3/docs/datatypes/string.html
   Is there really no hope of   {" folowed_by_space then whatever 
chacters I please _ending_with_space _before "}   or some such as 
  {~ space_before_text_then_ending_space_before ~}     It is so odd 
that for our emphasis on value that a string containing  a linefeed 
and an odd number of braces is an error.  After all,   an odd number 
of colons is not an error !   Why MUST we escape characters rather 
than allowing true LITERAL string values ?  We even allow semi-colon 
within braces without an escape !  ;comment anyone?

Robert.  { ^(7B) ^(7D) }   ?? Maybe?

Sounds interesting. A few comments:

- Colons and semi-colons don't have special meaning within REBOL 
string literals - { and " do (depending on how they are specified).

- String literals in programming languages almost always have escaping, 
though the capabilities vary from language to language. Escaping 
is done to include data in the string that would otherwise break 
the syntax. Without escaping you will never be able to include certain 
characters or character sequences.


There's a lot of terms and methods for what you are asking for, such 
as here docs (from Perl), CDATA sections (from XML), etc. An interesting 
idea, though it is usually cause for concern when we look to Perl 
or XML for syntax ideas - that's usually a bad road to take. Remember, 
when you get rid of escaping you limit the characters (or sequences) 
that you can include, though with here docs that limit can be minimal.

Robert, don't be fooled by R2's buggy console. R2 can escape { just 
fine - it's the console that will wrongly think you have an open 
string. Try that in a .r file.

or try:

>> b: load "{ ^^{ }"
== " { "

I totally understand what Robert means... escaping like Brian T. 
or Gabriele shows is crazy if you work with C/PHP/JS-ish sources 
inside REBOL

I thing theere should be whish in CureCode at least.

*wish*

First plugin example posted to Chat. You can get it going to:

1) chat
2) 5045
3) get *

For literal string delimiters, {~ followed by a space seems safe 
as I am unaware of where ~ is used followed by a space and at the 
other end I cannot think of where tilde is used followed by a closing 
curly brace.  Having Rebol always test for nested curl-braces in 
curl-brace values makes Rebol as difficult for my project as is Tcl 
- for the same reason.  Worka-arounds abound but the result has such 
poor usability and readability as to be unusable.

But I will resort to ICON or ObjectIcon or UNICON before I resort 
to PERL ;-)

If the {} are matched you need no escaping.

if they are not, you just need a ^

how is that crazy? I don't see any other way...

What are you guys proposing?

I think they want a multi-char delimiter so that the text inside 
needs much less escaping (or none?).

For example, I think RobertS might be happier if a new special type 
of string which is delimited by ~{ and }~ was added to Rebol.

In the content, single braces } or single tildes ~ would not need 
any escaping unless they happened to be together so that they look 
like the ending delimiter.
Or maybe no escaping is possible/necessary in such a string.

But now I'm also thinking of the start and end unique key strings 
used to delimit email attachments...

Gabriele, the problem is, that if you for example want to form JS 
code from REBOL, you will hardly have matched {} pairs. At least 
that's my experience.

What Robert wants (and I second that) is something like "heredoc" 
notation.
http://en.wikipedia.org/wiki/Heredoc

The wish is submited here http://curecode.org/rebol3/ticket.rsp?id=1194

A77 released - so, we got R3 extensions now :-) More here: http://www.rebol.net/wiki/R3_Releases

3 new blogs posted ...

Hmm, scripts would too easily get "messed up" (that is, very unreadable) 
with Heredoc or similar stuff. maybe we could use #[{   .....    
}]# for that... I'd still rather use external files for long strings, 
and use escaping for short strings (in other languages you have \" 
everywhere, so why bother with a couple ^{ ?)

Gabriele:
Heredoc was suggested *because* RobertS's script was messy.

Maybe *you* would rather use external files for the situation you 
imagine RobertS is in, but I think you're not really trying to put 
yourself in his shoes. Moving stuff out into external files can create 
its own problems. The advice to "just use an external file" suggests 
a deficiency in the language. (One day we may not be using files. 
I hope sooner rather than later.)

A server-side scripting language which cannot handle literal strings 
- and especially one that claims to be Unicode - has to be excluded 
from consideration for templating web content which is expressed 
in any other langauge which uses curly braces.  I told BrianH that 
the red flag here should be Tcl as Rebol shares this with Tcl.  Literal 
string are literal strings.  Period.  No if's and's or "that might 
be my curly brace in there" ...  Unless you dream of a Rebol-only 
world - and that fantasy should have passed some years back.    This 
falls under the heading of folly - a topic too often neglected.  
Folly in a meritocracy usually requires some individual to speak 
up.  But the folly of meritocracies is that  to be heard taht individual 
would already have to be playing within those constraints.  We see 
this in schools which graduate top people distinguished for inidividual 
effort who then do not fit well into teams.  They did group work 
in college by being the one who saved the group from failure by ... 
their individual effort.  For me this will be what makes or breaks 
my involvement with REBOL.  I could not wait for REBOL4 and hope 
for change then by getting into the merit circle.  My outside voice 
would have to be heard before it is too late. Tcl as the do-all is 
folly.  As nuch as I admire OOTcl, the XOTcl IDE and Expect.  I cannot 
use Tcl with "balanced brace" foolishness.  Of course if we all adopt 
XML and abandon scripting in non-XML languages ... So  We have comment 
{  }  and that was a mistake: it should have been symmetrical as 
in c{ comment here as literal with } or whatever }c   And that is 
water under the bridge.  We cannot be UNICODE and claim that  we 
must escape a certain pair  of characters if ithey are in a literal 
string.  That is silly. Ludicrous. Folly.  A literal string is a 
data value where you do not get to peek.  Imagine a proxy object 
that said: "I will be your proxy only if you promise that when the 
real object appears it does not contain [ folly happens here ] " 
  Many forms of "catch-22" in the world of beaurocratic regulation 
have a similar pattern.  I am no expert on unintended consequences, 
but requiring that some pair of characters be escaped in otherwise 
literal content has consequences for TEMPLATE value TEMPLATE  There 
should be a lesson there: some markup must be arbitrary and the choice 
will matter.  { and } are the wrong choice.  At least the terminal 
markup must be "sacrificed (it will always have to be escaped so 
pick carefully.   [{ is a bad combo for JSON so #[{ looks worrisome 
to me.  I propose lit |ls# and_content_then  #ls|    Someone shoots 
that down and we inch towards a suitable result.  Not perfect.  But 
usable.  { and } are not useable in the real world on the server-side 
if rebol is to play a role with other languages.  Play nice.  Please.

lit_str1: lit |ls#    the word lit  indicates that what follows is 
an unconditional literal string much as comment indicates ignore 
only this is a value ; when necessary use the UNICODe equiavaled: 
note that the markup is symmetrically reversed as we end here #ls|

RobertS: not much into that topic, but -  your note that #[{ is worrisome 
for JSON sounds strange. So we should use obscure syntax to support 
some JSON or what? Then comes someone next who uses something else, 
and we will give-up the option too?

excuse me, but what is wrong by escaping by ^{  and ^} ? In R2, left 
curly brace escaping does not work in console only, but script being 
run from file (which is case on the server anyway) is OK. In R3, 
which soon will be ready to replace R2 for such scenarios, it works 
even in console. But probably I am too dumb to understand the issue 
involved :-)


Could someone please give me a snipped of some quoted JS or other 
code, in order to get the issue? Would like to try the headache myself 
:-)

What is obscure about a syntax which permits literal strings to be 
literal strings?  Try assigning  set lit "{test} {" in your favorite 
Tcl interpreter.  I am not a JSON expert but [{ looks like JSON to 
me so #{[ "looks worrisome to me"   JSON or YAML or something other 
than XML is going to be important whether REBOL likes it or not. 
 Take RDF as one exmaple ( I prefer Topic Maps - please do not attack 
the example, but the isea ).  The fact that most people seem to think 
that RDF is XML does not make it so.  Tim Berners-Lee prefers some 
form of Triple notation for RDF.  Not XML.  As soon as a notation 
uses curly braces we have a problem using Curl on the server-side. 
 Please don't point to QM.  IT is not just tightly coupled to HTML 
it is married to it.  The web is not HTML it is HTTP with Content-Type: 
 set in the response header.  If that content type uses curly braces 
we have to start escaping characters in Rebol.  Awkward templating 
is dooked templating.  Let me repeat: doomed.  Folly.

Pekr: take any peice of template code that ends with curly braces 
unbalance, then insert a value through templating and then clsoe 
off the curly braces.

Now try assigning those opening and closing pieces to variables so 
as to generate code.  If you try to use Rebol then there is an immediate 
problem because a great deal of real world code uses quoted strings. 
 So now you need a literal string.  But in Rebol that will be in 
curly braces. Sunk.  Now you are escaping chartacters when you are 
tyring to generate code.  No problem if code genrated by Rebol is 
consuked by Rebol.  But that is not realistic.  So now you are generating 
code with Rebol but then preporcessing hte code with Perl to strip 
out the escaping carets on the ^{ and ^} ???

consumed by Rebol

For me - REBOL is important, no need to adhere to JSON on my part. 
What I was trying to say is, that if we step aside because of every 
possible pseudo popular system, then we might miss some characters 
to use for quoting anyway :-)

JavaScript and ActionScript enjoy "psuedo-popularity" ?!?  And white 
wine - say Chablis - with seafood ... pseudo popular as well?  Someone 
who thinks the latter drinks too much beer or too much whiskey or 
no wine or what?

R3 rejects   comment { this is my test { }

real world code

 ... then why using REBOL, if there is plenty of  real world much 
 better code much better languages around. I can accept anything, 
 maybe the fix is easy, and then we should just submit a ticket, or 
 - the worse case, it could affect REBOL internal parser, making it 
 more complicated, slower. Dunno ...

Ok fine.  But R3 also rejects  comment  {this is my silly test { 
}   and whatever could explain that could not justify that in the 
real world.  Back to Tcl we go.

surely it rejects it, as you did not escape the left curly brace, 
no? Well, I am really probably dumb, but how could you expect above 
code to work? You did NOT escape the code upon the REBOL's standard. 
Do you expect not escaping char used for string representation in 
other languages?

So if I understand you correctly. REBOL is escaping/allowing escaping 
curly braces correctly via ^{, but the trouble is, that the curly 
brace is very often used in other languages for code sections, so 
it makes generating/mixing the code difficult?

A scripting language on the server must tolerate literal strings. 
 Python at google is one example.  Rebol is not at google. Dave Hanson 
is.  But ICON is not. So it is not some conspiracy.  No one is out 
to subvert Rebol.  JSON was an example.  Examples abound.

how do you define literal string?

A nightmare if Rebol's output is to be another langauge's input.

our literal string is "content" {content}, and if you want to use 
quotes or curly braces, you have to escape them ...

So what you are asking for is to use some really weird combination 
of chars, which could not by accident happen inside your string (unless 
someone is crazy), and use them as a string delimiter?