Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!ncar!boulder!sunybcs!bingvaxu!leah!itsgw!batcomputer!cornell!blandy From: blandy@marduk.cs.cornell.edu (Jim Blandy) Newsgroups: comp.lang.c Subject: Re: Partial application in C Message-ID: <18609@cornell.UUCP> Date: 26 Jun 88 07:17:31 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <807@garth.UUCP> Sender: nobody@cornell.UUCP Reply-To: blandy@cs.cornell.edu (Jim Blandy) Organization: Cornell Univ. CS Dept, Ithaca NY Lines: 29 About executing data: With rare exception, I think we can all say that self-modifying code is horrid, and anyone who writes it should be left alone. It's nice to have one's code segment protected from out-of-control writes. Caching is great. I'd guess ? that if a program's having trouble with caching, the fault is in the design, not the caching. I wouldn't be too surprised by a notable exception, but I think it's generally true; YOU DON'T MODIFY ACTIVELY RUNNING CODE, so the assumptions made by a caching system should hold. Where executing data really comes in handy is in situations like interactive compilers. For example, Chez Scheme is a neato implementation of Scheme (a popular Lisp dialect); you define a function, chez compiles it and lets you execute assembly language, not some wimpy scheme p-code. If you really want to do this right, you need to put the code somewhere in your own address space; you need to be able to execute your data. One could call this self-modifying code, and they'd be right, strictly speaking, but it's a clean, upstanding use for executable data spaces. (I have no affiliation with the Chez Scheme people; I just think it's a good program.) -- Jim Blandy - blandy@crnlcs.bitnet "insects were insects when man was just a burbling whatsit." - archie