John Nowak <john <at> johnnowak.com> wrote:
> I think the second most interesting thing is that all functions
> operate on possibly empty sequences containing arbitrary amounts
> of program state. It's this "all the state" element that gives
> concatenative languages their character.

Indeed. And you're right when you elsewhere say that this gives
concatenative languages an imperative character.

You're right that any arbitrary function must be able to access all of
the state; but it need not be true that any specific function must be
able to access all the state. Modern concatenative languages use
typechecking to make sure that no function attempts to consume stack
state that doesn't match the function's declaration; but other types
of checking don't have such an obvious typechecking solution. (Were
you the one who designed a concatenative language with side-effect
checking?)

It seems obvious to me that in order to add effect checking, you have
to formally define the effect. Forth's dictionary could be formally
defined and checking there from implemented.

Of course, this is easier to say than to do, and I haven't even said it.

I also admit that by saying this, I have conceded your point. This has
the result of making reordering hard.

> This is very different from concatenative languages where
> combinators like 'bi <at> ' allow the functions provided to step on
> each other as the second function runs on top of the stack
> returned from the first. This is the reason I gave up on
> concatenative languages; the equational reasoning possible when
> all functions operate on "the stack" just isn't great. I think

That specific example need not retain all of its problems, obviously
-- you can define similar combinators to require the forks to have
identical static types, and then effectively isolate the forks from
each other. Factor chooses not to do that, and thereby adds semantics
which are useful for its purposes.

> (as with Joy's 'infra'), is *really important*. While this fact
> is arguably implicit in the definition on Wikipedia, it's not
> spelled out at all. Maybe I can add some insight to it in the
> next few days.

Fair point. We await your input. Fthagn.

> - jn

-Wm

] By substituting, we get a new polymorphic type for 3 within the
] expression:
? does this mean '3 is polymorphic because it can be written as
infinitely typed'?
? what does "within the expression" mean ?

] 3 :: FAC. (C, int) -> (C, int, int)
=> let 3 be a function, which ForAllC, maps (C, int) to (C, int, int)

] This matches the non-polymorphic type:

] 3 :: FAA. (A, int) -> (A, int, int) = FAB. B -> (B, int)
? is there a bracket missing here ?

] So the final type of the expression becomes:

] 2 3 :: FAA. (A) -> (A, int, int)

? why/how ? is this formal maths or Haskell-poetry ?

eas lab <lab.eas <at> gmail.com> wrote:
> This commentor appropriately acknowledges the important cognitive-load aspect:-

Indeed.

> ]the code was always *intensely* write-only since you had to have a
> ]mental model of exactly what was on the stack where to even hope to
> ]follow it.

He's talking about HP RPN code -- fairly low-level code. It's not
entirely fair to attribute cognitive load to stack code when most of
it is due to bad language design.

> *nix piping is beautifully simple yet powerfull, since the stack only contains
> "it" [the previous output]. So that at each/every stage, you only need to know
> about your single-supplier.

True for pipes. Not true for programming in general -- you need more
than one data item per function call.

> Apparently, if the output of stageN includes item/s in addition to what
> stageN+1 needs, they can be left on the stack for stageN+2. But he and
> Haskell/monads seems to 'wrap' the extra item/s and pass it on, and
> imply that some automagic relieves you from the mental load of
> remembering what was left on the stack for all possible
> combinations of stages afterN+1 ?

Haskell would be a fine language to learn; it gives a large reservoir
of concepts to discuss language design.

But no, monads don't relieve your mind; they tend to require a lot of
careful thought, especially if you start mixing them. They have
interesting mathematical properties. You can implement a concatenative
language in Haskell using monads; the stack language is a monoid
(well, according to von Thun).

-Wm

I've become increasingly enthusiastic/obsessed about cat-style.
Clearly there's some ambiguity about 'the definition'.
I'll give my definition AFTER I've shown WHAT problems it solves.
Backus correctly stated the problem before he gave his proposed solution.
That's called goal-directed, and it's the right way, because that's how human.
minds work. We used to call it top-down-programming.
Almost all write-ups on 'Concatenative Programming' show a solution looking
for a problem. MvThun claimed that joy could help do formal proofs, since
it allowed algebraic-like manipulation. That would be great; but did anyone
ever see any such problems solved; eg. proof of an algorithm, via joy?

The 'hello world' concept is powerfull, because it's a FULL demonstration,
which can later be successively refined/extended. Cat-style allows this too.

So the meta-problem is:
how to minimise the concept-counts that need to be handled simultaneously.
I.e. reduce the coupling. It's about the human mind, not technology.

So that eg. you could progress the problem and come back to it next week;
like evolution works: it doesn't NEED to remember and understand previous
steps. And this is vital for serial programmERS.

This little outburst is motivated by another discovery how *nix almost allows
good cat-style: you can 'concatenate the concepts' but not write them linearly
from left to right.

The example problem: I want to reuse a [few-line] script/file, by copying it
to a new-name and editing it. It's called 'Sa'. But I don't know where it is
located. But unix helps with:
whereis Sa == Sa: /usr/local/sbin/Sa

But I only want the 2nd 'string/field' so:
whereis Sa | awk '{print $2}' == /usr/local/sbin/Sa

[DON'T LOOK AT THE SYNTAX: just see blobs concatenated by "|" ]

So that's where Sa is located. But I want to DO something with Sa.

Clearly the evolving structure is:

[[[noun1 verb1] verb2] verb3]
where any verb can have modifiers: like 'awk' has "2": for the 2nd string.
And [[noun1 verb1] verb2] is the noun that verb3 operates on, because
[noun verb] maps to a noun.

But we don't want a lispy-bracket-style. So use a forth-style, where for
readability, we'll put each stage/data-transformation on a new-line:

Sa whereis |
2 FieldOnly | ;; "2" is a modifyer, which joins in the 'data flow'
dog CopyFileAsName

What's really annoying me in linux, is that I have to wrap the existing code
and put <copy it> in FRONT, and then put the copy-destination at the end,
i.e. split/bracket my existing code, instead of just concatenating to it.

So:
cp ` whereis Sa | awk '{print $2}'` dog
does it...
The concatenative concepts are all there in *nix, but the syntax should be:
Sa whereis | 2 Field | dog CopyFileAsName

So I define cat-style as 'the ability to serially transform data, by applying
a <verb/operation> to it, without needing to know/remember how the data was
achieved, by previous stages of transformation'..
That's the concept, which *nix achieves. It just lacks the good/clean syntax.

Thanks,

== Chris Glur. PS. has *nix not got a: <fileName> <printContents> command?

I may have asked this before, [I can't get an answer]: How does *nix.
returning 0 for success and non-zero for different types of function's errors,
instead of the conventional boolean approach, relate to cat/pipe-lining?

Robbert van Dalen <robbert.van.dalen <at> gmail.com> wrote:
>> 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?

Looking elsewhere in your email, I see the problem. This is a good
time to ask that implied question: "is there any difference between
[]k and drop, or between 0011 and q"?

No, it's not a problem, and there's no detectable difference. "01"
performs the action "drop" requires. There are other ways to implement
"drop" as well, all of them taking more bits, more time, and more
stack space. They're perfectly valid implementations of drop, but this
is the one I told you about. (There are good complexity theory reasons
to prefer "01" to any of the others.)

> aren't there actually five combinators?
> q
> k
> [q]
> [k]
> []

There are a countably infinite number of combinators, and zeroone can
express all of them. I'm not showing you [q] and [k] because they're
fairly ugly. [], on the other hand, is quick to produce from memory.
[] = "00101".

One effective way to prove that a base is complete is to use it to
produce all of the combinators in a known complete set. I'll do
that... But not now.

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

See above .

>>> does such flat base mean that you can cut an valid expression anywhere to produce two valid expressions?
> what about these - more strong - requirements?:

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

You later define "reduce" as "execute". I have to point out that some
expressions in any Turing-complete language never reach a fixed point
by execution.

Furthermore, you later assume that the reduced expression is itself
flat; that's not correct in my notation. It's actually possible to
build a formal logic where that does hold, but such a logic will be
both VERY complex and either incomplete or possible to express
contradictions in (per Godel). Using zeroone formally requires
understanding how zeroone works internally first, which is what we're
doing now. It's possible to perform all program transformations by
replacing substrings with different strings (that's called "formal
logic"), but before we can talk about how that works we have to
understand how to discover the meaning of a substring so that we can
prove that the two substrings have the same meaning.

I consider flat formal logic a "later" step, not for now. For now, we
use the semantics of the language to assist in proofs, rather than
doing things formally. Although we ARE using formal logic on the
semantics, it isn't a flat formal logic.

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

Whatever "reduce" means, it doesn't mean this. Sorry, but this would
imply that any two expressions of the same function will always reduce
to the same fixed form, thus allowing you to test in a finite amount
of time whether two functions are equivalent. That's impossible.

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

That's the only way I've really worked it out at this point, so I agree.

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

More importantly, it'll have syntax to allow user-defined names -- so
you can define any combinator you want using zeroone, and from then on
refer to it by name.

>> 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.

Implementing true/false/if/else actually isn't hard; it usually starts
by defining "false" as "drop", and "true" as "execute". The function (
func flag ) "if" would then simply be "execute" -- that is, it
executes the true/false flag, and if that's a 'true' it executes the
function; if it's a 'false' it drops the function.

> R.

-Wm