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

eas lab wrote: 
> 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.

What total goal are _you_ after? You've kinda handwaved a little about
what you want -- something about formal methods and human factors.
That's really cool, and it's never been done before outside of UI
construction. Unfortunately, it's not clear what you're asking us to do
about it. Are you seriously asking us to right-here-right-now give you a
complete formal proof of the usability of concatenative languages --
when you know there's no such thing as a formal proof of usability?

You need to state YOUR goal.

Cat's goals have always been clearly stated: Cat is intended as a more
human readable language for intermediate compilation/code generation
purposes. If that's not enough for you, I don't blame you; but it's
enough for the author of Cat.

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

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

But that's exactly whaty he just did -- he told you the goal (to express
a certain mathematical result clearly), and then he demonstrated it.
That's what he wanted to do.

We still don't know exactly what YOUR goals are. How about you tell us?

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

"Hiding" a local ID doesn't remove it; on the contrary, it adds a new
concept of "name scope" which isn't otherwise present. That, then, makes
it even harder to analyse a code fragment, because its meaning changes
depending on where it appears within the code.

> > * 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 ?

And yet C has CRUSHED Pascal for practical purposes -- and for
educational ones as well (half of my college classes were in C, half in
Java; Pascal was only used at community college).

But I'd also doubt the idea that Pascal is in some measure "closer" to
natural language... Perhaps you're using the isolated fact that Pascal
uses English words in a couple of places that C uses symmetric glyphs,
but this isn't a clear win, and doesn't make the overall result any
closer to natural language -- it affects only _tiny_ details of the
language.

Applescript is intended to be far closer to a natural language; and in
practice, this makes doing complex things with it harder, because you
have to guess at the correct syntax (and usually it's ugly).

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

I don't know what to say... This entire paragraph makes no sense at all.
You're saying that "all languages" use a single syntax for if/then/else?
And you're trying to hint that somehow this increases productivity for
"all languages"?

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

No, you're dead wrong in every way. HCI is what this group is about.
Computer languages are a pure form of HCI.

You don't seem to want a working model (like Cat); you want a complete
logical derivation first, a "proof" that the proposal is better. I'm
trying to tell you that HCI is more complicated than you think it is;
there's no logical model around which a proof could be constructed.

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

I'd love that. You'll need to start by being clear about what you want to do.

> == Chris Glur.

-Wm