World: r3wp

Also I can clearly understand, why Janko needs the delimiter in his 
dialect. It simplifies a lot when you can delimit values, where some 
of the values can be functions requiring arguments. Without the delimiter 
you must add pretty large complexity which will provide info, how 
many args require each funcion.

I don't like #'." as a delimiter imho. I would use #"|" instead when 
#"," is not available.

String parsing under REBOL is the reason, many people ask, why regexp 
is not available. It just shows that parsing is by default quite 
hard to do, especially, when the underlying mechanism for parsing 
never has been described properly. Gabriele's issue is that he is 
just too good at it, so he doesn't see a problem with it.

the underlying mechanism for parsing never has been described properly
 - this is false

Janko needs the delimiter in his dialect

 - in fact, he requested the #"," to not behave as a delimiter, which 
 defies his goal in a way

Geomol, so your point is, that since string parsing uses bitset!, 
which is not used in block parsing, then it is much more difficult 
to do string parsing?

Henrik, my problem is that is see block and string parsing as equally 
difficult, especially for newbies that have probably never heard 
of the concept, and that have no experience in designing languages, 
BNF rules and grammar parsers. if you can get block parsing to work, 
then you figured out the hard part already, and can get string parsing 
to work with only minor extra effort.

String parsing may be hard, but so is block parsing.

BNF rules

 - I do not think it is necessary to know anything about them, since 
 REBOL PARSE is, in fact, an analytic grammar, unlike BNF

Gabriele, that's one point, not the only point.

this is false

 - please point to the exact documentation that describes in depth 
 what parse does.

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

The problem is that it only describes what each command does in PARSE. 
What I really would like, is a source description of PARSE to learn 
how the "machine" works. That makes it much easier for me to have 
a model of PARSE in my head, rather than having to learn PARSE by 
rote.

What I really would like, is a source description of PARSE
- that is not what "complete description" means.

If you know the source, you kinda know all there is to it, right? 
So that's pretty complete, I would say.

when you have the source, you can generate the complete description

For example, having a source code, you cannot discern whether something 
is a bug.

If you know the source, you kinda know all there is to it, right? 
So that's pretty complete, I would say.
 - how does it prove, that any other description is not "proper"?

what the manual above describes is like learning to drive, by memorizing 
that when turning the wheel to the left, the car turns left, turn 
the wheel right, the car turns right, and have a big table in a book, 
that you must either memorize or consult, in case you are at an intersection 
and must turn in some direction. it usually makes intuitive sense, 
how to drive a car, so you don't need a huge description of every 
possible operation of the car. same with PARSE.

Are you suggesting that a source code would not contain all the variants 
of "turning left/right" described in the source code, or how shall 
I understand the above note?

I pointed to the exact documentation that describes in depth what 
PARSE does, and am quite curious how do you want to suggest otherwise.

no, the opposite: the source code would provide the operation of 
parse in a way that makes sense to have as a model in your head. 
it would be the same as learning how the steering wheel of your car 
is connected to the wheels. if you know that, the rest comes on its 
own and you don't need to learn by rote.

how does it prove, that any other description is not 
proper"?"

It doesn't, and I didn't try to do that. Other descriptions can be 
useful, but I don't think, that kind of description is what, Henrik 
is after.

The http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse
article contains quite a lot of in-depth informations, which surely 
cannot be found in the PARSE source code (this note is not meant 
for Henrik, but for other people interested in having a proper description 
of PARSE)

Reposting to make it readable:

The


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


article contains quite a lot of in-depth informations, which surely 
cannot be found in the PARSE source code (this note is not meant 
for Henrik, but for other people interested in having a proper description 
of PARSE)

Not to be mistaken; the manual is very comprehensive and contains 
a lot of information. I just miss a basic description of the source 
code. It doesn't have to be the source itself, just a pseudocode 
description of it.

Geomol: "that kind of description is what, Henrik is after"


- I can understand that Henrik wants the PARSE source code (it would 
not help him, but I do not intend to prove that).

- My point just is, that for me, the above article can be called 
"a proper and complete PARSE description"

BTW, Henrik, did you really read it?

There indeed are many things you cannot find in PARSE source code, 
that describe PARSE quite well.

I think actually it would help me a lot. The problem I guess, is 
that I'm terrible at learning by rote, which is what the above manual 
is about. That is why I try as often as possible to create "internals" 
documentation of whatever I make, to help the user understand the 
inner workings of a system.

So, you did not read it, yet you are saying it is "by rote"?

Ladislav, that is actually not what I'm looking for. Like learning 
the connection of a steering wheel to the wheels will not teach me 
anything about the dynamics of driving the actual car. That is something 
I will learn, intuitively, when I drive it.

I did read it, because, if you recall: I wrote half of it. The rest 
was replaced, as it turned out to be wrong and I had misunderstood 
large parts of it.

So, you are saying, that, for you to be able to drive a car you need 
to know how the steering wheel is connected to the wheels, and that 
you lose the ability to steer a car once the steering wheel is connected 
"by wire"?

Henrik, I think here's your "internals" documentation:


http://en.wikipedia.org/wiki/Parsing_expression_grammar#Definition


(Esp. skip ahead to the "Operational interpretation of parsing expressions" 
section.) It's linked to from the "Parse" documentation Ladislav 
gave above.

No, I don't lose the ability. I just get a much better impression 
of it. It doesn't matter how it's connected, but if you know how, 
it's much easier to figure out the rest.

The above "by wire" example is a typical case when you do not know 
how the wheels are connected (will be connected in your future car). 
Do you know it for your future car?

Of course not, and it does not make sense to even try to know.

I'm not sure what relevance that has.

If you are an airline pilot, you are probably fairly interested in 
learning how your plane works.

Car driving is what you choose as a relevant example, so why you 
are asking me?

If the airplane maker says "I can't tell you that, it's secret" you 
have no way of learning how to solve a problem that is caused by 
the design of the airplane.

THat is improper, the honest way would be to admit, that pilots trained 
on older airplanes *are* qualified to drive "by wire" airplanes.

Yet, most accidents occur, because of insufficient knowledge on the 
internals of the airplane. It doesn't matter what the design is.

Anyway, this leads nowhere. Back to work.

what is missing is a 100 page book on the subject.  not a reference, 
but a guide to parsing.  In fact what I often feel is missing is 
a reference that outlines not how PARSE commands work, but the different 
typical parsing constructs themselves.


its like explaining algebra as opposed to maths.  they are both fundamentally 
similar, only that algebra has a lot of non-obvious tricks like substitution 
and reduction which can be done.   these things have to be shown 
(usually) to even be noticed, let alone understood.


in a sense, when people start out with parse, they understand the 
concept of matchin a pattern, they just don't undertand how to break 
up and analyse a PARSE pattern, there doesn't seem to be much docs 
in the way of identifiying common PARSE structures, for real world 
patterns.


where are the pattern types listed?... we don't really know them, 
in relation to PARSE, there are no types of pattern we can say apply 
this technique to that pattern.


that is what makes learning PARSE complicated, the *structure* of 
the parse rule is the hidden knowledge which newbies don't "see". 

we can't just say: here is the "recipe" to solve a "quadratic formula"... 
 


There could be a site which has hundreds/thousands of PARSE examples, 
documents, and active forums, just like there are for regexp, this 
is how rich PARSE is... but alas there is not.

I think the same about every different aspect of REBOL for newbies. 
this is what misses from the actual doc. 


When we limit ourselves to use REBOL as another procedural orand 
 functional language, it's relatively easy to master but when we 
have to delve more deeply into other aspects which would require 
more tools - or a more precedently acquired deepness about languages 
internals (kike globals storage allocastion and representation vs 
local ones in contexts and functions for example or even the bind 
mechanism - then there is some missing parts.


And I agree, this is the same for Parse and the way constructs have 
to be thought to eventually become a master  at creating new patterns 
easily - not mimicing others without learning (this is the first 
step nevertheless - whatever we are using which is new and we never 
met before ) ... 


Carl already resolved some part of this challenge with his Cookbook 
and How-to guides but more material needs to be covered and parse 
fits this need ... 


Not to formal and not too informal is the rule and the way to go 
from my POV.  : )

I think this is why one of his last Blog's post asked for some PARSE 
idioms - but not a lot were submitted - this could be a real starter 
to help him put new docs online - when he will find some time after 
R3 is beta released ...


But the best time to have new ideas is when we modify something and 
since PARSE has been modified, then may be some nimimal doc in between 
could be released to start many of us in the right direction ...

May be just extracting some parse rules from older work already running 
well would help us - at least pointing the material to us with some 
nice comments about what has been done (but often the problem domain 
and all is needed to solve it causes some noise preventing learnerd 
to distinguish the trees from the forest ... 

This is how most of us learned as far as now, isn't it ? ;-)

yeah, I think for now, just having a dedicated rebol-parsing site 
which tries to market itself independently of REBOL would be nice. 
  by independently, I mean that its content is valuable enough that 
it attracts new users to REBOL.


REBOL parsing is still one of still most powerfull feature and a 
lot of techies out there would use it if they new it existed.

... still one of *its* most powerfull ...