Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!aplcen!haven!udel!princeton!phoenix!pucc!EGNILGES
From: EGNILGES@pucc.Princeton.EDU (Ed Nilges)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <9850@pucc.Princeton.EDU>
Date: 12 Oct 89 16:21:00 GMT
References: <1080@mipos3.intel.com> <48682@ricerca.UUCP> <236@bbxsda.UUCP> <16542@siemens.siemens.com>
Reply-To: EGNILGES@pucc.Princeton.EDU
Organization: Princeton University, NJ
Lines: 34
Disclaimer: Author bears full responsibility for contents of this article

I have followed this discussion with interest.  In modern very-high-
level interpreted languages like REXX, an interesting variant of the
SMC issue emerges.  This is the use of the INTERPRET verb:


     INTERPRET expression


evaluates "expression" and executes it as a REXX statement.  Some of
the same arguments pro and con are used with reference to the use of
INTERPRET: pro:


     1.  It's "efficient"

     2.  It allows me to execute more complex and sophisticated
         algorithms in which code is data and data is code, eg.,
         implementation of expert systems


con:


     1.  It's "confusing"

     2.  It breaks associated technology.  Traditional SMC breaks
         instruction caches and other such contraptions, whereas
         use of INTERPRET breaks compilers.  This last point is not
         a necessity, since the compiler could generate code for
         lazy evaluation of the expression, but the only current
         compiler for REXX simply prohibits INTERPRET.


Other examples of this SMC variant include DO in Hypertalk.