Hi Elan,

maybe I should have spent some more time on this before answering... ;-)

> In my smf? example function I implicitly took advantage of your statement,

Maybe true, but I didn't want to say anything about your example... :-)


> >I'd call it SMC, but even then you still could make lists global (I think).
>
> How does that help? Global lists can still be used to modify the function

I didn't say it would help, on the contrary. I just maent it would still
be
possible.


> >But then there would be a big difference considering the meaning of lists.
> 
> That I don't understand. Since words may have any values, you cannot tell
> whether a block containing some words, when it is eventually reduced, will
> end up dereferencing one or the other word to find that the value's
> datatype is a function ;-).
> 
...
> I had to chuckle when I saw that example. Wickedly, dangerously
> intelligent.  REBOL prides itself that its functions are first class, they
> are data, nothing but data ... If someone were to say (which you just did),
> that the example was not really self modifying code because it was only
> data, then you would be (are) giving a go ahead for implementing self
> modifying data (which includes REBOL functions).
> 
...
> Sure. Now, for some comments ;-) We really need to define what self
> modifying code is under REBOL. IMHO the distinction between code and data
> doesn't work for REBOL, because functions are data. So, you have to be more
> precise.
> 

You're absolutely right, in Rebol everything is data.

But data without interpretation actually is just, well, garbage.

For example "Elan" is a really nice pattern as long as we don't start to
interpret it somehow. As most of us might believe, that pattern forms
some
letters and all those letters make up a word. And as we all know, the
word
"Elan" is the German word for "verve, vim, dash, spirit"! ;-)

So for all the discussion about SMC I think the interpretation of the
data
is the key point. Although in Rebol everything starts as being data some
differences arise when it's interpreted. This surely depends on the
level of
abstraction we talk about, so we should be careful not to mix the level
of
Rebols internal interpretation with the level of programming. Although
with
Rebol that's a little difficult.

So considering the lifetime of a programm, we could say we have three
different
types of data:
1. data that's only interpreted as data, never ever as code
2. data that's only interpreted as code, never ever as data
3. data that's interpreted as data as well as code
In this case only the third has the potential to be considered as self
modifying,
doesn't it?


> 1. A function accesses its own code as data and modifies it. Subsequently
> the words modified or added by the very same function are evaluated. I take
> it that this certainly qualifies as self modifying code:

I'd agree...

For all the other examples I think the scope of view gets rather
important.
Let's say we have a file including some code. Within there are no
refferences
to other files, so that single file is all the code (besides Rebols
internal
code) we have to look at. This file could include some functions,...

So let's take look at your second example:
>> f: func [] [insert second :g [print "hi"] g ]
>> g: func [] []

Function g is obviously not self modifying, it only get's modified.
Function f hard to tell, as it doesn't modify itself, but changes it's
behaviour bey modifying g.
The point is, when you look at the whole code (that single file) it
obviously IS SMC.

I'm getting out of time, so I'll see what you have to say... ;-)

Tom


P.S.: I'll be gone for a few days, so my next reply might take a while.

Reply via email to