Re: Interactive parsing with Bison

[Hans Aberg]

On 7 Jul 2006, at 06:14, Richard Stallman wrote:

>     But Bison itself is already "incredibly slow", due to its M4  
> component.
>
> What is this?

I think M4 has a tendency to choke on large string inputs. Hopefully,  
Guile would have such a problem. But another problem with M4 is that  
it is macro based, leading to tricky programming, as anybody trying  
TeX knows. A functional language with good, non-choking string  
handling should be able to considerable better.

One reason to use C++ is the absence of a good strings library in C.  
Bison now uses "obstacks", but once an object has been put onto it,  
it cannot be removed. Bison actions now put extra "{" and "}" onto  
these stacks, which makes it impossible to quickly implement a % 
define that is used to place code (top level code cannot be enclosed  
in "{...}". In C++, this "{" and "}" removal would be effortless.

C++ has also the advantage of being able to build automated class  
interfaces. A drawback of these, is if large structures are returned  
in functions, or if one wants to implement a GC, where in effect only  
a reference count would work. But that latter would not be needed for  
Bison.

It is possible to program C++ conservatively. Perhaps one could agree  
on a conservative subset to use.

C++ is better than Java, if one wants to have access to low level  
programming, which Bison needs. So Java is not an option.

And has not SML been replaced by Haskell yet. :-)

  Hans Aberg