Re: [Pyparsing] more refinement but still lost

[Eric S.. J. <es...@es...>]

----- Original Message -----
> From: "Paul McGuire" <pt...@au...>
> To: "Eric S.. Johansson" <es...@es...>, pyp...@li...
> Sent: Tuesday, September 18, 2012 7:55:17 AM
> Subject: RE: [Pyparsing] more refinement but still lost
> 
> Sorry for my terse reply earlier - hit send too early!

Not a problem. That happens to me with speech recognition errors. Sucks being disabled and then your tools bite you in the ass.

> 
> Eric, you have definitely taken on an ambitious first-project for
> pyparsing. Writing BNF's takes some practice, but it is important to really get
> your thoughts down about how the parser is supposed to work before getting
> mired down in Words, and Groups, Forwards, etc. In your nested terms, let
> the recursion in the BNF take care of nesting []'s - when you have
> LBRACK/RBRACK in two different levels of your nesting, it's a sign you should
> rethink just how you have defined the contents of this group.

Yes it is an ambitious project. As I've probably said earlier, I am disabled and as a result have become quite smart about user interfaces. Sadly, not being able to write code or webpages gets in the way of proving my intellectual capabilities vis-à-vis getting a job. The usability model behind this project should allow me to show off some of my UI chops.[1]

The syntax was one I inherited from another project but it turned out to be a great base for a speech recognition friendly method of generating webpages. I know that the differentiation between arguments and keywords using the same bracket is problematic. I've been wrestling with that one for quite a while. One model says change the notation between keywords and arguments. another says change the notation completely so that the problem doesn't come up. I'm open to suggestions I think the fundamental structure should remain the same because it works for speech recognition use. Could use a little boost from a smart editor but hey, I will live with what I've got.  in any case, I'm open to suggestions for reworking the syntax/notation

Mixed text:: = [<plaintext>]* 
               [<open square bracket> <keyword> 
                   [<open square bracket><argument> [<mixed text>]<close square bracket>]*
                   [<mixed text>]
               <close square bracket>]
               [<plaintext>]* 

I think that's the best definition of how it is now. I'm trying to think of a way I can make arguments as functions you to go away and be replaced by keyword definitions everywhere
> 
> Here's my earlier post, with annotating comments.

Thank you. I'll take a look later today.

--- eric

[1] https://docs.google.com/document/d/1In11apApKozw_UOPAhVz0ePqns72_6652Dra34xWp4E/edit
http://blog.esjworks.com
core ideas behind using speech recognition for programming