Partial application in C

Dave Jones djones at megatest.UUCP
Sat Jul 9 05:55:50 AEST 1988


>From article <429 at uwovax.uwo.ca>, by 16012_3045 at uwovax.uwo.ca (Paul Gomme):
> In article <619 at goofy.megatest.UUCP>, djones at megatest.UUCP (Dave Jones) writes:
>> 
>> From article <3353 at cognos.UUCP>, by jimp at cognos.uucp (Jim Patterson):
...

>>> there are machines that don't allow you to execute data as
>>> code.
>> 

...

> 	Unless my memory is failing me completely, I believe that OS/2 will
> absolutely prohibit "executing data".

...

> 	Besides, I thought that self-modifying code was (a) extremely difficult
> to write, and (b) considered poor programming practice.
>


(a) "Extremely difficult" is what makes this job fun.
(b) I'm sure it is considered poor practice by many. And for most
    applications, I agree.  But that will not slow me down if it's the 
    best engineering solution available.
    
    What tends to be frustrating is to come upon a situation where you
    have been prevented from using some technique only because some
    I-know-your-job-better-than-you-do has decided to prevent anybody
    from ever using the technique.

    However, the kind of stuff I am talking about is not what is
    traditionally called "self-modifying" code.

    I'll give you an example from actual practice:

    You have a Pascal compiler's source code.   You want to provide
    a debugging tool which will compile and execute Pascal code on-the-fly,
    as it is typed in by the user at runtime at a "breakpoint".
    You must be able to call the user-defined procedures and inspect
    and modify user-defined variables.  You even want to be
    able to redefine a procedure (when you find a bug) and link in
    the new version, without recompiling the entire program or losing
    the program's context.  (I think PPI and Sabre Software have such 
    facilities for Objective C and C, respectively.)

    Solution: When the user prepares the program, "freeze" the compiler
    after it has parsed the program.  Use the "frozen" compiler to 
    compile the interactive code.  Read it into the program (as data),
    link it, and then branch to it.  What you have done is exactly what a
    normal compiler and linker would do, except that you have done it
    at runtime.

    We have been using this technique, with great success, for over five
    years now.  We've even been able to get the interactive response time
    on short code sequences down to a respectable 200 Ms or so.  
    (Works good. Lasts a long time.)


    

			-- Dave J.



More information about the Comp.lang.c mailing list