Loading ...
Sorry, an error occurred while loading the content.

RE: [XP] How to TFD a compiler?

Expand Messages
  • Charlie Poole
    Kevin, ... If this becomes, non-hypothetical, please let us know what you do and how it works out. ... I m trying to make this decision right now. ... Here s
    Message 1 of 2 , May 1, 2002

      > Hypothetically, let's imagine that I plan to write a pseudo
      > compiler that would take a script language file as input
      > (perhaps Ruby), and would output "something else" (perhaps
      > C code, or some kind of bytecode).

      If this becomes, non-hypothetical, please let us know what
      you do and how it works out.

      > As my own Customer, I *know* I want a full langauge, which
      > would lead me towards using an existing YACC-like tool. But
      > that is not where I would start if I take a purely TestFirst
      > approach, one story at a time.

      I'm trying to make this decision right now.

      > If you were about to start this project, would you:
      > 1. Start right off with something like YACC?
      > 2. Start with a single test, and the simplest possible code
      > that could pass that test, essentially rolling your own
      > lexer and parser, and stick with it until it became painful
      > (and perhaps, maybe, possibly, it never would)?
      > 3. Start rolling your own, but "fairly soon" plan to switch
      > over to a more powerful and robust solution like YACC?

      Here's where I'm tending in my own thinking - no guarantee
      that I won't change my mind though.

      I'm not convinced that YACC is necessarily more powerful and
      robust than what I might do. If I use YACC, I'm still coding
      when I write new productions and regenerate the parser. Using
      YACC means that I need to test my produtions and since I'm
      not really sure how to do that, I may not do it as well as
      if I were testing code in C# or C++.

      So I'm leaning toward #3, with the difference that I won't
      go with YACC unless I have a need to do it. If I discover
      some easy way to do my testing and use YACC, then I may
      change my mind.

      I'll do a minimal up front design: parser talks to lexer
      and generates tree structure. Since my language has an
      eval feature, the tree nodes need to know how to either
      generate code or directly evealuate themselves. A higher
      level component will deal with reading files and passing
      them to the parser. That's it... subject to change as
      the application emerges.

      In working on the app, I'll start with a simple test case
      for the parser - reading files is easy and can come later.
      I'll fake the first case or two and add the lexical
      analyzer when it's easier than not doing it. Same goes
      for the other objects that I predict I will need: lexical
      token, tree node, etc.

      Generating actual code is probably going to call for a
      spike. I'm working with .NET so I can do one of two
      things: use the built-in ability of .NET to emit IL,
      or work directly in the format of a PE file and emit
      code manually. Each has pros and cons and it will
      probably take a few days of messing around to decide.

      That's where I am... so far.

      Charlie Poole
    Your message has been successfully submitted and would be delivered to recipients shortly.