World: r4wp

Pekr: "That is understandable, but it almost feels like a push - 
either do it R3 way, or it is your bug :-)"


Not always. R3 isn't done yet either. Remember, we're still catching 
up with a 2-year backlog of pending design changes. Some of its design 
experiments have turned out to be bad ideas for reasons that weren't 
known at first, or in some cases discovered by Red. So sometimes 
R3 is the one that needs fixing, and much sooner because R3 is going 
to get to 3.0 long before Red's design is set.


There are real advantages for Red and R3 to declare that incompatibility 
in comparable situations should be considered a bug, especially then 
it comes to syntax, and sometimes when it comes to semantics (ie 
indexing). But I don't assume that either R3 or Red in in the right. 
More often these incompatibilities are a sign of things that haven't 
been fully thought through, and once they are it could be R3 or Red 
that needs fixing, or in some cases both.


But, in the scale of history, Red is much earlier on in its design 
process than R3 is. R3 is more towards the end, closer to release. 
So that means that any changes that might break the *core* semantics 
or syntax of user code need to be made very soon, before 3.0 comes 
out and sets the standard. Red can afford to make those changes later 
because it isn't anywhere near the point of standardization. So if 
there are design flaws in R3 that might be comparable to something 
that would affect Red, they need to be fixed earlier in R3 (not by 
the Red people unless they're into that). And it would be useful 
for Red if people would participate in the R3 design discussions 
for stuff that would affect Red too because Red would benefit from 
the discussions regardless of compatibility, and also benefit from 
being compatible with the results.

and btw - R2 and R3 are incompatible already, so why to bother so 
much?
 - see my post in !REBOL2.

Pekr: we don't have much regression tests for the interpreter yet, 
so regressions might have happened during the last set of interpreter 
changes. Also, some edge cases have not been tested yet, we'll probably 
find more of this kind of bugs soon.

I wish I could switch to a more TDD approach asap.

I've been trying TDD out for R3 and it works pretty well. I usually 
have to expand or change the tests afterwards based on stuff learned 
while fixing the problem, but as long as you're OK with that it works 
great.

If you are a TDD purist and insist the the tests not be changed after 
you do the fixes, then the process fails horribly.

I am sure everybody here is really looking forward to that next blogentry!! 
:)

The tests reflect the specification, if the specification changes, 
the tests must follow.

Ah, so you are doing spec-driven development. For TDD the tests are 
the spec.

I'm not a TDD purist. ;-)

Neither am I :)  I tend to put stuff in CureCode first, resolve the 
design issues there (especially if they need community feedback), 
then add or fix tests in rebol-tests, then do the fix. If I learn 
more while doing the fix, sometimes the tests need more work, and 
sometimes the ticket needs changing. Or rejecting, because sometimes 
while doing the fix we find out why it's a bad idea.

BrianH:I don't believe a single second for R3 becoming even beta. 
Three or so years ago I wrote, what makes a good beta for me. So 
here it comes - give me a console, not a crap. Give me smtp, ftp 
etc schemes, without an excuse. Give us odbc, mysql, postgress, give 
us CALL. So - no matter how much advanced R3 is to R2, in a sence 
of a complete package, it is still pre-alpha ...

R3 is not TDD, it is a long time - TBD :-)

Wrong group, switching to !REBOL3.

Nenad, what kind of timeframe do you see for implementing parse? 
I didn't see anyhting on the roadmap.

State of Red's PARSE: 


It's not on the roadmap because it's too low-level for the bird view 
(maybe I need to add it anyway?). Moreover, PARSE is not (for now) 
useful for the internal construction of Red/System and Red, so from 
that perspective, it's quite low-priority.


OTOH, it is quite simple to implement in Red/System, and users could 
see that as a sign of good progress, so I probably need to schedule 
it for a weekend to implement a R2-level PARSE (with a couple of 
features from R3's PARSE) and a few more days to test and debug it.


Also, Gabriele is interested in implementing a "compiled" PARSE version 
for Red, but unfortunately, Red has not yet all the features that 
Gab needs for it (mainly object! support). So, he's waiting on me 
to get Red ready first.


As currently, object! support is much more important to implement 
(for completing the context/binding model of Red and enabling ports) 
than PARSE, you might get Gab's version first. Also if it's fast 
enough, I wouldn't need to make a Red/System version then.


Last but not least, I don't agree with 100% of the changes/addition 
in PARSE for R3, so I would need to review R3 parse and make a "cleaned-up" 
version for Red. Also, Topaz has some interesting improvements on 
PARSE what I might want to include in Red's version too, so that 
needs a bit of preliminary review work.


So, as you can see, it's hard to give you a precise timeframe, I 
guess we would have a first version of it during Q2 2013.

If your review of R3's PARSE generates some criticisms, be sure to 
let us know. I am already looking at Topaz for ideas, your ideas 
would likely be useful too.

Some of the design choices for R3's PARSE were the result of inevitable 
side effects of its implementation model. Some of those choices would 
have been different with a different implementation model, particluarly 
with a compiled dialect. If you had a compiled dialect with rule 
functions, for instance, most of the operations would be converted 
to those functions and the dialect would be very lean indeed.

For instance, there is at least one bug report for R3 related to 
increasing the number of delimiters that should be rejected because 
implementing it would drastically reduce the readability of code 
written in any Rebol family language. If Red implemented that proposal 
it would be a bad thing for Red as well for the same reasons.

 -- my proposal is to write a special AI filter that checks for each 
 word user writes and resists to evaluate it if it reduces the readibility 
 of code. IMHO we surely can't say that ony specific delimiter reduces 
 readibilty and anything else a stupid programmer might cobble together 
 with the ones left doesn't  <-ironic .. I hoped the comma wars won't 
 have to continue in Red also :(

Some of the new operations were added to reduce bugs by having clean 
implementations of things that PARSE users frequently need to do 
but usually get wrong, such as CHANGE, INSERT, REMOVE, IF, THEN, 
AND, NOT, QUOTE and DO. The modification ops are the ones that lead 
to the most frequent R2 parse errors.

(I say this because your proposal is that red and r3 should have 
the same syntax rules for the same datatypes, like words)

Well, word syntax in R3 needs some work. There are tickets about 
some of the problems already.

I am not 100% if I understood your text correctly. Did you say that 
the bug report was about "increasing the number of delimiters which 
should be rejected" or that the bug that was "about increasing the 
number of delimiters" (well I don't know what this means, the only 
delimiter now is space and even nospace at brackets etc) and the 
bug report should be rejected?

The latter, the ticket needs to be rejected, I was wrong. There is 
another ticket about adding support for Unicode whitespace as delimiters, 
and we should probably try to figure out how to implement that one 
(though the zero-width spaces are a bit iffy).

aha, I misunderstood it then.. yes these unicode whitespaces are 
problematic.. I often have problems with them when trying processing 
data in bash from various documents

We can switch to !REBOL3 is you want to continue this discussion 
:)

I am just going to sleep, no problem

BrianH: compiled dialect is what Gabriele wants to implement. It 
should indeed be efficient in Red. About the review, I think we should 
get it organized somehow, I know that Gabriele has also some words 
to say about it too. But this can wait for a few more weeks.

It's a subject I've given a bit of thought to, especially when we 
were working on R3's PARSE dialect. The problem is that without the 
dynamism PARSE is only as powerful as a regular PEG parser, since 
regular PEG parsers are compiled. With the dynamism PARSE can be 
strictly more powerful than PEG. If your compiled dialect doesn't 
replicate the dynamic rule abilities it will be less powerful (though 
faster, so that's a tradeoff). Actually, that rule function trick 
doesn't need to be compiled, it can work with an Rebol-style interpreted 
dialect - I was thinking of doing it for R3 as an experiment.

implementations of things that PARSE users frequently need to do 
but usually get wrong, such as CHANGE, INSERT, REMOVE, IF, THEN, 
AND, NOT, QUOTE and DO

 this is where I *must* disagree. THEN seems to be infrequent, CHANGE, 
 INSERT and REMOVE are not frequent either according to my experiences 
 (nor they should be frequent), DO is a typical "one user feature".

Well, the modifiers are infrequent in your experience because (based 
on our arguments) you avoid modification of the source in parse rules 
on principle, and don't like it much outside of parse rules. So it's 
not surprising that *you* don't do it much. For that matter, *you* 
would be a poor judge of what people normally do badly in PARSE or 
DO dialect code because you just aren't that used to doing things 
wrong :)

I agree about THEN though (that was a Carl thing), and to some extent 
DO. For DO in particular I have seen people request help doing stuff 
like that frequently enough, but they either give up or are capable 
enough to not get it wrong.

DO is basically the semantic block-parse equivalent to Fork's request 
to incorporate TRANSCODE into PARSE. People would use it for mixed 
DO-other dialect code, but there is probably a better way to do it.

What can we do, Gabriele wanted it and it seemed like a good idea 
at the time. He convinced me.

What I see as a bad idea about DO is that it looks too specific to 
be of general use

It seems useful for dialects, and dialects are one of the main purposes 
of block parsing, and supposedly of Rebol. Beyond that it doesn't 
seem to be useful. It doesn't hurt to have it in there. Security 
was one of my initial concerns when Gabriele first proposed it, but 
R3's greater control of binding can be enough to deal with that issue 
so it's about as harmless as any method of implementing a dialect 
that allows code execution.

It also isn't difficult to do (Do_Next is a core function) and isn't 
likely to cause a conflict as a keyword because why uses 'do as a 
rule name or temporary variable? END is a worse keyword than DO.

why -> who

I hope you guys are considering the longer (hopefully not so long) 
term series streaming (from ports?) wrt to what you consider worthwhile 
functions in parse. I would think that some the in-place changing 
functionality is desirable for that kind of situation. I guess, copying 
might not even be an option if there is not significant buffering 
available. Am I totally off with this kind of thinking?

That is something I have given some thought to. I don't know about 
Red's port model, but for R3's port model we should be able to use 
seeking to implement backtracking and position setting. This should 
be reasonably quich in buffered port models.

Copying would be easier than modification, especially since modification 
wouldn't even apply for many port schemes, while copying just results 
in a value in memory.

You're right - I don't know what I was thinking. What I had in mind 
was one or more back-to-back parsing/transformation stages and it's, 
clear now that you pointed it out that each stage would just parse 
(if needed) data as it is copying from the port or a previous stage, 
to fill its respective buffer.

Kaj, yes, I would say regarding the SDL wav XP bug that it is appearing 
as a timing bug.  Hope to look at it more this weekend.

Great!

Doc, how about merging dyn-lib-emitter into the upcoming release? 
I think it would make use and development a lot easier

I've tested that the remaining issues we had with the R3 bridge are 
due to bugs in R3, not dyn-lib-emitter

Would it be possible to implement { } multi-line strings in LOAD 
before the release?

Another crash:

red>> function [] [()]
Segmentation fault

LOAD doesn't parse file! type: