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

Groups > comp.programming > #1162

Re: parser tokens

Show all headers | View raw

Dmitry A. Kazakov wrote:

>> Why do you even need to abstract the stack and the table of a meek
>> parser?
> 
> Because there could be thousands different ways to implement either. There
> are ready-to-use components providing them. The choice should have no
> influence on the parser itself.

Why do you believe that you need to simultaneously support thousands 
different ways of implementing a single parser for the very same language?  
Even if you need to parse a completely different language then basicaly you 
only need to define the tokens, the lexer and the parser table, which are 
specific to each language.  This is easily done in any programming paradigm, 
and it is done so in a very simple and straight forward way in C.  So why 
should anyone rewrite everything following the OO paradigm just to end up 
doing something they already do quite well?


>> 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?
> 
> Abstract data type /= abstract data.

I referred to your previous ADT claim.


>> 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.
> 
> See what happens when things aren't properly abstracted?

What does the use of recursive functions has to do with "things not being 
properly abstracted"?


> If the parser state is an object, what should prevent you from having a
> stack of such objects allocated anywhere you wanted?
> 
> You jump to a certain implementation without even considering any possible
> alternatives.

This is a strange accusation, as your attempt to justify replacing C with a 
language which explicitly supports OO programming is based on a failure to 
consider any possible alternatives to the OO paradigm.


>> Please do tell how you go from using a function pointer to causing leaks.
> 
> Abstraction leaks when implementation details get exposed and can be
> unintentionally or improperly used.

I don't understand what you are trying to say.  Are you trying to say that 
using function pointers causes leaks because a programmer may write buggy 
code?


>> 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.
> 
> I don't see any contradiction. The point was that in a low-level language
> like C, I would be forced to implement some parts of the RTL already
> present in the higher level languages, extensively tested and debugged.
> Why should I reinvent the wheel, the dispatching table in this case?

Why are you talking about RTL and dispatching tables?  Again, it appears you 
are striking that proverbial OO hammer pretty hard for a problem which 
doesn't even resemble a nail.  If it is terribly simple to solve problem 
with basic structured programming techniques then why do you believe that a 
programmer should abandon a specific programming language in favour of one 
which supports your hammer, the OO paradigm?


> 25 years ago I used to write a lot of compiler stuff in K&R and ANSI C. I
> don't want back.

No one is forcing you to abandon OO.  Yet, that doesn't explain why anyone 
should rewrite a project in an OO language just to be able to develop a 
simple parser.  Up until now, the only objective justification you've 
presented was that with OO you could parse streams, files, text buffers, 
stuff which is easily done with non-OO programming.  So, exactly what's the 
point of abandoning C in favour of a OO language just to be able to perform 
such a simple task?


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