[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interactive parsing with Bison

From: Hans Aberg
Subject: Re: Interactive parsing with Bison
Date: Fri, 7 Jul 2006 10:48:01 +0200

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]