World: r3wp

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?

A literal string has an indiated start and an indicated end and between 
you do not hiccup - how could we break comment on another forward 
curly brace?

literal string delimiters.  We are now UNICODE so we take our pick.

Are we breaking comment on another forward curly brace? Works in 
R2, no?

Can we not use a word such as lit ?  ( as I dare not suggest the 
word 'ls

busted in R276

hmm, you are right with comment. So we basically can't comment larger 
section of code, by enclosing it in {}

Escaping characters in comments is pure Tcl to my mind.  I love Tcl. 
 But it should be used as Expect for what it is good at.  Rebol is 
far more powerful and flexible and on one point exceedinly silly.

The Tcl community has had some very high-level discussions among 
serious Tcl experts on their comment and brace balancing  issues. 
 The result is that their problems are there to stay.

I see it as a failure to evolve.  They see the problem as an indication 
of their strength (their unique interpreter strategy )

What about using a word which requires three paramaters the first 
and third of which must be those delimiters ( smart might be to have 
3 sets of delimiters which need not even be paired - or to have what 
counts as a delimiter set for the user context with one pair of system 
defaults.

couldn't we somehow use some rebolish combinations to identify a 
lit string? e.g. your's suggested ~{, or gab's #[{     }]#  (more 
easily noticeable)

OOps, I left a right parenthesis stranded - luckily the text widget 
did not reject  my input ... ;-)

I thinkt he answer is to have Carl open a post on his R3 blog and 
get some comments - somefeedfack can get us to toptimal choices - 
maybe the anser is to have 3 pairs avaialbe - I don't know ( I'm 
just a Rebol user, not a Rebol guru )  Okay, Okay, I'm also a pain-in-the-neck 
 ( I really do have cervical osteop. in real life - not usually funny, 
but that's life ;-)

Who will ask Carl? Should I do it? I am rather good in bringing some 
topics on the table with Carl :-) OTOH BrianH might have even better 
channel to Carl ...

I am hoping this is on BrianH radar ...  I thought at one time you 
were kinda the guy who spoke for the community ?  Gab is aware of 
this and Oldes - doesn't he generate FLASH or PDF or something ? 
 At the moment my own option is to take shelter in PHP and PHPTemplate. 
 I wanted to fall back on Smalltalk but all the web frameworks from 
the MVC gurus seem to miss the point that the View was supposed to 
be de-coupled.  Go figure.

I don't remember anyone bringing this topic as important to solve 
...

Personally I could not just wait for R4 and hope to see it fixed 
there. Any langauge which cannot tolerate literal string I cannot 
use.  Any of the alternatives are nowhere as suitable as rebol to 
server-side scriping.  I love Rebol.  It's not personal.

R4? We are working on R3 for 3-4 years and still not finished. Before 
we get to R4, I will retire :-)

Found this nicely explaining string literal - http://en.wikipedia.org/wiki/String_literal

I think that in UNICODE raw string is now meaningless to end users; 
Americans ignore that European languages often have variant opening 
quote from closing quote ( as did British English in my youth, as 
I recall )  this is a new phenomenon in America: educated Americans 
spoke French, read French and if they were mean, had often spent 
time at a German university,  The North American shool system was 
of Prussian insoiration, as I recall.  But atleast Carl is learning 
French ... but does he use << and >>  ... that I woulldn\'tt know 
\"  ;-)   So that leave literal strings  such as @"  "@  I still 
use a language with a character count delimiter pair

prev {"mean"  read 'men' }

a mirror-terminator of "@ is my idea of a bad idea

some string literals should be un-preprocessed and un-processed verbatim 
content.  "Verbatim string" might be less confusing than "literal 
string" which sould like "string literal".  "pristine string" has 
a nice ring.   vs{  virgin string  }sv

C# verbatim strings require that double quotes be escaped.  Good 
for them.  Keeps 'em busy.

http://www.rebol.com/article/0420.html


August plan. No GUI, which is to be expected. Too much work left 
before that happens.

August is short, we are almost at the middle of August. I expect 
some bugfixes, BrianH syncing his module related work, maybe new 
additions/fixes to extensions, I think GUI can wait a bit :-)

We should not probably also forget about parse - before we get to 
protocols, etc., it would be probably good to have some parse enhancements 
implemented ... or so I think :-)

RobertS, you said that similarity with TCL is a red flag, but that 
is not the case. TCL, like Ruby, is known to be bad because of its 
internals and semantics, not its syntax. XML and Perl are the ones 
with bad syntax.

What is obscure about a syntax which permits literal strings to be 
literal strings?
 - Most languages don't support it.

So now you are generating code with Rebol but then preporcessing 
hte code with Perl to strip out the escaping carets on the ^{ and 
^}

Completely unnecessary. REBOL escaping is only a REBOL syntax trick 
- in memory the escaping carets don't exist. If you don't want carets 
in your output use PRINT, FORM, WRITE, or anything but MOLD. There 
is no interoperability argument for heredocs whatsoever.

REBOL can generate JSON just fine, and there are no carets in the 
generated output.

I am not saying that heredocs are a bad idea (and have given some 
advice on them in the CureCode ticket). However, they are not *needed* 
for any of the reasons that you have stated. The only reason we would 
want them is for minor ease-of-use improvements, and because several 
other languages in roughly the same category as REBOL has something 
similar.

RobertS, this means that you can do server-side processing of JavaScript 
using R3 right now, without heredocs. All you need to do is escape 
unbalanced { and } in your REBOL syntax { } delimited strings. The 
escaping is resolved at LOAD time, so the resulting strings don't 
have escape sequences in them. Then you can combine and generate 
the resulting string data without concerning yourself with escaping.

A server-side scripting language which cannot handle literal strings...
 (the long message)

I had a little difficulty finding any criticisms of REBOL or its 
string literals in this message that actually apply to REBOL 3 even 
now.


- { } balancing exists make generation of brace languages like JS 
and CSS easier. You only have to escape { and } if they are unbalanced 
in the syntax; most of the time they aren't. R3 already fixed the 
^{ console bug, so that isn't a problem. And the escaping only applies 
to REBOL syntax, and is resolved by LOAD - there is no escaping in 
the data once loaded.

- COMMENT is a function, not syntax, and that function doesn't even 
need to be there most of the time. REBOL doesn't have block comments 
at all. And doesn't need them for the most part - COMMENT works when 
they are needed.
- The meritocracy argument doesn't apply here (or make sense).

- Unicode is supported just fine (at least within the BMP). String 
escaping doesn't affect Unicode support.

- String escaping doesn't affect string data - it's just a syntax 
thing.

- JSON is supported just fine in R3, better than in R2 since the 
R3 data model is a better match. String escaping doesn't affect JSON.


The one part that made sense is that #[{ }]# would be bad for specifying 
JSON data - true that. Something starting with # for the start delimiter 
would be good, but not starting with #",  #{ or #[  since those would 
conflict.


I suggested in the CureCode ticket that the last character of the 
start delimiter and the first character of the end delimiter be newline 
- this would make the heredocs really distinct. There would not be 
a need for single-line heredocs because there could only be a small 
number of characters in them, small enough to escape. Just a suggestion 
though.

I'm seeing a bad conversion for alpha-77 under Windows Vista 32-bit:

    system/version
    == 2.100.77.3.1
    9200000000000000000
    == 9200000000000000000   ;; good
    9300000000000000000
    == 9223372036854775807   ;; bad  
    9999999999999999999
    == 9223372036854775807   ;; stays bad up to here 

Brian is not seeing this problem under a different Windows.

Could you try it on your rig and see what happens?
Thanks. That'll help narrow down the problem area.

I've got invalid integer error (XP on Parallels).