digitalmars.D - Suggestion: "break template;"
- Russell Lewis (35/35) Feb 28 2007 I have been writing a compile-time parser using Tuples and CTFE. I
- Pragma (25/67) Feb 28 2007 I ran into this too when attempting some compile-time parsing. While I ...
- Walter Bright (2/2) Feb 28 2007 I suggest looking at using compile time function evaluation for string
- Russell Lewis (3/5) Mar 01 2007 I've tried that, but I need to return a struct which represents the
- Russell Lewis (9/15) Mar 02 2007 Even if CTFE is upgraded to allow for structs, that still won't solve my...
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
Feb 28 2007
Pragma <ericanderton yahoo.removeme.com>
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
Feb 28 2007
I suggest looking at using compile time function evaluation for string parsing instead of using templates.
Feb 28 2007
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.
Mar 01 2007
Russell Lewis wrote:Walter Bright wrote: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.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.
Mar 02 2007