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

chris glur wrote:
> William Tanksley wrote:
> >Lojban is a constructed language that was designed "entirely"
> >from scratch in order to be easily learned and unambiguous. One
> >of the design choices was to make it easily parsed, and
> >the implementor chose to make the language defined by an
> >LL grammar. The result has been catastrophic: in spite of a
> >reasonably strong community, not one person has EVER achieved
> >fluency in lojban (according to the community-acclaimed best
> >speaker).
> ! This amazes and disturbs me ! OTOH, let's not confuse short
> term [30 years] populatity with technical excellence.

I have to admit -- as someone pointed out -- that my conclusion was
ill-supported (although possible). A better conclusion would be that
although Lojban was designed to be highly learnable, usable, and
unambiguous, in practice it hasn't been. One possible reason for this is
that the designer didn't know enough about the problems to be able to do
the design work.

The reason that this explanation seems possible to me is that the
designer wasn't a linguist, and even modern linguists and cognitive
scientists don't generally claim to know enough to achieve Lojban's
goals. (In modern terms, some of those goals might be stated as: a
language that's naturally speakable, yet is capable of sufficient
precision to be used for computer programming when used by a trained
programmer.)

Because we can't solve the general problem yet, and we admit that it
seems like a desirable problem to solve, we pick at subsets of the
problem. For example, we look at how specific restrictions on languages
(e.g. disallowing mutable variables, or composing functions rather than
applying functions to data) allow us to reason about the resulting
sublanguages more efficiently.

> I meant that we should build on
> the existing human/sociatal assets, eg.:
> * use already existing knowledge - call a 'tail' a "tail" and not
>    a "cdr"
> * work left to right, top to bottom:
>   '7 -> counter' is better than counter := 7
> * iteration is more 'natural' than recursion - all things being
>    equal ..........

Sure, that's fine; but the existing social knowledge isn't enough to
solve the problems we know how to characterize. There's strong incentive
to develop NEW social knowledge. That's largely what we're doing in this
group; concatenative languages have been poorly researched due to a
shoddy theoretical basis. We're trying to firm up the theoretical basis
so that research can be done on them. Once that research is done, it'll
be possible to determine whether concatenative languages improve the
situation. In the meantime, all we have is the gut feelings of Forth,
Postscript, Factor, and Joy programmers that there's something elegant
and useful about these languages.

what I'm trying to say, I guess, is that contrary to your requests
there's a need and a place for both practical and theoretical work
before we're able to say what a maximally nice language is. Your
writings imply that there's some way to just MAKE the nicest language,
as though all that knowledge was somehow just THERE.

> Yes but as stated the compiler cost is irrelevant compared to human
> effort cost - these days.  I'd rather pay the compiler to push &
> pop, than do it myself.

There are things that the author of a program will always do better than
a compiler. One of them is express intention.

> >syntax is as important to me as it is to the next guy, but other
> >characteristics of PLs matter more, chief among them being how
> >many new concepts i'm required to master before i can use the
> >language well.
> Yes! And menu/prompts help tremendously too ?

Menus use the fact that's it's easier to recognise something than it is
to recall it. Thus, when you have a large number of possibilities, it's
often easier to pick them from a list than it is to just type them out.
On the other hand, when your number of possibilities gets VERY large,
you can no longer READ the list; there has to be a way to "clump" the
data in order to have any hope of recognising OR recalling. And that
becomes a _very_ hard problem.

> Perhaps cat-languages enable easy moving/transforming the
> data through the process; like:
> IF ( (NextToken(MaxOf(BlueOnes) - NextToken(AveOf(RedOnes) < 5) THEN
>    becomes [not in postfix form]:-
> BlueOnes > MaxOf > NextToken ; RedOnes > AveOf > NextToken ...etc?
> It seems that you MUST think of 'temporarily storeing/stacking'
> NextToken(MaxOf(BlueOnes); so you can't escape stack-shuffling.

Sure you can! You just define a combinator that lets you make that kind
of distinction:

[{blue-one? [max-of]} {red-one? [avg-of]} aggregate-by] each-token

There you go -- reusable code for next time you're processing a group of
tokens, or for next time you're performing different aggregations on
multiple items.

> With procedural languages, you 'leave NextToken(MaxOf(BlueOnes)'
> in the source code, and the compiler does the stack-shuffling.

Do you see any stack shuffling in the concatenative code above?

Stack shuffling IS a problem. I suspect that it's actually a symptom of
a deeper problem, really; I think most of the time when you're doing
stack shuffling your code isn't reflecting your intention. The problem
is that we don't understand concatenative languages well enough yet to
be able to get rid of stack shuffling in all cases.

Maybe it's impossible. If so, maybe concatenative languages are a bad
idea, or perhaps local variables are (in general) a good thing. On the
other hand, perhaps there's some way we can do more. Factor gives me
hope for this -- they've recently discovered the cleave/spread/apply
combinators, which replaced almost all stack shuffles and local
variables in their library with code that appears to express intention
more directly.

Is that the best we can do? I hope not!!! But it's better than we were
doing before.

Chris, do you have any suggestions for research? I'm enjoying the
conversation, but I don't see it going anywhere.

> == Chris Glur.

-Wm