Re: lambda-like expressions for C

[Paul Davis <paul linuxaudiosystems com>]

>Therein lies the problem. How do you change the program's behaviour at 
>runtime, without using an interpreted language, or attempting to compile 
>on the fly as you suggest? It can be done, but C++ makes it very difficult.

interpeting and compiling on the fly are formally equivalent. and yes,
C++ (and C) make it difficult with good reason: its not part of their
design. 

>There are (very) good reasons to do this, other (compiled) languages do 
>it, 

Please name one. And by the way, although run-time compilation is a
very interesting area of CS research, i still haven't seen or heard
any programmers complaining that they can't do their jobs without it.

>     and I have C++ code that does exactly this. In my case, I need to 
>defer function evaluation until some later point in the code. C++ makes 

Your language is a bit sloppy here. Calling a function is completely
different than reading a series of (source code language) bytes and
converting them to machine code. If your language distinguishes
between compile time and run time operations (as C++ and C do), then
you have to make that distinction too. If you don't like that
distinction, you're probably using the wrong language.

>this *very* difficult, but I can get some of the way there by storing 
>references to the deferred function's actual parameters, and what the 
>function needs to do, so that it can all be executed at a later time. If 
>I could also get the deferred function from another file at runtime, as 
>Ed wanted, that would be great, but I can't. I found the Boost lambda 
>reference very useful - I may be able to use their expression template 
>mechanism to get a bit further in what I need to do.

the boost lambda expression does not do what you think it does. i
suggest you look carefully at it again. i have lots of code that uses
anonymous function closures. these will not provide the functionality
you described.

>The machine code sequentially reaches a certain address. However, at 
>this address, it finds instructions which should not be executed 
>immediately, but which specify some actions for later execution. Call it 

thats not a problem. but the example you gave didn't involve "finding
instructions", it involved the conversion of source-code to
instructions, which is an entirely different fish.

>an anonymous function, if you want. Possibly much later, it finds it has 
>to evaluate the statements in the anonymous function, from a different 
>context.

repeating myself: "evaluating statements" is what an interpreter
does. "compiling statements" is what a compiler does. "executing
instructions" is what a processor does.

--p