View mode: basic / threaded / horizontal-split · Log in · Help
February 28, 2007
Suggestion: "break template;"
I have been writing a compile-time parser using Tuples and CTFE.  I 
admit, I am writing it basically by thinking iteratively, and writing 
templates that execute the code that would have otherwise happened at 
runtime.

There is one big annoyance I keep running into, though, and it is the 
inability to "return" from this sort of template in the middle.  Imagine 
that I'm thinking something like this (writing it as runtime code, first):
  parse_tree parse(char[] str) {
    if(str.length == 0)
      return new parse_tree; // empty tree

    // do lots of other complex stuff
  }

Now, when I translate this into templates, I get something like:
  template Parse(char[] str) {
    static if(str.length == 0)
      alias struct {} Parse;
    else {
      // do lots of other complex stuff
    }
  }

Sometimes, I end up pretty deeply nested in the else clauses of my 
static if's.  It's technically correct, but ugly.  What I would like to 
see is the template equivalent of "return" - something which would break 
you out of the current evaluation.  My idea is to use the syntax "break 
template;"

Then the template code becomes something which I think is clearer, and 
closer to how I'm actually thinking about things:
  template Parse(char[] str) {
    static if(str.length == 0) {
      alias struct {} Parse;
      break template;
    }

    // do lots of other complex stuff
  }

Russ
February 28, 2007
Re: Suggestion: "break template;"
Russell Lewis wrote:
> I have been writing a compile-time parser using Tuples and CTFE.  I 
> admit, I am writing it basically by thinking iteratively, and writing 
> templates that execute the code that would have otherwise happened at 
> runtime.
> 
> There is one big annoyance I keep running into, though, and it is the 
> inability to "return" from this sort of template in the middle.  Imagine 
> that I'm thinking something like this (writing it as runtime code, first):
>   parse_tree parse(char[] str) {
>     if(str.length == 0)
>       return new parse_tree; // empty tree
> 
>     // do lots of other complex stuff
>   }
> 
> Now, when I translate this into templates, I get something like:
>   template Parse(char[] str) {
>     static if(str.length == 0)
>       alias struct {} Parse;
>     else {
>       // do lots of other complex stuff
>     }
>   }
> 
> Sometimes, I end up pretty deeply nested in the else clauses of my 
> static if's.  It's technically correct, but ugly.  What I would like to 
> see is the template equivalent of "return" - something which would break 
> you out of the current evaluation.  My idea is to use the syntax "break 
> template;"
> 
> Then the template code becomes something which I think is clearer, and 
> closer to how I'm actually thinking about things:
>   template Parse(char[] str) {
>     static if(str.length == 0) {
>       alias struct {} Parse;
>       break template;
>     }
> 
>     // do lots of other complex stuff
>   }
> 
> Russ

I ran into this too when attempting some compile-time parsing.  While I haven't attempted anything since compile-time 
function evaluation (CTFE) was introduced, I did devise the following technique for templates:

template ParseTerm(){
	const char[] Reason = null; // is non-null for any term that fails, and contains the reason
	const bool Passed = true;   // is false for any term that fails
        alias Foobar Result;        // where foobar is any value that you wish to "return" from this term.
}

As long as all your templates in your parser adhere to this "interface", you can do things like this:

template ParseSomething(char[] str){
	alias ParseSomethingElse!(str) Term1;

	static if(Term1.Passed){
		alias Term1.Result Result; // return the result (could be anything really)
		const char[] Reason = null;
		const bool Passed = true;
	}
	else{
		alias Tuple!() Result; // return an 'empty' result
		const char[] Reason = "Parse failure: " ~ Term1.Reason;
		const bool Passed = false;
	}
}

... then use 'ParseSomething' in the same manner as 'ParseSomethingElse' elsewhere in your parser.

-- 
- EricAnderton at yahoo
March 01, 2007
Re: Suggestion: "break template;"
I suggest looking at using compile time function evaluation for string 
parsing instead of using templates.
March 01, 2007
Re: Suggestion: "break template;"
Walter Bright wrote:
> I suggest looking at using compile time function evaluation for string 
> parsing instead of using templates.

I've tried that, but I need to return a struct which represents the 
parse information.  Thus, I can't use CTFE.
March 02, 2007
Re: Suggestion: "break template;"
Russell Lewis wrote:
> Walter Bright wrote:
>> I suggest looking at using compile time function evaluation for string 
>> parsing instead of using templates.
> 
> I've tried that, but I need to return a struct which represents the 
> parse information.  Thus, I can't use CTFE.

Even if CTFE is upgraded to allow for structs, that still won't solve my 
problem entirely.  Since I'm parsing a string into a parse tree, I need 
to be able to allocate an arbitrary number of nodes and use pointers or 
dynamic arrays in my return value.

Or, as I'm currently doing, I can dynamically generate types by nesting 
types inside other types.

The point is: CTFE needs to be a *lot* more flexible before it works for 
this sort of situation.
Top | Discussion index | About this forum | D home