title: Recursion in Fluent API
body: <p>I am designing a fluent API for writing SQL.  Keep in mind one of my goals is to have API not suggest functions that can't be called in that part of the chain.  For instance if you just got done defining a field in the select clause you can't call Where until you called From first.  A simple query looks like this:</p>
  
  <pre><code>        string sql = SelectBuilder.Create()
              .Select()
                  .Fld("field1")
              .From("table1")
              .Where()
                  .Whr("field1 &gt; field2")
                  .Whr("CURRENT_TIMESTAMP &gt; field3")
              .Build()
              .SQL;
  </code></pre>
  
  <p>My problem comes with recursion in SQL code.  Say you wanted to have a field contain another SQL statement like below:</p>
  
  <pre><code>        string sql = SelectBuilder.Create()
              .Select()
                  .Fld("field1")
                  .SQLFld()
                      .Select
                          .Count("field6")
                      .From("other table")
                  .EndSQLFld()
                  .FLd("field2")
              .From("table1")
              .Where()
                  .Whr("field1 &gt; field2")
                  .Whr("CURRENT_TIMESTAMP &gt; field3")
              .Build()
              .SQL;
  </code></pre>
  
  <p>I am using method chaining to build my fluent API. It many ways it is a state machine strewn out across many classes which represent each state.  To add this functionality I would need to copy essentially every state I already have and wrap them around the two SQLFld and EndSQLFld states.  I would need yet another copy if you were one more level down and were embedding a SQL statement in to a field of the already embedded SQL statement.  This goes on to infinity, so with an infinitely deep embedded SQL query I would need an infinite number of classes to represent the infinite states.  </p>
  
  <p>I thought about writing a SelectBuilder query that was taken to the point of the Build method and then embedding that SelectBuilder in to another SelectBuilder and that fixes my infinity problem, but it is not very elegant and that is the point of this API.  </p>
  
  <p>I could also throw out the idea that the API only offers functions when they are appropriate but I would really hate to do that.  I feel like that helps you best discover how to use the API.  In many fluent APIs it doesn't matter which order you call what, but I want the API to appear as close to the actual SQL statement as possible and enforce its syntax.</p>
  
  <p>Anyone have any idea how to solve this issue?</p>