Re: [stack] S-K Construction of Dip?

Manfred Von Thun <[email protected]> wrote:
> "William Tanksley, Jr" <[email protected]> wrote:

> > The problem is that machine language/assembler uses explicit offsets to
> > express jumps and branches, and those destroy referential transparency. In
> > effect, you can't split a valid program into two arbitrary parts and have
> > the two parts still be valid -- if you cut in the middle of a branch, the
> > branch will then lead off into nowhere.

> Since the language had assignments, there was no referential transparency to
> start with.

Oops! I meant to type "destroy flatness", not "destroy referential
transparency". Oops.

Doggone it, one slip like that and my message makes no sense at all.

> counter,..) of the actual or virtual machine. And the concatenation of the
> five operations computes the composition of the five functions computed by
> the five parts. Concatenative according to my definition:
> If P is a program which computes a function F, and Q is a program which
> computes a function G, then the concatenation P Q of the two programs
> computes the composition F G of the two functions.

That's concatenative by my definition as well.

> But I suspect that it is not by your definition. (I got a similar impression
> some time much earlier). You mean (or you also mean, or you mean by ³flat²):

The latter -- I try to use the word "concatenative" in the same way
you do; I try to use the word "flat" to mean:

> If P is a program consisting of concatenated parts p1 p1 .., and P computes
> a function F, then each of the parts compute functions f1 f2 .., and F is
> their composition.

...approximately. Actually, I define it using the hand-waving but
intuitive concept of "splitting" a function into two parts, each of
which is a valid program for all possible splits. I can make this more
rigorous by admitting that "all possible splits" includes some splits
that don't make intuitive sense, such as a split between characters of
a literal; thus I use the idea of the quantitative ratio "flatness",
where you compare the number of possible places to perform a split
with the number of splits that produce two valid programs. Our ik and
ok languages are perfectly flat; there's no possible split that
produces invalid programs, even if you get really pedantic and start
splitting between odd bits.

However, in general, similar languages will have similar possible
splits, so when we're not comparing very different languages -- for
example, the compare-and-branch versus the ik/ok languages -- we can
ignore nitpicking splits that are equally impossible in both
languages.

> This happens to be satisfied by my assembled expression, but it is not part
> of my definition of concatenative.

Agreed. That's why I use the combined expression "flat concatenative"
to describe my language.

> It is true that cutting in the middle of
> a branch leads somewhere else, but where it leads is still dependent on what
> the cut inserts of deletes.

Well, a cut doesn't insert; it only deletes.

> Of course nobody expects cuts to be permissible inside an instruction. Thus
> call(h) does not have 3 parts: cal  l( h).

Right -- it's intuitively not reasonable to split inside an
instruction. I don't count that against the language :-). On the other
hand, if you can't cut inside the instruction, you have to count every
bit, so one can't claim the compare-and-branch language has only one
instruction; each instruction uses all /n/ bits of its encoding, so
such a language has 2^n instructions.

> - Manfred

-Billy