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