Understanding regexes

[Georg Wrede]

Don Clugston wrote:
> Georg Wrede wrote:
>> Walter Bright wrote:
>>> Georg Wrede wrote:
>>>> Walter Bright wrote:
>>>>
>>>>> If the compiler is to constant fold regular expressions, then it 
>>>>> needs to build in to the compiler exactly what would happen if
>>>>> the regex code was evaluated at runtime.
>>>>
>>>> Yes. IMHO in essence, the binary machine code, which the runtime
>>>> also would build. What I have a hard time seeing is, how this
>>>> differs from building a normal function at compile time?
>>>
>>> Consider the strlen() function. Compiling a strlen() function and
>>> generating machine code for it is a very different thing from the
>>> compiler knowing what strlen is and replacing:
>>>
>>> strlen("abc")
>>>
>>> with:
>>>
>>> 3
>>
>> Either I'm getting too old for this business, or you're only giving 
>> pseudo answers.
>>
>> (1) If we were to stop the compiler dead in its tracks, and I compiled 
>> the function "manually" and returned it to the compiler, would we 
>> still have a problem here?
> 
> 
> That would be OK. The issue is that the compiler is a tool for 
> converting text to machine code. It has no mechanism for executing the 
> machine code.

Aaaaaah... heureka.

So there's a wavelength problem here!

What I've been talking all along, is 'a regexp compiled into a function, 
but _not_run_ at compile time.

** So, Don's regexps can be both "compiled" and "run" at compile time, 
whereas what I've been wishing all along is a "compile-time compiled but 
not compile-time run" regexp!

In other words, a profoundly normal function, just that it happens to be 
written in RegexpLanguage instead of vanilla D (Or C, or asm).

(Gees, I hope this same wavelength problem wasn't the reason for last 
winter's unsuccessful regexp discussions.) :-(