Rebol von Neumann properties (RIP ifs-for-whomever cont.) Re:

[...snip...]

I do like the notion of an Evolving Language. That means a language, whose dictionary is easy to enlarge together with its syntactic/semantic rules. All those properties are present in natural languages, like English, etc. To enlarge a language there must be a possibility to speak about the language in the language. As Carl likes to underline, an Evolving Language must be its own metalanguage. I don't think, that an Evolving Language must be able to do something like: a: [append a [+ 1] 1] do a (a von Neumann property - Pure Self Modifying Code), but I do think, that an Evolving language must be able to do: a: create-a-translation-of something do a , which may be described as a von Neumann property of the language too, but this is a code I would like to describe as a provision to understand Something with new syntactic/semantic rules (a new dialect, if you like, but it might not be a new dialect, but a new stage of the original language evolution). Regards Ladislav

Ah! I should have thought of that one! Silly me!

If I understand your use of the term "evolving language" correctly, back in the 70's we used the term "extensible language" for the same thing (or something quite similar). That term implied that the programmer could: * add new syntactical structures (notation), * add new control structures, * create new datatypes and associated operations, and that having done so, * the extended language would appear as a whole language, without obvious "seams" between the core language and the extensions, and * there should not be a significant performance penalty for using the extensions. However, doing so -- at least when performance was at issue -- seemed always to require fairly intimate knowledge of the implementation of the core language. A prime example is FORTH, which I recall hearing described as "not so much a programming language as a programming language construction kit." So much so, in fact, that it is nearly impossible to write true-FORTH-idiom code without detailed knowledge of the implementation. It should be no surprise, then, that the FORTH community split into factions; such details as the layout in memory of the dictionary data structures could cause code to be highly faction-specific and non-portable!

I believe I understand the distinction you're drawing here, but I must confess that I don't yet grasp HOW to enforce it without either performance penalties or loss of introspection. For example, if I imagine something like active-thing: load-to-read-only-code data-representation do active-thing ALONG WITH the ability to introspect interesting-property: obtain-state active-thing selector then wouldn't I be able to do this altered-property: mutate interesting-property active-thing: load-to-read-only-code replace/all interesting-property altered-property do active-thing and be right back with self-modification, albeit at a severely lowered performance? Have I missed something? -jn-

Extensible Language seems perfect.

The performance subject is very questionable, IMHO. I would call your sample a WYSIWYG code. Let's try to compare it with Pure SMC like: a: [append a [+ 1] 1] do a Don't you see any difference? If I would like to do it in a WYSIWYG fashion, I would have to write: a: [append a [+ 1] 1] do copy a Let's compare the results: the first case:

== [append a [+ 1] 1]

== 1

== 2

== 3

== 4

== 5

== 6

== 8 the second one:

== [append a [+ 1] 1]

== 1

== 2

== 3

== 4

== 5

== 6

== 7

== 8

== 9

== 10

Regards Ladislav