Can a low-level programmer learn OOP?

Eddie Corns eddie at holyrood.ed.ac.uk
Tue Jul 24 20:36:24 CEST 2007


Paul McGuire <ptmcg at austin.rr.com> writes:

>On Jul 23, 12:43 pm, ed... at holyrood.ed.ac.uk (Eddie Corns) wrote:
>> Paul McGuire <pt... at austin.rr.com> writes:
>> >On Jul 23, 5:53 am, ed... at holyrood.ed.ac.uk (Eddie Corns) wrote:
>> >> Wolfgang Strobl <ne... at mystrobl.de> writes:
>> >> >few of James Gimple's snippets from "Algorithms in SNOBOL4"
>> >> >(->http://www.snobol4.org/) as an exercise using that library might help
>> >> >to get a better appreciation. Perhaps I'll try, eventually ...
>>
>> >> I never noticed them or the PDF of the book there before.  Some Friday
>> >> afternoon reading for sure.
>>
>> >> Personally I hope to get more to time to look at a combination of Lua and
>> >> PEGs (http://en.wikipedia.org/wiki/Parsing_expression_grammar) for my parsing
>> >> needs.
>>
>> >> Eddie
>> >If you get a chance to look at pyparsing, I'd be interested in your
>> >comments.  The PEG page and the SNOBOL implementation have many
>> >similar concepts with pyparsing (or is it the other way around?).
>>
>> It's on my list of things to get round to.
>>
>> I think what I'm really after though is a parsing DSL.  I only did only one
>> fairly small project in SNOBOL but I was impressed at the ease with which I
>> could express the problem (some googling suggested that many end users found
>> the same).  I guess I want SNOBOL embedded in a modern language with scoping
>> etc.  Python is antithetical to (this class of) DSLs (IMHO) :(
>>
>> Probably what I really need is parser combinators in Haskell or maybe camlp4
>> or some such exotica but unfortunately I've never heard of them.
>>
>> Eddie- Hide quoted text -
>>
>> - Show quoted text -

>I have had pyparsing users refer to pyparsing as an in-Python DSL, and
>others make comparisons between pyparsing and Parsec (monadic
>combinator in Haskell).  I'm not sure why you would say this approach
>is antithetical to Python - the builtin support for operator
>overloading, __call__, __len__, __nonzero__(soon to be __bool__),
>__set/getattr__, etc. permit you to impart quite a bit of expressive
>behavior to your parsing classes.  What I tried to do with pyparsing
>was to emulate Python's builtin container classes and object instances
>with the results that get returned from invoking a parser, so that the
>after-parsing work would feel natural to established Python users.

I don't dispute it is _a_ DSL nor even that it's a very powerful way to do
parsing (in case anyone was wondering).  But my intuition tells me that it
ought to be possible to close the remaining gap and I'm trying to understand
how that could be done and that's the bit I suspect might require a higher
class of DSL (<whisper>ie macros</whisper>).  Of course my intuition never
fails but sometimes reality distorts so as to make me look wrong.

The plan is to apply pyparsing to some real project and hopefully gain a
better understanding.  I have in mind parsing Cisco config files as a first
trial.  As to when I get time...

You see I could just sit down and work out how to solve the problem (eg the
config files) using pyparsing or whatever and move on but I'm sure you of all
people know why that's not enough!

>If you want to just see some existing BNF's implemented in pyparsing,
>you can view them online at the pyparsing wiki.  Here are some
>representative examples:
>http://pyparsing.wikispaces.com/space/showimage/simpleSQL.py
>http://pyparsing.wikispaces.com/space/showimage/fourFn.py
>http://pyparsing.wikispaces.com/space/showimage/jsonParser.py

>-- Paul

I appreciate the input and hopefully one day I'll be posting some questions on
the wiki.

Cheers,
Eddie



More information about the Python-list mailing list