If I understand correctly, D templates can take text as parameters.  I also understand that there are limitations as to the length of the text string. If this limitation could be eliminated, would it then be possible to generate highly-optimized source code from a regular expression at compile time?

Just a thought.

-Craig

Yes, that would be quite a feature :-)

There was quite a bit of discussion early in the year about supporting regex-expressions as a first class citizens within the language. Doing so via a template could be a fine resolution.

- Kris

"Craig Black" <cblack@ara.com> wrote in message news:dnkj03$298u$1@digitaldaemon.com...
> If I understand correctly, D templates can take text as parameters.  I also understand that there are limitations as to the length of the text string. If this limitation could be eliminated, would it then be possible to generate highly-optimized source code from a regular expression at compile time?
>
> Just a thought.
>
> -Craig
> 

These new D features are very exciting.  D is breaking into new territory and the implications are vast and unexplored.  It's like buried treasure.

-Craig

Craig Black wrote:
> These new D features are very exciting.  D is breaking into new territory and the implications are vast and unexplored.  It's like buried treasure.
> 
> -Craig 
> 

It's like being the first to walk on Mars. :-)

In article <dnkj03$298u$1@digitaldaemon.com>, Craig Black says...
>
>If I understand correctly, D templates can take text as parameters.  I also understand that there are limitations as to the length of the text string. If this limitation could be eliminated, would it then be possible to generate highly-optimized source code from a regular expression at compile time?
>
>Just a thought.
>
>-Craig
>
>
How about a special case of templates that allow any arbitrary constant parameter but may only be used in a context where they can be reduced at compile time to a constant literal. this might be permissible because there would never be a need to generate a mangled name for the specialized template. This would allow things like this.


isOneOf(T i, T[] a)
{
static if(a.length == 1)
const bool isOneOf = is(i == a[0]);
else
const bool isOneOf = isOneOf!(i, a[0..length/2]) || isOneOf!(i,
a[length/2..length]);
}

or maybe even things like mergesort and array filters.

BCS wrote:
>
> How about a special case of templates that allow any arbitrary constant
> parameter but may only be used in a context where they can be reduced at compile
> time to a constant literal. this might be permissible because there would never
> be a need to generate a mangled name for the specialized template. This would
> allow things like this.
> 
> 
> isOneOf(T i, T[] a)
> {
> static if(a.length == 1)
> const bool isOneOf = is(i == a[0]);
> else
> const bool isOneOf = isOneOf!(i, a[0..length/2]) || isOneOf!(i,
> a[length/2..length]);
> }
> 
> or maybe even things like mergesort and array filters.

I think this should already be possible, as the optimizer should throw away most metaprogramming template code once the constants have been determined, which should precede any symbol length errors.


Sean

Can the following (or it's equivalant) be done in a template, if so how?

template moo(T[] a)
{
	T[] moo = a[0..length/2];
}

> How about a special case of templates that allow any arbitrary constant
> parameter but may only be used in a context where they can be reduced at
> compile
> time to a constant literal. this might be permissible because there would
> never
> be a need to generate a mangled name for the specialized template. This
> would
> allow things like this.
>
>
> isOneOf(T i, T[] a)
> {
> static if(a.length == 1)
> const bool isOneOf = is(i == a[0]);
> else
> const bool isOneOf = isOneOf!(i, a[0..length/2]) || isOneOf!(i,
> a[length/2..length]);
> }
>
> or maybe even things like mergesort and array filters.
>
Are you suggesting working around the limitation by inlining the method and thereby eliminating name-mangling?

-Craig

On Mon, 12 Dec 2005 17:44:57 -0500, BCS <BCS_member@pathlink.com> wrote:

> Can the following (or it's equivalant) be done in a template, if so how?
>
> template moo(T[] a)
> {
> 	T[] moo = a[0..length/2];
> }

I came up with:

private import std.stdio;
template moo(T, T[] a)
{
   const T[] moo = a[0..a.length/2];
}
int main()
{
   const char[] s = moo!(char, "hello world");
   writefln("%s", s);
   return 0;
}

and DMD complains:
   Error: arithmetic/string type expected for value-parameter, not T[]

Change the "T[] a" to "char[] a" for the template and it works.

Craig Black wrote:
>>How about a special case of templates that allow any arbitrary constant
>>parameter but may only be used in a context where they can be reduced at compile
>>time to a constant literal. this might be permissible because there would never
>>be a need to generate a mangled name for the specialized template. This would
>>allow things like this.
>>
>>
>>isOneOf(T i, T[] a)
>>{
>>static if(a.length == 1)
>>const bool isOneOf = is(i == a[0]);
>>else
>>const bool isOneOf = isOneOf!(i, a[0..length/2]) || isOneOf!(i,
>>a[length/2..length]);
>>}
>>
>>or maybe even things like mergesort and array filters.
>>
> 
> Are you suggesting working around the limitation by inlining the method and thereby eliminating name-mangling?
> 
> -Craig 
> 
> 
More or less.

IIRC the name-mangling is needed to put the template instance into the symbol table. If it all ends up as a literal, it doesn't need to be put in, just as a string literal never ends up in the table