Re: Loops using flex/bison..

[Hans Aberg]

At 00:45 -0500 2002/02/06, Matthew Tedder wrote:
>> The Bison generated parser does not back-track (ever), and in addition may
>> apply reductions before an error is detected, so if your idea is to step
>> through the text one token at a time and interpret it as you go along,
>> Bison is not at all suitable for that approach. -- But this is not a very
>> efficient approach:
>
>But flex/bison must have some idealized way of doing this.  If an
>intermediate code was invisioned, why did they design lex and yacc to tie
>directly together?  There must be some intended manner of implementing loops
>and labels..

I really don't understand your question: The way Flex and Bison works
together is the most efficient one. Backtracking (or re-interpretation)
adds a heavy penalty in performance.

>You might be intirely right, since it's not intended to be a compiler.  The
>idea of making this an interpreter was to enable certain things a compiler
>cannot do--such as executing code assembled at run-time in a string variable.

Why don't you just include the compiler withe the runtime code? If you make
a DLL, it needs not to be added twice to the system.

> This has applications where users need to assemble data processing logic,
>such as for contract management and other uses..  This is a critical
>capability of the Mumps language using in medical facilities.  Unfortunately,
>Mumps is not very lay-person friendly.

You should have cc'ed Bison help, because I do not know about Mumps.

>For my purposes, the main benefit of BASIC is in making it very easy to code
>in for professionals in other fields, not programmers.

You should perhaps check out the Freecard mailing list -- they seem to do
just this, but using various HyperCard like languages.

>> >  I have some great ideas for enhancing it.
>> > I also thought about using flex to translate BASIC to C.
>>
>> But this seems like a simple approach if you want to produce efficient
>> output code.
>
>Yeah... I might want to do this as a second project..  The interpreter has
>different benefits.  I think translation to C++ might be good for RAD game
>making...  I could make BASIC commands for QT's qcanvas class and other
>related goodies..  At the very least, it could make great skeleton code.

But this would not work (well) if you want strings to be interpreted on the
fly. (Unless you hook up a full C compiler.)

>> >  Would it be
>> >possible to turn such a thing easily into a gcc front-end?
>>
>> I am not sure what you mean by "gcc front-end" here: Note however, that the
>> Haskell compiler GHC <http://haskell.org/> produces C as output. I write on
>> a compiler of my own OOPL that produces C++ as output.
>>
>> The GHC compiler is tied to GCC only because it uses special GCC compiler
>> features. If you produce standard C/C++ as output, which I figure would be
>> possible with Basic, then that would not be needed.
>
>Maybe I was thinking of something very similar then.  I hear GNU's C++ was
>originally just a tool that converted C++ code to C code.  It was then
>accepted into the gcc family, I believe.  Therefore, would such as approach
>be viable to adopting BASIC into the gcc family.

It is at least an easy starting point. One can then successively rewrite
the portions needed. This is a common approach. For example, Java is said
to be written in earlier versions of Java. If one implements a C compiler,
one can implement a small part of it, a kernel, in assembler, and then
implement the rest in this mini-C.

The best place for such discussions is probably comp.compilers.

  Hans Aberg