Re: lambda-like expressions for C

[Edward Peschko <esp5 mdssirds comp pge com>]

On Thu, Apr 10, 2003 at 08:23:07AM -0400, Paul Davis wrote:
> >exactly why? fprintf does a close proximity to such a thing, and its used extr
> >emely 
> >heavily. I thought glib stood for 'generic lib' - and a lambda-like extension 
> >to C is 
> >pretty damn generic if done right.
> 
> either i just don't understand what you want to do, or you don't
> understand enough about how a program in C (or C++ or any other
> compiled-to-machine-code language) works when its executing.
> 
> when you write
> 
>      if (i < 50) fprintf (stderr, "something\n");
> 
> this expression is converted by the compiler into machine code. when
> the processor actually executes it, it is simply marching through a
> series of low-level instructions that cause it to do certain basic
> things. it has no clue what the original line of text that you typed
> was that ultimately ended up as this stream of instructions.
> 
> by constrast
> 
>    lambda ("if (i < 50) fprintf (stderr, \"something\n\")");
> 
> is a function call that passes a string to the function. this string
> is just text, and cannot be executed by the current program without
> first converting it to machine code. there are many ways of doing
> that, but they are all very expensive, and would not be used
> lightly. using them for debugging would be, uhm, unusual. the
> "simplest" one is to just feed the string to a compiler and
> dynamically link the resulting object. problem is: no context for the
> variables can be provided. the most "complex" one requires a full C
> interpreter, several of which exist, but again, the interpreter would
> have no context for the variables that you are transferring from the
> outer scope of the "lambda" expression.


To be useful, an eval-like library ( if lambda-like is misleading ) 
doesn't have to be extensive. Nor does it have to be expensive.

----
1  int gt_int (int a, int b);
2  int lt_int (int a, int b);
3  int eq_int (int a, int b);
4  
5  main()
6  {
7 
8     int arg = 40;
9     int trials = 0;
10    int (*func)(int, int) = 0;
11    int compcond = 0;
12
13    while (trials++ < 1000000)
14    {
15 //      if (arg > 30) { }
16         if (cond(arg, ">30", func, &compcond))
17         {
18             fprintf(stderr, "arg = %d", arg);
19         }
20     }
21 }
22
23 int cond(int arg, char *cond, int (*func)(int a, int b), int *cond2)
24 {
25     if (func != 0) return((*func)(arg, *cond2));
26
27     *cond2 = atoi(cond+1);
28
29     func = (cond[0] == '>')? gt_int : (cond[0] == '<')? lt_int : eq_int; 
30 }
31 
32 int gt_int (int a, int b) { return(a > b);  }
33 int lt_int (int a, int b) { return(a < b);  }
34 int eq_int (int a, int b) { return(a == b); }
----

the main function here is cond (to substitute for conditionals) and to 
avoid the overhead for parsing the text I 'precompile' the statement by 
making the text into an equivalent function call. (and I'm sure I could 
think of ways of making it faster..)

Anyways, I benchmarked this, and I get about a slowdown of 100%. 
Not a speed demon, but still very usable when 10^7 comparisons are 
being done in about one second. And a lot faster than a debugger.

> so, as i said, either i am misunderstanding you or you don't seem to
> grasp this basic level of program execution.

no, I know the difference between compile and interpret, 
thank you very much. I also know that changing code, and 
instrumenting it with printf statements is a pain in the rear, 
and that I'd rather control the debugging process from a 
text file if I could.

Ed