Re: Loops using flex/bison..

[Matthew Tedder]

The main thing I'm looking for is how the designers of lex and yacc intended
one to design a compiler/interpreter that has looping constructs such as
while, for, and goto/labels?

I have written a lexer and parser using flex and bison that stores and
retrieves data of different types (scalar & array), performs some functions,
and I figured out a way to make If .. Then .. Else .. statements work (though
there's probably a better way).

Other than using an intermediate code, how can one make the execution of
statements jump to a specified point?  Example:
=========================================
start:
  print "My program 1.0"
  print "1. Do something.."
  print "2. Do Something else.."
  input "What do you want to do? "; answer
  if answer = 1 then goto DoSomething
  if answer = 2 then goto DoSomethingElse
  goto start

DoSomething:
  print "You can't do that"
  goto start

DoSomethingElse:
  print "You can't do this, either.."
  goto start
======================================

Your are right that a compile function could be included in a .so file, and
thus called by programs.  Unfortunately, my level of skill is kinda limited
right now..  I don't know how to make a compiler.   I figured an interpreter
would be a good first step.  I also thought that maybe an interpreter would
have a smaller footprint for use on PDAs.  I really like gcc's ability to
cross-compile on just about anything digital.

--Matthew

On Tuesday 05 February 2002 04:56 pm, you wrote:
> 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
>
>
>
> _______________________________________________
> Help-bison mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/help-bison