Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Rebol von Neumann properties (RIP ifs-for-whomever cont.) Re:(2)

From: joel:neely:fedex at: 13-Oct-2000 22:45

[lmecir--geocities--com] wrote:
> ... The only problem of > your code WRT termination is, that it doesn't terminate for some > trivial inputs, such as None supplied as the first argument. >
Ah! I should have thought of that one! Silly me!
> [...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. >
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 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). >
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-