World: r3wp

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.

So I just thought, that as an excercise, someone could "port" the 
SQLite driver, even if architecture might not be ideal. Why Device 
should be needed here? I know it would be better to be async non 
blocking, but we did not have it with R2 either, no?

what? Really? What kind of JIT would it be? What exactly would be 
"jitted"? I don't expect normal REBOL code here, but some kind of 
limited dialect?

In R3, async non-blocking is essential - in R2 it was optional.

So you think that next logical step for RXI is to support device 
model?

Yes.

What needs to be done here? Carl making some low-leve exposure of 
Device commands to RXI interface?

OK, then push Carl to go that way :-)

The problem is, that both Device and RXI models are not much practically 
tested, no? Or does R3 uses Devices internally already for IO?

I'm not sure how devices will be integrated, but know they must be, 
and soon. R3 uses devices internally and  they work great. The trick 
is integrating devices with plugins.

there is no spoon
 ... :-) there are no plugins, just extensions, RXI for short :-)

Google tries to propose unified way for browser extensions. I wonder 
if R3 could become such an extension, if we would benefit from such 
situation? Probably different model than having browser plug-in ...

I've traced through the RX code (there isn't much of it - extensions 
are *simple*). It's a great model. I have a few low-level questions 
and one or two requests, but the overall model is pretty solid. There 
are GC considerations that still need addressing though.

Google browser extensions are written in Javascript - if you want 
to use REBOL, you'd either need to compile to Javascript or be a 
plugin (which is supported by Chrome). The closest thing in R3 to 
Google's browser extensions is the module!.

Have you looked to the LUA model? I posted you a link privately - 
seems similar ...

What? I read some topic called - Google native extensions ...

As for the JIT, I could write the compiler in REBOL and generate 
the intermediate code of the JIT, then pass that intermediate code 
to the JIT with a command. The JIT would then generate a function, 
add it to its list, and return the list index as an integer. That 
integer can be  used to create a new command!, which RX_Call can 
dispatch to the internal JITed function.

Since extensions can't be statically linked with R3, I can wrap a 
LGPL JIT like libjit. It should work great. I'll be stuck with the 
RX data model, but that cold be plenty for the types of functions 
you wold write just for speed.

So we've got Rebcode replacement? :-)

What, did you think Carl was going to be the one to replace rebcode? 
:)