Re: [Pyparsing] text grammar -- single sample

[spir <den...@fr...>]

Paul McGuire a écrit :
 > Ralph -
 >
 > Actually, spir/Denis is proposing a specialized form of BNF, which would be
 > compilable into pyparsing constructs (I think that's where we left this idea
 > last), probably using a pyparsing parser.

Exactly. Would be highly useful for a present project of mine: I need to write 
the grammar at runtime because it depends on user choices. Then I realized that 
it may be worthwhile for other needs; kind of alternative, or desigh-time 
format. Reason why I let my explorations public, could be a collaborative work. 
Now, just ignore if you do not care.

 > I do agree, though, that writing up an actual example would be very
 > instructive, both in conveying the concepts, and in actually testing the
 > syntax out.  How about this for a test structure, a log message:

I do agree, too. Simply illustrating, testing and such things are not my cup of 
tee... each one his/her favorite playing field. If you're interested, 
contribute with what you like to do or what you are good at.

 > An integer message number
 > Date/time timestamp
 > Severity (Debug/Info/Warning/Error)
 > Message everything up to the end of line
 >
 > Example:
 > 10001 2008/11/18 12:34:56 Error A bad thing happened
 >
 > Use the syntax to name each field, each field in the date-timestamp, and
 > convert the integers to actual integers and the date-timestamp into a
 > datetime.datetime (that is a datetime object as imported from the Python
 > datetime module).

Anyway,... some notes:
* Nothing is fix in grammar format yet. All open to critics. Just propose 
better alternatives with rationale.
* There may be parsing directives to allow programmer control (like preprocessor).
* Right side is a field for all post-parsing actions including Group-ing 
Combin-ing, pattern naming (= result typing).
* All patterns could be automatically named (using left-side name) with a 
"grammar directive": this feature does not fit here, as some patterns are not 
to keep (they define tokens, as opposed to products).
* All "post-processed" patterns could be named: this would be all right here. 
No need to rename on right side like I did below -- all products would then 
hold their type like "naturally".
* Some fields can be especially typed to catch their special *role* in a 
specific situation. I wrote the 'text' pattern to illustrate this feature with 
'severity': results would get 'word' & 'severity' respectively as .nature & 
.role attributes.

d			: [0-9]
number		: d+						: int "number"
date		: d4 '/' d2 '/' d2
time		: d2 ':' d2 ':' d2
date_time	: date time					: <> datetime.datetime "date_time"
word		: [printable]+				:
text		: word"severity" word*		: <> str "text"
message		: number data_time text		: () "message"
NL			: '\10' '\13' '\13\10'
log			: message (NL message)+

comments:
~ d - NL: There may be constants for such things --> [digit] [new_line]
~ date time: Use of ints as quantifiers seems both useful and easy.
~ date_time, text: <> means concatenation (= Combine())
~ message: () or {} could mean packing (= Group()). Not to be confused with 
in-pattern expression grouping with (), too... {} for Dict() instead? See 
previous & next posts.

I realize that a whole lot of charset constants could be worthwhile, too.
Imo separation of pattern expression and post-parsing action is very good for 
legibility.
About right side actions: I will send a separate post on the topic -- have a 
better image of what fits in, and how.

 > You can also look back on the examples I've posted over the past few years
 > on comp.lang.python and use one of them.
 >
 > -- Paul
 >
 >
 > -----Original Message-----
 > From: Ralph Corderoy [mailto:ra...@in...]
 > Sent: Tuesday, November 18, 2008 2:40 PM
 > To: spir
 > Cc: [pyParsing]
 > Subject: Re: [Pyparsing] text grammar -- first rough
 >
 >
 > Hi spir,
 >
 > I don't wish to discourage your using the list as a sounding board, but I
 > for one would have more inclination to read in detail if there was an
 > example at the top that contrasts how I'd have to write something now in
 > PyParsing compared to the better way I could write it with your suggestions.

nou spennn yer prrishuz taym n inerdji !

*I* will not supply samples only for advocating. I like design instead. I do 
this for I wish to do it, because it fulfills a need of mine, and brings me 
pleasure. If *you* feel like having illustrations, if you think it would be 
worthwhile for others maybe: do it.

denis

 > Cheers,
 >
 >
 > Ralph.
 >