Comments on: Needed: A PARSE Common Patterns Page
Do we have a library of common patterns for parse? If not, I think it would be a useful page to publish.
For example, in R3 here's a parse line that removes all extra lines from a text file (that is, allow only one empty line between paragraphs.)
parse text [some [thru lf [lf some remove lf | none]]]
Here's an a paragraph "unwrap" example. It makes a sequence of adjacent lines into a single long line.
parse doc [
some [
not lf thru lf
some [s: not lf (change back s space) thru lf]
|
thru lf
]
]
Perhaps you see a slightly better way to write that?
These little parse expressions are really useful, and it'd be great to gather them together onto a single web page so that we don't have to re-invent them each time.
Here's a page where you can post them: Common Parse Patterns.
13 Comments Comments:
Endo
22-Feb-2011 2:13:04 |
This is a great page. And please add most used charsets also:
digit, digits, alpha, alphanum, hex etc. | James_Nak
22-Feb-2011 8:19:07 |
Man, that IS a great idea. Thanks. | Steven White
22-Feb-2011 8:47:14 |
I hate to whine, AND I realize that I am a relative REBOL beginner, AND I don't use parse much, BUT, I would find it extremely helpful if these examples could be annotated a bit. I did just read the documentation about parse, but that first example remains a perfect example of a problem I continue to have with REBOL (a problem that is my own problem, I do admit). I look at ONE LINE of code, and I just don't get it. If anyone else is like me, then a few comments could save, world-wide, many person-hours of head scratching.
Thank you. | Hallvard
22-Feb-2011 11:13:23 |
Steven, read this: http://www.codeconscious.com/rebol/parse-tutorial.html | Steven White
22-Feb-2011 14:06:34 |
Thank you, that was helpful. It helped me understand parse, but also helped me understand why I don't understand.
I read the REBOL documentation this morning, and the tutorial this afternoon. As I read the tutorial, a couple times I had the experience of thinking, "Aha, so THAT'S what they meant in the documentation." I also encountered a few situations where I did not grasp one little point, and then, a bit later, because of lack of understanding of the previous point, I could not understand a following point, and by the end of the tutorial my brain was fried again.
I think that when the REBOL experts explain things, they know the material so well that they can't always comprehend what a beginner doesn't understand. Therefore, I still think that comments are good because they just keep hitting the material from different angles, and eventually they pound the knowledge into some of those thicker skulls.
Regarding the first example above, I now do get the general idea of what is being done. Find a line-feed character, and if the following character is a line feed also, remove it, leaving only one line-feed. A blank line is defined as a line-feed immediately following another line-feed. (In my world, a blank line is a line containing one or more blanks, an example of something a person from a different world might not even comprehend.) I could not close my eyes and tell anyone how to code the above example. | Kaj
23-Feb-2011 16:02:15 |
To understand those text manipulation examples, one has to know how Carl likes to format his texts (in several varieties of MakeDoc format). That's quite apart from PARSE and REBOL themselves. | Carl Sassenrath
26-Feb-2011 10:53:36 |
I've added explanations to the wiki's parse page. This should help new users understand how it works (in R3 that is.) | jocko
26-Feb-2011 21:23:39 |
Concerning the parsing and formatting tools, I often use clean-script.r, but it seems not compatible with r3. A new version would be useful. | Steven White
27-Feb-2011 13:07:24 |
Thank you for the explanations on the parse page.
I realized, when reading that single line to remove extra blanks, that some years ago I had to have a procedure to do the same. The tool available was COBOL. I wrote a little re-usable module that I have used many times over the decades. I looked at the code today, 61 lines.
A number of times with REBOL, I have tried to do something, beaten my head on it for quite a while, finally accomplished it, looked at the results, and found that it was only a couple lines of code. I have found myself thinking, "Is that all there was to it?" Sort of fun.
| RobertS
28-Feb-2011 7:59:28 |
I think that the Common Parse Patterns page deserves a place on the rebol.net home page.
| Edoc
22-Mar-2011 10:52:14 |
Needed: An all-in-one CTO, chief evangelist and computer language guru who can post to a blog more than once per month. :) | Steven White
28-Mar-2011 9:01:20 |
That's an interesting idea. I have wondered at times if some things would become dramatically clearer if Carl himself would explain them. I believe there is some programming concept out there, "extreme programming" or something like that, where two programmers actually work at one computer. An "extreme CEO" could sit at Carl's side daily, know everything there is to know about REBOL, be a Carl clone, but then Carl would do the programming and the clone would do other stuff, the explaining, blogging, evangelizing, etc. Not that I would know how to make that actually work... | Steven White
27-Jul-2011 8:12:28 |
The "Common Parse Patterns" page above seems to be for R3 code only, according to the note at the top.
I see the value of a common parse patterns page. It seems to me that some people are able to learn a general concept and then create instances of it, but others need an example first to understand what the general concept is trying to accomplish, then can understand the concept, then can create their own instances of it.
So here is one. To copy a file from one directory to another, one has to get the name of the file, then locate just the last node of the name, then build up the new path name. Parse works handily to get the last node of a full path name, as follows:
FILE-PATH: first request-file
FILE-NAME: last parse to-string FILE-PATH "/\"
If I understand correctly the idea of the common parse patterns page, the 'last parse to-string FILE-PATH "/\"' is a common pattern because it accomplishes what would be a bit of fussing in another language, in such a small number of words that it would not be worth the effort to code up any sort of re-usable procedure for it; one would just restate that pattern whenever one wanted to accomplish that result.
|
Post a Comment:
You can post a comment here. Keep it on-topic.
|
