Re: [stack] Re: Jon Purdy: Why Concatenative Programming Matters

> Given 'q' and 'k', both defined in iepos' webpage, we can define:
> 
> "0" = [] [q] [k]
> and
> "1" = k.
> 
> So, for example, "01" evaluates as follows:
> 
> "01" =
> [] [q] [k] "1" =
> [] [q] [k] k =
> [] k.
> 

but the result

[] k

cannot be expressed with the defined combinators 0 and 1, except implicitly with "01"
isn't that a problem?
aren't there actually five combinators?

q 
k 
[q]
[k]
[]

> I can execute
> 'q' using the bit sequence "0011":
> 
> "0011" =
> "0" "01" "1" =
> "0" drop "1" =
> [] [q] [k] drop "1" =
> [] [q] "1" =
> [] [q] k = q.
> 

but "0011" isn't q, only after reduction.

>> does such flat base mean that you can cut an valid expression anywhere to produce two valid expressions?

what about these - more strong - requirements?:

1) you can cut any flat expression anywhere - into two valid flat (sub)expressions.

2) each flat (sub)expression can be reduced one step (or many steps, to reach fixpoint).

3) any flat (reduced) expressions can be concatenated into a new flat expression.

4) this new flat expression can be further reduced (until fixpoint).

5) the reduction order of flat expressions doesn't matter - any reduction order will always yield the same (fixpoint) expression (confluence)

note: reduction = execution,
i prefer to discuss concatenative programming languages in terms of abstract (expression) rewriting.

> 
>> is the high level language independent of the choosen set of combinators?
>> 
> That's tough to answer; I haven't produced it yet. In theory I suppose
> you could write base-independent code in it, but that's not why I'm
> considering writing it -- it's more intended to help me talk about the
> low-level concepts. I'm also interested in what a high level flat
> language might look like; nobody knows.

a high-level flat language would probably have more than two combinators.

> Even more esoteric, though, is the question of what else can happen to
> a flat language. I vaguely suspect that a flat language might be able
> to address control flow. Such a language would not be concatenative in
> the same sense, although it would hold the same aspect in other ways.
> I don't know what it would be.

may be flatness can be preserved if there can't be a construct such as *if-then-else*
may be a flat language should reduce postfix expressions (containing a choice), to both choices.

cheers,

R.