Motivation for compile time function execution

[Pragma]

Walter Bright wrote:
> Pragma wrote:
>> I've found that treating meta programming like lisp (thanks to 
>> everyone who drew those parallels this week) is the first step.  
>> Adopting this mindset makes #1,#2 and #3 somewhat moot.  You only wind 
>> up in trouble if you try to approach it like normal D code (DMD 1.006 
>> is going to change that quite a bit).
> 
> To someone who is comfortable with Lisp, I agree that 1, 2, and 3 are 
> moot. But most of us aren't, and a very common request I'd get is to 
> make metaprogramming look "like normal D code." The eventual 
> metaprogramming goal is to get the power of Lisp expressible in the 
> "normal D" syntax.

Actually, FWIW, I'm not comfortable with Lisp.  D template coding is just "noisy" enough for me to grok as a list 
processing grammar. In contrast, my comprehension of Lisp breaks down after about three or four nestings.  Yea, I'm 
probably a huge weirdo in that respect. ;p

But I'm all for the changes and improvements.  Your rationale for adding to things is dead on.

> 
> 
>> To that end, I went about writing a parsing lib in the same vein as 
>> Enki.  I currently have a tokenizer (attached) that will turn an input 
>> string into a tuple of token 'structs', complete with line/col 
>> information.
> 
> I was thinking of writing one myself, you beat me to it.

Well, consider it public domain then.  Everyone, hack away as you wish.

> 
>> By this, I've found that using tuples has addressed point #4 only 
>> slightly by avoiding the kludge I added to the regex lib.  
> 
> Right, tuples don't fix the mangling problem at all.
> 
>> Passing such large tuples around still bloats the template 
>> "manglespace" horribly, and generating the list is about as bad.
> 
> Yes, this is the motivation for compile time interpretation.
> 
>> That said, Walter, I think you're on the right track by making 
>> functions compile-time capable.  I might just refactor my code to take 
>> advantage of this.
> 
> I think for parsing strings, this will vastly improve things.
> 
>> This leads me to two questions for DMD 1.006:
>>
>> Say I convert my tuple-processing code into compile-time functions 
>> that use const lists instead.
> 
> I think the right result would be array literals.

You're right.  My fingertips weren't connected to my brain in that sentence.

> 
>> What is the primary tradeoff, increased compile-time for unlimited 
>> call-depth due to non-bloated namespaces?  Is there another tradeoff 
>> that is more dominant here, and not as obvious?
> 
> The tradeoff is you won't be able to generate tuples with functions, but 
> you will be able to handle a couple orders of magnitude larger datasets 
> to work on.

Fantastic.  D is starting to look like one of those all-in-one Swiss army knives.

-- 
- EricAnderton at yahoo