World: r4wp

I would probably think to implement as a high level dialect in Red 
that compiles down.

Isn't that the other way around? I want to go from Red/System source 
to Verilog and other similar languages for different hardware. I 
don't want to start with a Verilog program and end up with what Red/System 
produces.

Doc wants to program FPGA CPUs dynamically one day, so there is a 
sensible route in there somewhere

What I mean is, I want to write the Verilog/VHDL dialect in Red, 
and have it compile down.

Gregg, you have a fine taste of useful tech ;-)

I guess this is a huge task. If you look at the Xilinx ISE Pack and 
the prices they are asking...

There is a free Web version but this one only supports the very small 
units with max. 24k LC, not enough todo usefull things.

But of course a Verilog/VHDL dialect would be more than cool. Meanwhile 
OpenCL/CUDA would be nice as well.

@Doc: found problem about console windows. I use the function _system() 
twice so I have two windows so it is my fault, sorry.

Doc, is your plan for Red PARSE to use R2 dialect, or R3's?

I am for R3 including enhancements, but Doc does not plan to support 
features like to [a | b | c]. Whereas I am almost refusing to use 
parser without it, Doc seem to be against stuff, which would eventually 
slow down the parser. And as the parser will be most probably implemented 
by Gabriele, we might get some compile rules or something like that. 
I am for R3 compatibility though ...

I agree that TO [a | b] is very important in a parser. I was surprised 
when I found that R2 doesn't do it

Isn't it just a nice thing to have? You write less, yes, but you 
could just parse for
	[to a | to b]


Some might even argue, that if you have a lot of alternate rules, 
it is more readable to have the keyword, TO, together with the alternates.

Geomol,
    [to a | to b]
is not equivalent (not even nearly) to
    to [a | b]

ok Then it's a good argument.

However, it is questionable whether a user unable to replace
    to [a | b]
by an idiom like recursive
    rule: [a | b | skip rule]
can be actually able to use Parse...

I feel, you need to explain this. If I replace a with "abc" and b 
with "str", and I want to parse ["abc"] :

(From R3 prompt:)

>> parse ["abc"] [to ["abc" | "str"]]
== false

>> rule: ["abc" | "str" | skip rule]
== ["abc" | "str" | skip rule]

>> parse ["abc"] rule
== true

Or did you mean

rule: [to a | to b | skip rule]

?

Ladislav - I am able to user parse, used it even for some more complicated 
stuff, including recursive rules. But - it was mostly trial and error 
on my side. OTOH - parse should not be reserved just for gurus imo.

Geomol - try to understand your example. Imagine html file for e.g. 
Your [to a | to b ...] is wrong ... imagine 'a is at the end of the 
file. Simply "to a" will find it, before "to b" is even given chance 
to be applied. What we want is - find what is first - 'a or 'b ....

Geomol, I certainly did not mean the idiom you suggested. I just 
used an idiom for THRU, which can be adapted as follows::

    a: [here: "abc" :here]
    b: [here: "str" :here]
    rule: [a | b | skip rule]

Pekr, ah :) Early in the morning here, so I need to get in gear. 
Good point!

Idiom I long time wanted - to [a | b] might be more expensive imo, 
as it will do incremental searches, evaluate the lower index and 
apply the rule. Whereas recursive [a | b | skip rule] will skip one 
positition at a time, trying to match rules .... or that is how I 
imagine the difference :-)

But - it was mostly trial and error on my side.

 - yes, Pekr, agreed with that. Once it is just "trial and error", 
 that is what I call a question whether you actually are able to use 
 Parse.

What I don't agree with Doc and Gab is - if you are a guru, just 
don't use idioms! But plese - don't take them from those, who might 
find them usefull! I remember, during the parse history, that exactly 
such idiom was often requested and ppl were not able to use parse 
without it, because they were not able to understand the rule Ladislav 
provided. And - will we suggest them not to use parse? That's imo 
not rebolish ....

I try to think about, how I solved such situations in R2, or maybe 
I never had to. Hmm

if you are a guru, just don't use idioms
 - did they really say something like that?

(does not sound reasonable)

Ladislav - I don't care if I am able to use some guru system - it 
either works for me as a user, or it doesn't. Reserving something 
for gurus should not be the point. Not in Rebol imo ....

Objection of Doc was something like that it will slow parser, allow 
inappropriate use of parser, and hence could shed bad light on its 
performance, because instead of learning how to properly use it, 
ppl will use those idioms ...

I do not "reserve" anything for anybody. I just know that "using 
trial and error" is (unfortunately) not the way how to get things 
done.

But - I have a suspicion, that Doc is not aware of most R3 enhancements. 
Proof is, few months back BrianH just pointed him to the R3 wiki 
enhancement parse doc. So I expect him to study it. Not all enhancements 
are imo bad ...

Ladislav, so simple question - so would you discard to [a | b]  from 
the R3? Do you find it as a performance penalty, or teaching ppl 
wrong habits, preventing them to actually understand, what is parse 
about, or something like that?

I think, I mostly used string parsing in R2, and got around such 
problems that way.

would you discard to [a | b]  from the R3?
 - no, I actually support it being there

But I see the benefit of TO [a | b].

Well, we will see, what is Red's parse going to be about. I expect 
Gab to implement his compile rules, or something like that. Actually 
I never investigated his system, so we might get a bit different 
stuff, who knows ...

Do you find it as a performance penalty, or teaching ppl wrong habits, 
preventing them to actually understand, what is parse about, or something 
like that?

 - The answer is "no" to all the above questions. It is neither a 
 performance penalty, nor teaching people wrong habits or prevent 
 them to actually understand...

I only have R2 parsing in World today, as my initial goal was just 
to get to a point, where my R2 programs could run. It would for sure 
be an idea to look at the extensions at some point. And then desicions 
has to be made, if it should all be with extensions, if there should 
be more than one way of parsing, if it should still be mezzanine 
or made in C, or maybe some JIT compilation. Many options. :)

If it's not a performance penalty (and it certainly might not, I 
haven't looked closely at it), then I see no reason not to have such 
good ideas as is found in R3 parsing.

And then there is always the problem of getting it documented, because 
people talk different 'languages'. Maybe it's an idea to break documentation 
up in 'the basics', 'advanced' and 'expert' stuff.

I remember now, how I solved my TO [a | b] situations in R2. It's 
what I call 'positive' parsing, where I all the time look for a positive 
all the way to either a or b is reached. It's easier to just let 
it skip to either a or b, whatever comes first, yes, but I was able 
to parse about everything the other way.


I need to look through all the R3 extensions to parse some day, when 
parse needs an overhaul in World. I guess, having parse as a mezzanine 
is a good thing to port it to also Red or other languages?

Geomol - there's nic doc here - http://www.rebol.net/wiki/Parse_Project

cool, thanks! I also know of this:

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse/Parse_expressions

I lost track of, what REBOL docs are good and up-to-date.

I imagine Doc will profile things if performance becomes his argument. 
I support what makes it easier to use PARSE to get the job done, 
though sometimes there may be confusion between those who understand 
parsing at a deep level and those who don't. I would rather have 
support for TO [a | b], and other rules, even at the cost of them 
having lower performance, versus people not being able to do the 
job at all. In docs, we can note the tradeoffs, and people can optimize 
if necessary.

Agreed

Doc, is your plan for Red PARSE to use R2 dialect, or R3's?


R2 dialect plus a few of R3 additions that have no R2 equivalent 
or very complex R2 equivalent. Please don't ask me to make lists 
now, as it is not the current focus. When time comes to implement 
PARSE, we'll discuss every feature in detail if needed.

Is Gabriele still going to do the parse implementation?  Or was that 
just a rumour?

It was supposed to be a private info, but somehow private chats are 
leaking massively here these days. :-)

Blame Pekr!

Gabriele was mentioned here in the past, I believe :-)

Yep

For your information, http://en.wikipedia.org/wiki/Parsing_Expression_Grammar
gives some PEG related info that could be used to explain how REBOL 
uses PARSE to do almost ALL the same work ... and presents some fundamental 
differences with CFG and RegEx parsing. As you'll see for some simple 
(and not so simple) grammars REBOL Parse function works on par with 
the PEG theory.