POV-Ray : Newsgroups : povray.general : Announcement: Moray acquired by POV-Ray; to be released as Open Source : Re: Announcement: Moray acquired by POV-Ray; to be released as OpenSource Server Time
2 Jun 2024 10:07:02 EDT (-0400)
  Re: Announcement: Moray acquired by POV-Ray; to be released as OpenSource  
From: Darren New
Date: 15 Feb 2007 11:46:56
Message: <45d48e80$1@news.povray.org>
Warp wrote:
>   If you do otherwise you doom yourself to hardcode the input format in
> the program, making it painfully difficult to change the format, add support
> for alternative formats and create alternative ways of generating the data.

If the data structures resulting from the parse are very similar to the 
input language, and you're parsing from a "meaningless" stream of bytes 
into essentially a native representation of the parse tree, this can work.

If you're doing something like generating code as you parse, the 
intermediate level is not as useful.  I've worked with OO parsers and 
structured editors that generate data structures for interpreters. When 
you have 300 mutually-recursive methods each maybe one to three lines 
long, it gets very difficult to figure out what's going on when there's 
a problem.

Plus, the more generic the parser, the more difficult it is to generate 
clear error messages. For example, if your "union" refers to an object 
that isn't allowed to be inside a union, generating the appropriate 
error message can get very messy. You *can* make it work, mind, but it 
can be harder than if you're using a less-data-driven type of parser.

>   On the other hand, each time we wanted to add a new feature common
> to all the programs such as these, if we would had to modify all the
> over a dozen programs, I wouldn't call that "maintainable".

Questions like this always depend on which direction you see a program 
growing over time. It's what makes software architecturing fun.

>   Adding support for new blocks is easy: Just create a new module and
> "plug it in" the parser. In practice this "plugging in" may be as simple
> as adding the name of the module to some array or such.

Or not even that, if you're using a language with reflection. ;-) It's 
exactly the kind of extensibility that Warp is talking about that 
frustrates me so much trying to do big programs in C or C++, with no 
programmatic access to the code I wrote myself. Why should I have to 
tell the compiler *and* the application what the name of the class I 
just added is? :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     New horror show, now only in Las Vegas:
        HANNIBAL LUXOR!


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.