Re: Non-greedy wildcard possible? (Long)

[Laurence Finston]

-------------------
> Laurence Finston <address@hidden>:
> >
> [snip]
> > Since I don't think this approach will lead to success anyway, I don't 
> > see any point in going any further into objections with respect to the 
> > details of possible implementations.
> [snip]
> > I think that "a heading is a single line of text followed only by
> > whitespace and two newlines" is a reasonable specification, although
> > it may have to be refined a bit.  I _don't_ think that "a heading
> > might be that, but it might be something else, it's specified by the
> > user" is a specification at all.  
> [snip]
> > I also think that "less markup" is a reasonable goal, but that
> > "virtually no markup" is not.
> 
> How about writing a tool for adding markup based on a user-specified
> format description? That's the goal, and I have already achieved it in
> the current implementation.
> 

This would be the next step.  I can't judge how your previous 
implementation works.
As far as an implementation using Bison is concerned, I think it would be
easier to generalize an existing specification than to try to find a 
general solution first.  
I thought I understood Bison after I read the manual, but it was only 
through using it that I _began_ to understand why it works the way it does and
what one can do with it.  Software tools like Bison are like musical
instruments; you've got to learn to play them, but there's not just one way of
doing it, and there's no end to it.  

I originally thought that you wanted the user to be able to specify the 
formatting rules dynamically, and I think this would make sense, since most
users would presumably not want to build the executable over and over again
while working on their format specifications. However, I think a parser with a
simple structure but with a lot of rules to take care of all kinds of
formatting tasks would do the job better than a complicated one.  I think that
using code in the rules or the scanner that explicitly requires information
about the parser states would not be making the best use of Bison.  After all,
most documents will consist mostly of ordinary paragraphs, with a few other
kinds of elements.  Some elements are probably relatively rare, or only occur
in certain kinds of documents.

I think a scanner, either generated by Flex or coded by hand, would be 
better suited to handling complex input, since it can provide features such as
start conditions.  I would also try to look up items in tables in the scanner
rather than the parser in order to make the task of parsing more
straightforward.

I also think that it would help to make the constraints on the users' 
specifications stricter.  It might be possible to loosen them later, if you 
find that this isn't necessary.

> I've been looking into using Bison for efficiency reasons -- it's
> obvious that you don't think that's doable, and I appreciate that
> input.
> 

I have tried to help you by explaining my reservations about a possible 
implementation using Bison along the lines you've been describing.  I think
Bison could be used for this task, and I've suggested ways of using it that
seem to me to be more promising.  I myself would probably choose to use more
markup and a macro processor, but a Bison parser might be quite nice, too.  

However you decide to do it, I wish you the best of luck. I hope that you 
get it to work and that lots of people use it.

Laurence