[EMAIL PROTECTED] 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-
