Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #1160

Re: parser tokens

From Rui Maciel <rui.maciel@gmail.com>
Newsgroups comp.programming
Subject Re: parser tokens
Date 2011-12-30 16:09 +0000
Organization Aioe.org NNTP Server
Message-ID <jdknnp$6gr$1@speranza.aioe.org> (permalink)
References <4efd343a$0$18601$bbae4d71@news.suddenlink.net> <zssptqkx73l7.151z78ll8bbk0.dlg@40tude.net> <jdkjb1$qsn$1@speranza.aioe.org> <gq3rcwt0u3m3.lynpff502ffi$.dlg@40tude.net>

Show all headers | View raw


Dmitry A. Kazakov wrote:

> On Fri, 30 Dec 2011 14:54:28 +0000, Rui Maciel wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>>>> I am wanting to do this in C also.
>>> 
>>> I would suggest a language with OO support. It is much more elegant and
>>> easier to implement a table-driven parser in an OOPL.
>> 
>> I don't see why.  A LL parser only requires a stack and a table, and an
>> object-oriented programming language isn't required to implement any of
>> those data structures.
> 
> That depends on what you mean. If you do Turing-completeness, then yes,
> you could implement it in C, Forth, Assembler, machine code, even in
> Convey's Life gliders.
> 
> If stack and table are handled as abstract data types (ADT), rather than
> data structures, then OO gets handy. 

Why do you even need to abstract the stack and the table of a meek parser?  
One is used to store symbols, the other is used to map a pair of symbols to 
a state.  What do you gain by abstracting any of these components? And why 
do you believe that you need an OO language to abstract data?


> In fact there is no need to expose
> stack (or stacks) at all. OO allows you to encapsulate the parser's state
> as an opaque ADT. What is inside is no concern to the end user. And again,
> good design is always rewarded. 


> You get the parser reentrant and recursive
> for free.

It's widely known that recursive parsers are a bad idea.  All they do is 
replace the parser's stack with the call stack, and that in turn opens the 
door to nasty problems such as stack buffer overflows and associated 
security problems.


>> Again, I don't see why.  If you buffer the data stream then you can scan
>> the
>> buffered data without knowing where the data came from.  You just
>> abstract
>> the routine which fills the buffer and go on with your business.  You
>> don't need an OO language to do something which can easily be done with
>> basic C techniques, such as function pointers.
> 
> I prefer proper abstractions, which do not leak. I am too old to enjoy
> walking minefields of low-level C programming.

Please do tell how you go from using a function pointer to causing leaks. 
Then, please explain how you interpret basic stuff such as function pointers 
as "a walking minefield of low-level C programming".


> OOPL does these function pointers for me automatically. Why should I waste
> my time on re-implementing the OOPL's run-time library, testing and
> debugging it, rather than focusing on the main objective?

Your statement is quite odd.  First you suggest that a user abandons C in 
favour of an OO language, and then you complain that you shouldn't be forced 
to waste your time re-implementing things, along with testing and debugging 
them.  This is a considerable contradiction.

Frankly, it sounds an awful lot like the only tool you have is the 
proverbial hammer, consisting of a rather limited view on OO programming, 
and therefore you see every single problem which you face as being the 
proverbial nail.


Rui Maciel

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

parser tokens "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-29 22:46 -0500
  Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 10:50 +0100
    Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 14:54 +0000
      Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 16:26 +0100
        Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 16:09 +0000
          Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 18:22 +0100
            Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 19:33 +0000
              Re: parser tokens "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-12-30 23:08 +0100
  Re: parser tokens "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2011-12-30 12:09 +0000
    Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 14:43 +0000
      Re: parser tokens "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2011-12-31 08:48 +0000
  Re: parser tokens Rui Maciel <rui.maciel@gmail.com> - 2011-12-30 14:23 +0000
  Re: parser tokens Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-12-30 23:41 +0000
    Re: parser tokens "Bill Cunningham" <nospam@nspam.invalid> - 2011-12-31 18:26 -0500
      Re: parser tokens Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-01 01:51 +0000
        Re: parser tokens "Bill Cunningham" <nospam@nspam.invalid> - 2012-01-01 12:17 -0500
          Re: parser tokens Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-01 22:17 +0000
            Re: parser tokens "BartC" <bc@freeuk.com> - 2012-01-01 22:54 +0000

csiph-web