World: r3wp

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).

Rebolek, the invalid integer error is the correct behavior. Anyone 
running Wine, so we can test there?

Windows Vista Ultimate, 32bit edition - the same results as Sunanda 
...

Anyone running 7 32bit? I only have 7 64bit and XP 32bit here.

Sadly no Win7 here, testing system is deleted ....

BrianH: are you going to incorporate your module changes now? :-) 
Or waiting for some answers, regarding extensions first?

I am going to wait for answers to the questions in R3 chat #5126 
to finalize my changes. I've already worked out the integration, 
but a few policy/informational matters need to be addressed.

Just tested Sunanda's number on Win7 64bit - same error as Vista. 
Reasonable to assume that Vista 64bit is the same.

Some of my module changes involve shuffling code from one function 
to another. It's possible that Carl's added code in IMPORT should 
be moved to LOAD, for stability and flexibility. I also integrated 
extensions into the module checking and override model, but need 
to know whether there will be problems with doing LOAD-EXTENSION 
more than once with the same extension (necessary to see if it is 
already loaded).

BrianH: what are options to get e.g. SQLite driver running? If I 
understand it correctly, you can 1) include C source code of SQLite 
into your extension 2) wrap SQLite DLL from your extension ...

You can also statically link SQLite into your extension DLL, and 
just export your extension wrapper code, or the whole of SQLite if 
you want to do the trick like tclsqlite or System.Data.SQLite. The 
real trick is making a proper database access model that fits into 
R3. This might be tricky with extensions v1 because we don't have 
device support yet.

With extensions v1 it's much easier to make a compiler than it is 
to provide SSL or database access.

Really? Why?

If you look into R2 SQLite driver, then it is scheme around few calls 
to wrapped DLL functions. I am not looking for something more. Lack 
of DB drivers is what imo holds guys back from turning into R3. There 
is less and less reasons, to use R2.

I thought I'd need user-defined function types to make a JIT compiler, 
and those are much further down the road than devices. It turns out 
tthat the command! type is sufficient, today. I could start adapting 
a JIT next week.