Re: [stack] Advantages of cat, joy ..?

John Nowak wrote:
>Stack-based concatenative languages are well-suited to a linear
>implementation; see Henry Baker's "The Forth Shall Be First" paper. I
>may, however, be the only one interested in this.

I vaguley think I read that, but it's not 'hello world'.
The hello-world-principle: a complete demo; is what's missing.
Or at least the 'full top assumption must be stated' to see how
the facility provided by 'cat' will help build the total goal.


JN> The syntax also makes algebraic rules for a concatenative language
very simple. For example, you can express the distributivity of
multiplication nicely without the need for infix operators:

A B + C * == A C * B C * + == [*] papply bi +

You can also manipulate programs easily by prefixing them or suffixing
them. For example, if some program 'A' equals some program 'B', then
program 'F A' equals program 'F B' for any program 'F'. There is no
real equivalent for this prefixing rule in most programming languages.
(The suffixing rule is easy to translate though, e.g. 'A' -> 'A F' is
roughly the same thing as 'a' -> 'f(a)'.)
JN<

OK but what's missing is:
 and therefore X & Y and therefore the productivity is greater.
Like the law-bloke told me 'you must spell out the full allegation
chain; don't vague-out.'
---------------

William Tanksley wrote:
WT>First, they need fewer IDs. Throwaway intermediates don't need to be
given names; they can just be placed on the stack and "flowed" to their
next user. This can be done wrong (by requiring too many stack shuffles)
or abused (even elegant code can, in theory, overdo deep stack use), but
anything worth doing can be done wrong :-).

Second, because concatenative languages don't depend on IDs to get data
from one place to another, they also can't teleport data from one place
to another; the data flows along in the same direction as you read the
program. <WT ------

OK the 'flow & transformation of data through the process' is a
powerfull & natural concept which could potentially help manage
complexity and increase productivety. Lambda IDs are effectively
achieved by hiding the local ID in subroutines in applicative
languages. And then 'data flow through the process' can be
acheived by functions, although: A.B.C.D is nicer syntax than
lispy D(C (B (A))).

> * the gap between forth's syntax and natural
> language [which we've been practicing all
> our lives] reduces productivety.

WT> What does this have to do with concatenative languages? Every precise
language has a gap between it and everyday language; that's inherent in
the different needs of precision use versus everyday use. Even legal
documents are hard to learn to read and write, and they're nowhere near
to being accurate enough for a machine to execute.

No ! Obviously Pascal is closer to natural language than forth
or even C, which is a massive advantage ?

> * the arbitrary syntax of especially the new
> constructs of OOF, could be profitably handled
> by templates, or even better a structured
> editor, instead of 'learning telephone numbers'.

WT>
I don't know what you're talking about by "especially the new
constructs". I suspect I know what you mean by "learning telephone
numbers" -- I think you might be saying that the OOF.fs package has too
many words that take a large number of parameters, and so you're stuck
memorizing the order of parameters. (I'm only guessing here, in case
you're alluding to the idea that human short-term memory can handle at
most 7 gestalts at a time.)

As a prompt to 'how cat increases productivety', I'm giving
examples of what IMO *does* increase productivety. OOF and all
languages have their syntax for any 'construct' including the
declaration and definition of classes/objects. So eg. an
IF/THEN/ELSE in all laguages is just a thing with 3 args.
So you forget about all the syntax crap, and just fill in
the args.

WT>
You're also overlooking the fact that theoretical roots are very complex
things to trace. You express them mathematically above, but math doesn't
express human factors, which are far more important. A full
understanding of human factors can only be seen by implementing a model
and seeing how real humans use it.

Yes ! you've touched the essence of the matter: HCI is soft &
slippery, and we technos don't want to be bothered with
'womans stuff', but we must. Like your 'flow of data' concept
above could be further expalained as 'the mind can concentrate
on a single entity [the current data/stack] instead of multiple
side-effects'.  BTW this 'knowing by doing' I call bicycling:
you can do it, but you don't know how.  I want to formalise the
job and replace art by science.
--------

WT>
Representing stack-based code in a graphical manner exposes
essentially all of the parallelism you'd get in an applicative
language.

Some months ago, there was a post here with a diagram:
very simple & coloured of 'A,B,C stacked and progressing'
which I was amazed/frustrated at not being able to understand,
because I'm fanatically keen on visual & colour tools.

Thanks,

== Chris Glur.