Path: utzoo!attcan!uunet!husc6!purdue!decwrl!megatest!djones From: djones@megatest.UUCP (Dave Jones) Newsgroups: comp.lang.c Subject: Re: Partial application in C Message-ID: <644@goofy.megatest.UUCP> Date: 8 Jul 88 19:55:50 GMT References: <429@uwovax.uwo.ca> Organization: Megatest Corporation, San Jose, Ca Lines: 63 From article <429@uwovax.uwo.ca>, by 16012_3045@uwovax.uwo.ca (Paul Gomme): > In article <619@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes: >> >> From article <3353@cognos.UUCP>, by jimp@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.