# Advantages of cat, joy ..?

## chris glur — 2009-02-16 13:17:50

    Since I started reading this mail-list all I've got is:

    'look ma I can wear my cap backwards;

    and you can turn it inside out;

    and if you turn it to the right and march north,

      it points in the direction, where the sun rises,

     which will tell you approximately where the sun sets'.

    So what ?

    What the point of it all ?!

    What I've been hoping for is pointers to increased

    productivety, based on:

    * we naturally want to be more productive;

     i.e. acheive more output with less effort;

    * computer programming is constrained by human

      attributes, eg.

    A. the 7+-2 rule, and

    B. 'recognition is easier than remembering';

    * etc. - this is psychology, not compt-science.

    Which leads to facilities which aid productivety eg.:

    * any thing that helps reduced the mental clutter,

     by chunking several items together into a single

    idea: subroutines, data structures ...OOP.

    * since we've spent a life time reading, lets

      use this honed skill and have mnemonic IDs.

     Although java's verbosity can overwhelm.

    The coming productivety increase I'd

    hoped for is formal methods, whereby

    an 'algebra' would allow sequences of

    statements/expression to be reduced to

    simpler [in size or understandability]

    form.  Imagine what magic Pythagoras is

    if you've got a W * H tunnel  and you need

    to know if a L wide strip can pass through it.

    To concretize my criticism with a real example,

    I recently investigated gforth > OOF, and

    reached the following 'feeling' [obviously it's

    subjective and fuzzy]:-

    * perhaps the mental clutter can be reduced

    once a suitable class heirarchy is built ?

    * the gap between forth's syntax and natural

      language [which we've been practicing all

     our lives] reduces productivety.

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

    * forth is good for bootstrapping a new make of

      CPU, but not much else - ito productivety.

    IMO forth is cute and fascinating but not

    productive.

    AFAIK the 'joy web site', mentions the word

    "algebra", but doesn't show any complete

    solution of a problem, eg. "the following

    form <X> can be transformed the <Y> which

    is seen to prove P; which solves problem Q".

    Top down design means define the problem

    and show how it's solved.

    Is there any useful contribution to increased

    productivety yet,  in knowing that language

    X can be viewed as a sequence of

    tranformations of stacks ?

    == Chris Glur.

## John Nowak — 2009-02-16 13:49:03

    On Feb 16, 2009, at 8:17 AM, chris glur wrote:

     > What the point of it all ?!

     1. The formal methods you mention are certainly a big element. The

    pointfree, concatenative nature of the code makes it very easily to

    manipulate programs. This property has not been taken advantage of yet.

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

    3. First-order stack-based languages are well-suited to a graphical

    representation once you apply a type discipline. This would mesh very

    well with a linear implementation.

    4. Concatenative languages can be considerably simpler than their

    typical applicative counterparts. Throw out all your binding forms,

    precedence rules, scoping rules, etc.

    Other people undoubtedly have other interests.

     > I recently investigated gforth

     Gforth probably isn't what you want to be looking at. Factor is a

    better bet, although it isn't currently capitalizing on the formal

    methods you're talking about.

     > [advantages of] knowing that language X can be viewed as a sequence

    > of [transformations] of stacks?

     It certainly makes it easy to move state through your program. This is

    what enables the linear implementation I mentioned previously.

    Similarly, it could make dealing with uniqueness types quite

    comfortable.

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

    - John

## Christopher Diggins — 2009-02-16 14:57:55

    On Mon, Feb 16, 2009 at 8:17 AM, chris glur <crglur@...> wrote:

     > Since I started reading this mail-list all I've got is:

    >

    > 'look ma I can wear my cap backwards;

    > and you can turn it inside out;

    > and if you turn it to the right and march north,

    > it points in the direction, where the sun rises,

    > which will tell you approximately where the sun sets'.

    > So what ?

    > What the point of it all ?!

     No point at all. Now unsubscribe and leave us alone.

    William, can you do something about this guy?

    - Christopher Diggins

## Stevan Apter — 2009-02-16 15:14:58

    i think chris is asking good questions.  at some point i thought

    i might be turning into the concatenative languages productivity bore,

    but close association over the years with language development in the

    context of large financial institutions has convinced me that design

    ideas need to be constantly tested against real-world application

    problems.  like chris, i look for new ideas to yield productivity gains.

    joy and kin deliver some impressive code simplification in the small,

    but i keep wondering, "does it scale?"  so far, to my mind, the jury

    is still out.

     ----- Original Message -----

    From: "Christopher Diggins" <cdiggins@...>

    To: <concatenative@yahoogroups.com>

    Sent: Monday, February 16, 2009 9:57 AM

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

    > On Mon, Feb 16, 2009 at 8:17 AM, chris glur <crglur@...> wrote:

    >> Since I started reading this mail-list all I've got is:

    >>

    >> 'look ma I can wear my cap backwards;

    >> and you can turn it inside out;

    >> and if you turn it to the right and march north,

    >> it points in the direction, where the sun rises,

    >> which will tell you approximately where the sun sets'.

    >> So what ?

    >> What the point of it all ?!

    >

    > No point at all. Now unsubscribe and leave us alone.

    > William, can you do something about this guy?

    >

    > - Christopher Diggins

    >

## William Tanksley — 2009-02-16 15:24:55

    Christopher Diggins wrote:

     > chris glur <crglur@...> wrote:

    > > Since I started reading this mail-list all I've got is:

    > > 'look ma I can wear my cap backwards;

    > > and you can turn it inside out;

    > > and if you turn it to the right and march north,

    > > it points in the direction, where the sun rises,

    > > which will tell you approximately where the sun sets'.

    > > So what ?

    > > What the point of it all ?!

    > No point at all. Now unsubscribe and leave us alone.

    > William, can you do something about this guy?

     I can, but I won't; being "annoying" is a benefit if it reminds me to

    stop improving my hyper-theoretical "01" language and spend a few

    minutes thinking about how to make some concatenative language work a

    bit smoother.

     > - Christopher Diggins

     -Wm

## Stevan Apter — 2009-02-16 15:27:32

    ----- Original Message -----

    From: "William Tanksley" <wtanksleyjr@...>

    > I can, but I won't; being "annoying" is a benefit if it reminds me to

    > stop improving my hyper-theoretical "01" language

    no!  :)

## Stevan Apter — 2009-02-16 15:28:47

    ----- Original Message -----

    From: "Stevan Apter" <sa@...>

    To: <concatenative@yahoogroups.com>

    Sent: Monday, February 16, 2009 10:27 AM

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

    >

    > ----- Original Message -----

    > From: "William Tanksley" <wtanksleyjr@...>

    >

    >> I can, but I won't; being "annoying" is a benefit if it reminds me to

    >> stop improving my hyper-theoretical "01" language

    >

    > no!  :)

    seriously, 01/10 is imho the most interesting theoretical result to

    emerge on this mailing list since its inception.

## John Nowak — 2009-02-16 15:52:30

    On Feb 16, 2009, at 10:28 AM, Stevan Apter wrote:

     > seriously, 01/10 is imho the most interesting theoretical result to

    > emerge on this mailing list since its inception.

     Why don't I know anything about it? Any information on the web? Did I

    somehow just blank on the whole thing?

    - John

## Stevan Apter — 2009-02-16 16:00:35

    there's a long thread from a couple of years ago.  maybe search

    the archive for "01"?

     ----- Original Message -----

    From: "John Nowak" <john@...>

    To: <concatenative@yahoogroups.com>

    Sent: Monday, February 16, 2009 10:52 AM

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

    >

    > On Feb 16, 2009, at 10:28 AM, Stevan Apter wrote:

    >

    >> seriously, 01/10 is imho the most interesting theoretical result to

    >> emerge on this mailing list since its inception.

    >

    > Why don't I know anything about it? Any information on the web? Did I

    > somehow just blank on the whole thing?

    >

    > - John

    >

## Stevan Apter — 2009-02-16 16:03:40

    a k implementation of 10:

    http://nsl.com/k/10.k

    no examples.

     ----- Original Message -----

    From: "John Nowak" <john@...>

    To: <concatenative@yahoogroups.com>

    Sent: Monday, February 16, 2009 10:52 AM

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

    >

    > On Feb 16, 2009, at 10:28 AM, Stevan Apter wrote:

    >

    >> seriously, 01/10 is imho the most interesting theoretical result to

    >> emerge on this mailing list since its inception.

    >

    > Why don't I know anything about it? Any information on the web? Did I

    > somehow just blank on the whole thing?

    >

    > - John

    >

## William Tanksley — 2009-02-16 17:21:42

    chris glur wrote:

     > Since I started reading this mail-list all I've got is:

    > 'look ma I can wear my cap backwards;

    > and you can turn it inside out;

    > and if you turn it to the right and march north,

    >   it points in the direction, where the sun rises,

    >  which will tell you approximately where the sun sets'.

    > So what ?

    > What the point of it all ?!

     I know you're joking, but you've got to admit that this hardly

    characterizes any discussion we've ever had. As far as I can tell,

    you're saying that we've been rejoicing over the sheer _difference_

    between concatenative languages and applicative languages, without

    caring for what concrete benefits the differences bring us; and that's

    just not true.

     > What I've been hoping for is pointers to increased

    > productivety, based on

    > [...] psychology, not compt-science.

     An excellent desire! But you're either desiring enormous luck, or

    putting the cart before the horse.

    I'd love to have a human-factors expert look at concatenative languages

    to see what can come of it. Such an expert would, of course, FIRST have

    to understand concatenativity, and that would require either an expert

    who loved concatenative languages for some reason of their own, OR an

    expert who is taught about concatenativity by people who'd made it their

    own study.

    In the first case, we'd be extremely lucky to find such an expert; such

    a person would have to be an specialist in their own field, and yet

    still find a completely different field interesting (most of the time

    high skill in a specialty means you're more interested in the

    specialty).

    In the second case, we (the people interested in concatenativity) have

    to "suffer" without expert human-factors help until we understand the

    features of concatenativity well enough to explain them to a person

    who's not innately interested in concatenativity.

    So, we need to be either lucky in finding an expert who likes raw

    concatenativity; or persevere in understanding enough until we can

    justify ourselves to a human-factors specialist.

    I don't see a shortcut.

    On the other hand, I do see a huge benefit to what you're doing:

    emphasizing the importance of human factors, so that we can direct our

    efforts as a group. Surely if we make an effort to explore human factors

    we'll at _least_ be able to attract a human factors expert more easily

    (because we're _discussing_ that specialty, even if we don't

    accidentally make a useful discovery).

     > Which leads to facilities which aid productivety eg.:

    > * any thing that helps reduced the mental clutter,

    >  by chunking several items together into a single

    > idea: subroutines, data structures ...OOP.

    > * since we've spent a life time reading, lets

    >   use this honed skill and have mnemonic IDs.

    >  Although java's verbosity can overwhelm.

     Mnemonic IDs are a great idea, but we have more power than that

    available to us. Any language can have mnemonic IDs. Of course, this is

    what you're telling us to look for -- what human-factors things can

    concatenative languages do better?

    Let me list a few things that concatenative languages do better because

    of their concatenativity.

    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.

    Third, concatenative languages are easier to compress in a

    human-understandable way. The most natural way to compress data is to

    extract commonly-appearing sequences, give them names, and substitute

    the names for all the occurrences of the sequences (in computer science,

    a common algorithm for this was charecterized by Lempel and Ziv, see

    <http://en.wikipedia.org/wiki/LZ77_and_LZ78>). This process cannot

    easily be done in a language that uses IDs for data.

    With all that said, I have to hasten to contradict an easy error: I'm

    not claiming that these advantages prove that concatenative languages

    are better than applicative ones. Applicative languages also have

    unique, distinctive advantages in human factors. Part of our job is to

    look for ways in which concatenative languages are _worse_, and to see

    if we can engineer a way to make up for that potential problem.

    For example, applicative languages make it easy to implement a very

    limited amount of parallel control flow: the parameters of a function

    are evaluated independently, so in theory they could be evaluated in

    parallel. One possible solution is to invent control structures that are

    explicitly parallel; indeed, this has been done for at least one very

    interesting language, Factor.

     > The coming productivety increase I'd

    > hoped for is formal methods, whereby

    > an 'algebra' would allow sequences of

    > statements/expression to be reduced to

    > simpler [in size or understandability]

    > form.  Imagine what magic Pythagoras is

    > if you've got a W * H tunnel  and you need

    > to know if a L wide strip can pass through it.

     Formal methods take a lot of work, but some of our natives are putting

    that work in. You know about Cat, of course, and Nowak's old 5th project

    has done even more for the static analysis of concatenative programs.

    Meanwhile, Factor is an outstanding concatenative language that's built

    for practical use -- and part of that practical use is built on

    established formal methods. Factor's optimizer is extremely powerful and

    flexible, and if you understand how to write code with static stack

    effects, you can help it generate much closer to optimal native code.

    This makes understanding formal methods really pay off even to

    programmers who otherwise wouldn't be interested.

     > To concretize my criticism with a real example,

    > I recently investigated gforth > OOF, and

    > reached the following 'feeling' [obviously it's

    > subjective and fuzzy]:-

     I'm not sure that gforth+OOF is a sensible place to start. GForth has

    three OO extensions bundled with it, and none of them have a library. It

    makes more sense to look at a language whose OO extensions have been

    more developed and used. Factor is the obvious choice for this.

     > * the gap between forth's syntax and natural

    >   language [which we've been practicing all

    >  our lives] reduces productivety.

     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.

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

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

     > * forth is good for bootstrapping a new make of

    >   CPU, but not much else - ito productivety.

     I don't know what "ito" means.

    This observation cannot be accurately reached by someone who's merely

    looked at a oof.fs packages. Either you've done a *lot* more work in

    Forth, or you're just guessing. Care to specify which one?

     > IMO forth is cute and fascinating but not

    > productive.

     There are actually a decent number of Forth programmers who'd disagree

    with that. And to expand this out to more concatenative languages, I

    think it's pretty clear that Factor proves that concatenative languages

    are both fascinating *and* productive. Compare the growth and

    development of any other language... Scala and Clojure don't even come

    close; arc has some similarities, but took SO much longer to start up

    and seems to have stalled now.

     > AFAIK the 'joy web site', mentions the word

    > "algebra", but doesn't show any complete

    > solution of a problem, eg. "the following

    > form <X> can be transformed the <Y> which

    > is seen to prove P; which solves problem Q".

     The Joy website contributed immensely to the increase of formal

    knowledge. Forth contributed probably the most of any language to the

    increase of practical language. You're asking for someone who put the

    two ideas together; right now only Factor comes closest to giving what

    you seem to be looking for, but they don't emphasise very strongly

    tracing back *every* practical improvement to its theoretical roots.

    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.

     > Is there any useful contribution to increased

    > productivety yet,  in knowing that language

    > X can be viewed as a sequence of

    > tranformations of stacks ?

     Sure.

    The interesting thing is that Forth achieved this without even trying --

    Chuck Moore almost certainly never thought of Forth this way, but he and

    Forth programmers benefit from how the theoretical purity and

    referential transparency of concatenative languages can be mixed with

    state mutation and other non-functional behavior without losing many of

    the theoretical benefits.

    Postscript also achieved this without trying -- it's almost certainly

    the most-used programming language in the world, thanks to all the

    millions of printer drivers automatically generating "custom" Postscript

    programs to be run on PS laser printers, and that wouldn't be possible

    without the way concatenative languages allow you to produce a valid

    program simply by juxtaposing two valid programs. It makes automatic

    program generation simple.

    Is Factor benefiting from the fact that it's concatenative? That's hard

    for me to answer; Factor has a superb development community, so perhaps

    that's the real reason... But Factor is undeniably strongly

    concatenative, so at least this proves that concatenativity isn't

    actively hindering their work.

     > == Chris Glur.

     -Wm

## William Tanksley — 2009-02-16 17:31:23

    Stevan Apter wrote:

     > i think chris is asking good questions. [...]

    > joy and kin deliver some impressive code simplification in the small,

    > but i keep wondering, "does it scale?"  so far, to my mind, the jury

    > is still out.

     I think the only way to test this is to actually perform the scaling,

    and observe where it falls short. Otherwise you run the risk of assuming

    that the lessons-learned from other styles of programming apply strictly

    to this one.

    Factor is one attempt to do this in a public environment. Its library is

    large, well tested, and constantly being updated to match the currently

    useful idioms. Slava doesn't allow a library module to remain long in an

    "obsolete" style; such modules get deprecated until they're rewritten.

    -Wm

## John Nowak — 2009-02-16 17:44:30

    On Feb 16, 2009, at 12:21 PM, William Tanksley wrote:

     > For example, applicative languages make it easy to implement a very

    > limited amount of parallel control flow: the parameters of a function

    > are evaluated independently, so in theory they could be evaluated in

    > parallel. One possible solution is to invent control structures that

    > are

    > explicitly parallel; indeed, this has been done for at least one very

    > interesting language, Factor.

     Representing stack-based code in a graphical manner exposes

    essentially all of the parallelism you'd get in an applicative

    language. There are areas where applicatively languages are better

    (primarily implementing existing algorithms and math equations), but I

    don't think parallelism is one of them. Well, at least not in any way

    that matters; if you're talking about implicit parallelism, your

    compiler is going to be figuring it out for you anyway.

    Talking about "human factors", I really think an interface that would

    draw out your data flow in real-time as you coded (which is trivial to

    do in a flat language), complete with type labels, etc, would make a

    huge difference. You'd name the inputs and outputs to your function as

    you do in Forth/Factor, but you could think about these labels as

    names for "ports". The diagram would represent a push-based, strictly-

    downward dataflow program. As soon as I get the time, I'll try and put

    something together; I have the unfortunate obligation of working to

    feed myself lately. The idea would be to make concatenative

    programming accessible to artists and incorporate some functional

    reactive programming ideas.

    - John

## Joe Bowbeer — 2009-02-16 17:50:52

    Chris,

    While I think the overwhelming majority on this list are more open to

    self-examination and criticism than "sod off and leave us alone" (only

    slightly paraphrased), I've also come to the conclusion that the

    productivity and effectiveness of concatenative languages in the everyday

    world of programming -- as we programmers experience programming in our

    everyday lives -- is not a genuine driving interest of those on this list.

    What drives discussion on this list is a shared affection for these simple,

    puzzling, terse, powerful, (and so on...), and almost completely impractical

    languages :)

    Joe

     On Mon, Feb 16, 2009 at 5:17 AM, chris glur wrote:

    > Since I started reading this mail-list all I've got is:

    > 'look ma I can wear my cap backwards;

    > and you can turn it inside out;

    > and if you turn it to the right and march north,

    >  it points in the direction, where the sun rises,

    >  which will tell you approximately where the sun sets'.

    > So what ?

    > What the point of it all ?!

    >

    > What I've been hoping for is pointers to increased

    > productivety, based on:

    > * we naturally want to be more productive;

    >  i.e. acheive more output with less effort;

    > * computer programming is constrained by human

    >  attributes, eg.

    > A. the 7+-2 rule, and

    > B. 'recognition is easier than remembering';

    > * etc. - this is psychology, not compt-science.

    >

    > Which leads to facilities which aid productivety eg.:

    > * any thing that helps reduced the mental clutter,

    >  by chunking several items together into a single

    > idea: subroutines, data structures ...OOP.

    > * since we've spent a life time reading, lets

    >  use this honed skill and have mnemonic IDs.

    >  Although java's verbosity can overwhelm.

    >

    > The coming productivety increase I'd

    > hoped for is formal methods, whereby

    > an 'algebra' would allow sequences of

    > statements/expression to be reduced to

    > simpler [in size or understandability]

    > form.  Imagine what magic Pythagoras is

    > if you've got a W * H tunnel  and you need

    > to know if a L wide strip can pass through it.

    >

    > To concretize my criticism with a real example,

    > I recently investigated gforth > OOF, and

    > reached the following 'feeling' [obviously it's

    > subjective and fuzzy]:-

    > * perhaps the mental clutter can be reduced

    > once a suitable class heirarchy is built ?

    > * the gap between forth's syntax and natural

    >  language [which we've been practicing all

    >  our lives] reduces productivety.

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

    > * forth is good for bootstrapping a new make of

    >  CPU, but not much else - ito productivety.

    >

    > IMO forth is cute and fascinating but not

    > productive.

    >

    > AFAIK the 'joy web site', mentions the word

    > "algebra", but doesn't show any complete

    > solution of a problem, eg. "the following

    > form <X> can be transformed the <Y> which

    > is seen to prove P; which solves problem Q".

    >

    > Top down design means define the problem

    > and show how it's solved.

    >

    > Is there any useful contribution to increased

    > productivety yet,  in knowing that language

    > X can be viewed as a sequence of

    > tranformations of stacks ?

    >

    > == Chris Glur.

    >

    [Non-text portions of this message have been removed]

## William Tanksley — 2009-02-16 18:40:19

    Joe Bowbeer wrote:

     > I've also come to the conclusion that the

    > productivity and effectiveness of concatenative languages in the everyday

    > world of programming -- as we programmers experience programming in our

    > everyday lives -- is not a genuine driving interest of those on this list.

     That's not true for myself (although you wouldn't know it from anything

    online), and it's definitely not true for the Factor contributors on

    this list.

     > What drives discussion on this list is a shared affection for these simple,

    > puzzling, terse, powerful, (and so on...), and almost completely impractical

    > languages :)

     That's true if by "these ... impractical languages" you're not referring

    to all concatenative languages, but rather only the experimental

    languages we spend much of our time discussing here.

    Hint: if you want to get practical, you'll also have to get specific.

    Nobody's ever done anything practical in "a concatenative language";

    rather, we work in "Forth", or "Factor", or even "Joy". If you want to

    get practical, you have to do the same; and once you choose which one,

    this newsgroup isn't the most focussed place to discuss anymore, so

    you'll probably start posting to comp.lang.forth, or the colorforth

    newsgroup, or the Factor discussion list, or wherever your language is

    most topically discussed.

    Don't get me wrong; we welcome all the concatenative languages here, but

    there's tons of good reasons to carry on the real technical discussions

    where they can be more focussed, and seen by people who are truly

    experts, and NOT seen by people who aren't using that language at all.

    I'm actually not criticising your post, by the way; I think it's not an

    unreasonable characterization of the group, and I don't mind it. Perhaps

    someday we'll be known for our legendary advances in integrating

    technology and human factors; for now I guess we're just trying to

    figure this whole new thing out.

     > Joe

     -Wm

## Daniel Ehrenberg — 2009-02-16 19:13:54

    If you're looking for something useful, this list probably isn't the

    right place to go. Most of the discussions are about theory that

    doesn't get anywhere, and most of the people who post don't actively

    program in concatenative languages; they just implement interpreters

    for them.

    I find that one particular concatenative language, Factor, makes me

    personally very productive. Some of the advantages come from the fact

    that Factor is concatenative, and some come from the great

    organization of the Factor libraries and class hierarchy. From being

    concatenative, we get a nice, clean point-free data flow (cleaner than

    Forth because some combinators help with data flow) and the ability to

    factor things out very easily. It's also nice to have a simple,

    easy-to-understand left-to-right evaluation order.

    As far as Factor-specific features go, Factor is a dynamically typed,

    garbage collected language with object oriented features and a

    well-developed set of libraries for practical things like HTTP, SMTP,

    Unicode and XML. Factor also shares some particular advantages with

    Forth, eg extensible syntax with a simple parser. (If you don't like

    Forth syntax, though, I guess you won't like Factor syntax.)

    As far as knowing the "algebra" of concatenative languages goes, it's

    something interesting but I don't find it useful in everyday

    programming. Stack code is pretty easy to analyze automatically (which

    can be useful for certain macros, like a pattern matching library I

    wrote) and to generate (as Factor's Lisp-like macros do, sometimes

    with fairly complicated data flow).

    Dan

     On Mon, Feb 16, 2009 at 7:17 AM, chris glur <crglur@...> wrote:

    > Since I started reading this mail-list all I've got is:

    > 'look ma I can wear my cap backwards;

    > and you can turn it inside out;

    > and if you turn it to the right and march north,

    > it points in the direction, where the sun rises,

    > which will tell you approximately where the sun sets'.

    > So what ?

    > What the point of it all ?!

    >

    > What I've been hoping for is pointers to increased

    > productivety, based on:

    > * we naturally want to be more productive;

    > i.e. acheive more output with less effort;

    > * computer programming is constrained by human

    > attributes, eg.

    > A. the 7+-2 rule, and

    > B. 'recognition is easier than remembering';

    > * etc. - this is psychology, not compt-science.

    >

    > Which leads to facilities which aid productivety eg.:

    > * any thing that helps reduced the mental clutter,

    > by chunking several items together into a single

    > idea: subroutines, data structures ...OOP.

    > * since we've spent a life time reading, lets

    > use this honed skill and have mnemonic IDs.

    > Although java's verbosity can overwhelm.

    >

    > The coming productivety increase I'd

    > hoped for is formal methods, whereby

    > an 'algebra' would allow sequences of

    > statements/expression to be reduced to

    > simpler [in size or understandability]

    > form. Imagine what magic Pythagoras is

    > if you've got a W * H tunnel and you need

    > to know if a L wide strip can pass through it.

    >

    > To concretize my criticism with a real example,

    > I recently investigated gforth > OOF, and

    > reached the following 'feeling' [obviously it's

    > subjective and fuzzy]:-

    > * perhaps the mental clutter can be reduced

    > once a suitable class heirarchy is built ?

    > * the gap between forth's syntax and natural

    > language [which we've been practicing all

    > our lives] reduces productivety.

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

    > * forth is good for bootstrapping a new make of

    > CPU, but not much else - ito productivety.

    >

    > IMO forth is cute and fascinating but not

    > productive.

    >

    > AFAIK the 'joy web site', mentions the word

    > "algebra", but doesn't show any complete

    > solution of a problem, eg. "the following

    > form <X> can be transformed the <Y> which

    > is seen to prove P; which solves problem Q".

    >

    > Top down design means define the problem

    > and show how it's solved.

    >

    > Is there any useful contribution to increased

    > productivety yet, in knowing that language

    > X can be viewed as a sequence of

    > tranformations of stacks ?

    >

    > == Chris Glur.

    >

    >

## William Tanksley — 2009-02-16 19:50:23

    John Nowak wrote:

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

     You are not the only one; I've been interested in that since I read it,

    way back in the mists of memory.

     > 3. First-order stack-based languages are well-suited to a graphical

    > representation once you apply a type discipline. This would mesh very

    > well with a linear implementation.

     I agree, although "type discipline" isn't as strictly important as

    static stack effects.

    It would be very interesting, also, to consider a few different ideas:

    1. A graphical architectural mode for a concatenative language: would

    answer questions about which modules can be used by which other ones,

    which modules are sources/sinks/transformers, for which other ones...

    Can analyze source code for violations, or produce an architectural

    diagram from source code.

    2. A graphical presentation for a concatenative language: read in source

    code, show various diagrams.

    3. A graphical augmentation for a concatenative language: while editing

    source code, show arrows that point back to where data comes from and

    forward to where it's being consumed. (Can Emacs do this kind of thing?)

    #3 would be especially useful while editing normal text, I would think.

    One wouldn't use that in an applicative language (where simply

    colorcoding the variable names is sufficient), but it'd be nice in an

    applicative language.

    #2 could be a different way to program, and could help with security

    analysis.

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

     That's good! I'd say that it would be good exercise to always start and

    end without variables... So that little derivation could be written:

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

    (I'm not assuming commutativity of multiplication here.)

    As for commutativity...

     swap + == +

    Well, that's TOO easy.

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

     That works well for applicative statements, but not so well for programs or expressions.

     > - John

     -Wm

## William Tanksley — 2009-02-16 19:57:51

    John Nowak wrote:

     > Stevan Apter wrote:

    > > seriously, 01/10 is imho the most interesting theoretical result to

    > > emerge on this mailing list since its inception.

    > Why don't I know anything about it? Any information on the web? Did I

    > somehow just blank on the whole thing?

     Your mind probably mercifully blanked the entire episode. Go to our

    mailing list archive (http://groups.yahoo.com/group/concatenative is the

    yahoo-approved one, we're also archived by some list aggregators) and

    search for "01".

    One place to start would be in the thread around:

    http://tech.groups.yahoo.com/group/concatenative/message/3209

    This message is especially important because it links to Kerby's brute

    force searcher, which is still the most reliable way to test theories

    about 01-based languages. I've spent some time working on a fancier

    searcher/language-lab under the name of "tworing" (currently includes a

    pretty fancy search pruning algorithm); I stopped after I lost some work

    in a crash, and haven't resumed.

     > - John

     -Wm

## William Tanksley — 2009-02-16 20:59:31

    John Nowak wrote:

     > William Tanksley wrote:

    > > For example, applicative languages make it easy to implement a very

    > > limited amount of parallel control flow: the parameters of a function

    > > are evaluated independently, so in theory they could be evaluated in

    > > parallel. One possible solution is to invent control structures that

    > > are

    > > explicitly parallel; indeed, this has been done for at least one very

    > > interesting language, Factor.

    > Representing stack-based code in a graphical manner exposes

    > essentially all of the parallelism you'd get in an applicative

    > language.

     That's a fair statement; actually, of course, graphical representation

    gives you a LOT more control over parallelism than an applicative

    language alone can give. The same is true for explicitly parallel

    control structures.

     > There are areas where applicatively languages are better

    > (primarily implementing existing algorithms and math equations),

     Algorithms are no challenge for concatenative languages. Equations are

    more of a challenge, since there's a bigger translation step most of the

    time. (However, I did actually use a concatenative notation in one math

    class -- sorry, I forget the author, and the title was "Modern Algebra",

    which tells Google nothing.)

     >  but I

    > don't think parallelism is one of them. Well, at least not in any way

    > that matters; if you're talking about implicit parallelism, your

    > compiler is going to be figuring it out for you anyway.

     You're right. The parallelism in the arguments of functions is almost

    always accidental; a compiler that took advantage of it would probably

    break many programs.

     > Talking about "human factors", I really think an interface that would

    > draw out your data flow in real-time as you coded (which is trivial to

    > do in a flat language), complete with type labels, etc, would make a

    > huge difference. You'd name the inputs and outputs to your function as

    > you do in Forth/Factor, but you could think about these labels as

    > names for "ports". The diagram would represent a push-based, strictly-

    > downward dataflow program. As soon as I get the time, I'll try and put

    > something together; I have the unfortunate obligation of working to

    > feed myself lately. The idea would be to make concatenative

    > programming accessible to artists and incorporate some functional

    > reactive programming ideas.

     Factor has a nice emacs mode; I wonder if something like that could be

    coded in Emacs (which would allow it to use the very nice FUEL

    Factor-Emacs integration)?

    I see:

    http://www.xemacs.org/Documentation/21.5/html/xemacs-faq_5.html#SEC165

    ...which says that Emacs 19 doesn't support background images, but

    XEmacs does. A generated background pixmap would seem to be a reasonable

    way to get that kind of diagram... Not perfect, but a decent proof of

    concept.

     > - John

     -Wm

## chris glur — 2009-02-16 21:44:05

    >you can express the distributivity of

    >multiplication nicely without the need for infix operators:

     Which via A -> B -> C leads to increased productivety,

    either via faster initial building, or easier maintenance or increased

    reliability.

    What are the [assumed ?] A,B,C.

    I feel like a child trying to find out where babies

    come from, who's being given the run-around.

    ===re. unsubscribing critics:-

    Admitting that it's just fun, mentally stimulating

    or might lead somewhere is completely legitimate.

    Apparently origami has many followers too ?

    Muzzeling criticism is ....well ...gun-slinging ?

    == Chris Glur.

     On 2/16/09, Christopher Diggins <cdiggins@...> wrote:

    > On Mon, Feb 16, 2009 at 8:17 AM, chris glur <crglur@...> wrote:

    >> Since I started reading this mail-list all I've got is:

    >>

    >> 'look ma I can wear my cap backwards;

    >> and you can turn it inside out;

    >> and if you turn it to the right and march north,

    >> it points in the direction, where the sun rises,

    >> which will tell you approximately where the sun sets'.

    >> So what ?

    >> What the point of it all ?!

    >

    > No point at all. Now unsubscribe and leave us alone.

    > William, can you do something about this guy?

    >

    > - Christopher Diggins

    >

## William Tanksley — 2009-02-16 22:11:46

    chris glur wrote:

     > >you can express the distributivity of

    > >multiplication nicely without the need for infix operators:

    > Which via A -> B -> C leads to increased productivety,

    > either via faster initial building, or easier maintenance or increased

    > reliability.

     Plotting A->B->C won't get you anywhere if you're talking about human

    factors. You have to build an experiment and demonstrate by doing. There

    are too many factors to be able to make a-priori claims.

    I've pointed out Factor; you should head on over and see what you think.

    Come back and tell us! They've done all the hard work; you don't have to

    logically justify it, just enjoy it.

     > What are the [assumed ?] A,B,C.

     No need for them. The purpose was just what he said -- expressiveness.

    You can also express multiplicative distributivity easily without using

    variables, as I showed, which gives additional advantages.

    There are a lot of ways to write code. Every single one fails in the

    majority of situations, and most of them succeed in different

    situations. Knowing more ways of expressing yourself will lead to more

    of your code being expressive of your intent.

    One of Factor's biggest innovations is how it replaces shuffle words

    with the new dataflow combinators. (See

    http://factor-language.blogspot.com/2008/12/prevalence-of-shuffle-words-and.html for a telescopic view of a microscopic realm.) Dataflow combinators, when used correctly, allow you to state explicitly which quotations operate on which data, rather than having to juggle data out of the way so that the desired functions can access it. The difference is not that dataflow combinators are simpler than stack shuffles; the difference is that often they _express_ what you were actually intending to write. You didn't actually WANT to move the top element on the stack two down; you actually wanted to perform some action on the lower element and then some other action on the next two elements.

     > I feel like a child trying to find out where babies

    > come from, who's being given the run-around.

     Actually, you're more like a child trying to find out how Santa Claus

    manages to fit down the chimney. You're asking the wrong question, but

    you're nonetheless on the right path to find the truth.

    One difference from my Santa-Claus metaphor: none of us know the answer.

    We can't feed you the answer, even if you were ready for it. If you find

    out, we'd all love to know.

    At least I would.

    -Wm

## Stevan Apter — 2009-02-16 22:29:55

    productivity is a very complicated business, depending on factors

    ranging from the language to the personality chemistry of the programming

    team to the politics of the origanization.  as far as language is concerned,

    i've always imagined it to consist of the *distance* (in some metaphorical

    sense) from the thought to the code.

    can the programmer, literate in X, easily read off the meaning of the

    code, discern the algorithm in the text?  does X help or hinder the search

    for new algorithms?  does the implementation assist or obstruct?  &c.  these

    questions alone are complicated enough to resist off-the-cuff judgements.

    i think they take years to answer for any language, and what is required is

    an *actual large-scale project* under real-world conditions.

    (since i'm an old APLer, i'll cite the criticism of my colleague from morgan

    stanley, richard brookheiser, that APL was *too productive* (_a demon of our

    own design_))

     ----- Original Message -----

    From: "chris glur" <crglur@...>

    To: <concatenative@yahoogroups.com>

    Sent: Monday, February 16, 2009 4:44 PM

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

    > >you can express the distributivity of

    >>multiplication nicely without the need for infix operators:

    >

    > Which via A -> B -> C leads to increased productivety,

    > either via faster initial building, or easier maintenance or increased

    > reliability.

    >

    > What are the [assumed ?] A,B,C.

    >

    > I feel like a child trying to find out where babies

    > come from, who's being given the run-around.

    >

    > ===re. unsubscribing critics:-

    > Admitting that it's just fun, mentally stimulating

    > or might lead somewhere is completely legitimate.

    > Apparently origami has many followers too ?

    >

    > Muzzeling criticism is ....well ...gun-slinging ?

    >

    > == Chris Glur.

    >

    >

    > On 2/16/09, Christopher Diggins <cdiggins@...> wrote:

    >> On Mon, Feb 16, 2009 at 8:17 AM, chris glur <crglur@...> wrote:

    >>> Since I started reading this mail-list all I've got is:

    >>>

    >>> 'look ma I can wear my cap backwards;

    >>> and you can turn it inside out;

    >>> and if you turn it to the right and march north,

    >>> it points in the direction, where the sun rises,

    >>> which will tell you approximately where the sun sets'.

    >>> So what ?

    >>> What the point of it all ?!

    >>

    >> No point at all. Now unsubscribe and leave us alone.

    >> William, can you do something about this guy?

    >>

    >> - Christopher Diggins

    >>

    >

## Don Groves — 2009-02-17 01:44:15

    On Feb 16, 2009, at 5:49 AM, John Nowak wrote:

     >

    > On Feb 16, 2009, at 8:17 AM, chris glur wrote:

    >

    >> What the point of it all ?!

     To John's excellent summary below, I would add only one thing,

    which he gets close to but doesn't say explicitly, and that is that

    the primary aim of formal methods is to demonstrate program

    correctness. If they can also make programs easier to read and

    make programmers more productive by some metric, such as

    working volume of code per programmer hour, that is icing on

    the cake.

    But the cake is a provably correct program, or at least the ability

    to demonstrate that the code is transformationally correct, i.e., if

    it is correct at some point, then it is correct at any later point.

    Concatenative methods appeal to me as the best path toward

    this goal.

    Also, it takes some time using a concatenative language before

    you see the productively gains in your own work. I'll just say that

    in my nearly 40 years of programming, Forth was clearly the most

    productive language I used (in terms of that metric above).

    --

    don

     >> 1. The formal methods you mention are certainly a big element. The

    > pointfree, concatenative nature of the code makes it very easily to

    > manipulate programs. This property has not been taken advantage of

    > yet.

    >

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

    >

    > 3. First-order stack-based languages are well-suited to a graphical

    > representation once you apply a type discipline. This would mesh very

    > well with a linear implementation.

    >

    > 4. Concatenative languages can be considerably simpler than their

    > typical applicative counterparts. Throw out all your binding forms,

    > precedence rules, scoping rules, etc.

    >

    > Other people undoubtedly have other interests.

    >

    >> I recently investigated gforth

    >

    > Gforth probably isn't what you want to be looking at. Factor is a

    > better bet, although it isn't currently capitalizing on the formal

    > methods you're talking about.

    >

    >> [advantages of] knowing that language X can be viewed as a sequence

    >> of [transformations] of stacks?

    >

    > It certainly makes it easy to move state through your program. This is

    > what enables the linear implementation I mentioned previously.

    > Similarly, it could make dealing with uniqueness types quite

    > comfortable.

    >

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

    >

    > - John

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## John Nowak — 2009-02-17 05:07:18

    On Feb 16, 2009, at 2:50 PM, William Tanksley wrote:

     > John Nowak wrote:

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

    >

    > You are not the only one; I've been interested in that since I read

    > it,

    > way back in the mists of memory.

     I may not be totally crazy then.

     >> 3. First-order stack-based languages are well-suited to a graphical

    >> representation once you apply a type discipline. This would mesh very

    >> well with a linear implementation.

    >

    > I agree, although "type discipline" isn't as strictly important as

    > static stack effects.

     You're right; factor's stack inference would be enough provided you're

    willing to shrug when a definition can't infer. Nowadays though, it

    seems most things infer fine.

     > It would be very interesting, also, to consider a few different ideas:

     Interesting ideas!

    - John

## Stevan Apter — 2009-02-17 18:01:39

    > (since i'm an old APLer, i'll cite the criticism of my colleague from morgan

    > stanley, richard brookheiser, that APL was *too productive* (_a demon of our

    > own design_))

     uh, that should have been richard bookstaber, not brookheiser.  billy

    has probably figured out the reason for the slip .... :)

## John Nowak — 2009-02-18 07:46:18

    On Feb 16, 2009, at 8:44 PM, Don Groves wrote:

     >> What the point of it all ?!

    >

    > To John's excellent summary below, I would add only one thing,

    > which he gets close to but doesn't say explicitly, and that is that

    > the primary aim of formal methods is to demonstrate program

    > correctness.

     That may be the primary aim, but I'm not sure it is the primary

    benefit of such an approach. Designing a language to be amenable to

    formal analysis means that you have to keep things simple. You have to

    throw out ideas or language features that, while perhaps easy to

    implement, are hard to reason about. You have to eliminate or

    carefully take note of anything that might violate your fundamental

    model. You have to develop a syntax that makes proofs easier.

    Essentially, designing a language with the aim of making formal

    methods useful to more programmers ensures that your language has its

    head screwed on straight. How many languages have we seen that have

    all sorts of odd corner cases and misfeatures surfacing ten years or

    more after their initial release? Things like Ruby's broken scoping

    would've never happened if there was even a hint of effort towards

    making the language subject to rigorous reasoning.

    My point is that even if most programmers will not use formal methods,

    they will still greatly benefit by using a language that makes them

    possible. Such a language is essentially guaranteed to have less

    weirdness and less complexity than a language designed with only a

    nebulous concept of "productivity" in mind.

    - John

## Don Groves — 2009-02-18 08:07:32

    On Feb 17, 2009, at 11:46 PM, John Nowak wrote:

     >

    > On Feb 16, 2009, at 8:44 PM, Don Groves wrote:

    >

    >>> What the point of it all ?!

    >>

    >> To John's excellent summary below, I would add only one thing,

    >> which he gets close to but doesn't say explicitly, and that is that

    >> the primary aim of formal methods is to demonstrate program

    >> correctness.

    >

    > That may be the primary aim, but I'm not sure it is the primary

    > benefit of such an approach. Designing a language to be amenable to

    > formal analysis means that you have to keep things simple. You have to

    > throw out ideas or language features that, while perhaps easy to

    > implement, are hard to reason about. You have to eliminate or

    > carefully take note of anything that might violate your fundamental

    > model. You have to develop a syntax that makes proofs easier.

    >

    > Essentially, designing a language with the aim of making formal

    > methods useful to more programmers ensures that your language has its

    > head screwed on straight. How many languages have we seen that have

    > all sorts of odd corner cases and misfeatures surfacing ten years or

    > more after their initial release? Things like Ruby's broken scoping

    > would've never happened if there was even a hint of effort towards

    > making the language subject to rigorous reasoning.

    >

    > My point is that even if most programmers will not use formal methods,

    > they will still greatly benefit by using a language that makes them

    > possible. Such a language is essentially guaranteed to have less

    > weirdness and less complexity than a language designed with only a

    > nebulous concept of "productivity" in mind.

     Agreed. I've never forgotten this lesson from my high school geometry

    teacher:

    An object is sitting on the teacher's desk at the front of the room.

    The problem is to develop a formal procedure that will move the

    object from there to the southwest corner of the room. Easy enough...

    Then the teacher says to repeat the problem with the object sitting

    on the floor next to the teacher's desk. The only acceptable answer

    is to pick up the object and place it on the desk -- the rest of the

    problem is already solved!

    Now, while this method of problem solving can be used in any

    programming language, concatenative languages are built upon

    this foundation. So, concatenative languages enable a programmer

    to use provably-correct formal methods by their very nature.

    --

    don

     > - John

## John Nowak — 2009-02-18 12:24:33

    On Feb 18, 2009, at 3:07 AM, Don Groves wrote:

     > Then the teacher says to repeat the problem with the object sitting

    > on the floor next to the teacher's desk. The only acceptable answer

    > is to pick up the object and place it on the desk -- the rest of the

    > problem is already solved!

    >

    > Now, while this method of problem solving can be used in any

    > programming language, concatenative languages are built upon

    > this foundation. So, concatenative languages enable a programmer

    > to use provably-correct formal methods by their very nature.

     Interesting point. Two questions:

    1) How much of this is due to the "flatness" of concatenative

    languages? In a flat concatenative language, it's as easy as it could

    possibly be to concatenate, splice, and otherwise manipulate programs.

    Nothing gets in your way.

    2) If flatness helps, do first class quotations make things more

    difficult? Instead of being able to split at any point, quotations

    mean that you can only split within a certain context. I'm assuming

    the answer here is "yes", but I've not attempted to show this yet.

    If a large part of what makes concatenative languages well-suited to

    formal methods is their flat nature, then that would be a strong

    argument for the stack as the proper datatype for a concatenative

    language. My experiments with other datatypes have all resulted in a

    much more "nested" language with many additional functional forms.

    William has correctly remarked that they don't even "feel"

    concatenative.

    If first class quotations make things more difficult, then that would

    be a strong argument for trying the second order approach I've

    described previously; it keeps most of the benefits of the higher

    order approach while offering a trivial translation to a first order

    (i.e. "flat") program.

    - John

## John Cowan — 2009-02-18 19:41:08

    Don Groves scripsit:

     > An object is sitting on the teacher's desk at the front of the room.

    > The problem is to develop a formal procedure that will move the

    > object from there to the southwest corner of the room. Easy enough...

    >

    > Then the teacher says to repeat the problem with the object sitting

    > on the floor next to the teacher's desk. The only acceptable answer

    > is to pick up the object and place it on the desk -- the rest of the

    > problem is already solved!

     A puzzle:  You are in a room with a gas stove, a match, a bucket full

    of water, and a kettle. Your objective is to boil water. What, exactly,

    do you do?  Obviously you light the match, use it to light the stove,

    fill the kettle from the bucket, put it on the stove and wait.

    Second puzzle: You are in a room with a gas stove, a lit match, a bucket

    full of water, and a kettle. Your objective is to boil water. What,

    exactly, do you do?  The same thing except not bothering to light

    the match? Wrong. That's physicist/engineer thinking. A mathematician

    would blow out the match and then say he had reduced the problem to the

    previous problem!

    IOW, programming is about the Real World, and the Real World is inherently

    stateful.

    --

    May the hair on your toes never fall out!       John Cowan

            --Thorin Oakenshield (to Bilbo)         cowan@...

## Don Groves — 2009-02-18 23:04:07

    On Feb 18, 2009, at 4:24 AM, John Nowak wrote:

     >

    > On Feb 18, 2009, at 3:07 AM, Don Groves wrote:

    >

    >> Then the teacher says to repeat the problem with the object sitting

    >

    >> on the floor next to the teacher's desk. The only acceptable answer

    >> is to pick up the object and place it on the desk -- the rest of the

    >> problem is already solved!

    >>

    >> Now, while this method of problem solving can be used in any

    >> programming language, concatenative languages are built upon

    >> this foundation. So, concatenative languages enable a programmer

    >> to use provably-correct formal methods by their very nature.

    >

    > Interesting point. Two questions:

    >

    > 1) How much of this is due to the "flatness" of concatenative

    > languages? In a flat concatenative language, it's as easy as it could

    > possibly be to concatenate, splice, and otherwise manipulate programs.

    > Nothing gets in your way.

    >

    > 2) If flatness helps, do first class quotations make things more

    > difficult? Instead of being able to split at any point, quotations

    > mean that you can only split within a certain context. I'm assuming

    > the answer here is "yes", but I've not attempted to show this yet.

    >

    > If a large part of what makes concatenative languages well-suited to

    > formal methods is their flat nature, then that would be a strong

    > argument for the stack as the proper datatype for a concatenative

    > language. My experiments with other datatypes have all resulted in a

    > much more "nested" language with many additional functional forms.

    > William has correctly remarked that they don't even "feel"

    > concatenative.

    >

    > If first class quotations make things more difficult, then that would

    > be a strong argument for trying the second order approach I've

    > described previously; it keeps most of the benefits of the higher

    > order approach while offering a trivial translation to a first order

    > (i.e. "flat") program.

     Not having much experience writing non-flat code, I'll have to pass

    on passing any judgment as to which is better for what purposes.

    I do feel quotations add to the usefulness of these languages

    however, in spite of, as you point out, their removal of some of the

    manipulations possible in a language such as Forth. Quotations

    add many benefits, imho.

    --

    don

     > - John

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## Don Groves — 2009-02-18 23:17:31

    On Feb 18, 2009, at 11:41 AM, John Cowan wrote:

     > Don Groves scripsit:

    >

    >> An object is sitting on the teacher's desk at the front of the room.

    >> The problem is to develop a formal procedure that will move the

    >> object from there to the southwest corner of the room. Easy enough...

    >>

    >> Then the teacher says to repeat the problem with the object sitting

    >> on the floor next to the teacher's desk. The only acceptable answer

    >> is to pick up the object and place it on the desk -- the rest of the

    >> problem is already solved!

    >

    > A puzzle:  You are in a room with a gas stove, a match, a bucket full

    > of water, and a kettle. Your objective is to boil water. What,

    > exactly,

    > do you do?  Obviously you light the match, use it to light the stove,

    > fill the kettle from the bucket, put it on the stove and wait.

    >

    > Second puzzle: You are in a room with a gas stove, a lit match, a

    > bucket

    > full of water, and a kettle. Your objective is to boil water. What,

    > exactly, do you do?  The same thing except not bothering to light

    > the match? Wrong. That's physicist/engineer thinking. A mathematician

    > would blow out the match and then say he had reduced the problem to

    > the

    > previous problem!

    >

    > IOW, programming is about the Real World, and the Real World is

    > inherently

    > stateful.

     Point taken. But your example is faulty. Blowing out the match

    doesn't reduce to the previous problem as then you no longer

    have a match! Try it with a cigarette lighter ;-)

    --

    don

     > --

    > May the hair on your toes never fall out!       John Cowan

    >        --Thorin Oakenshield (to Bilbo)         cowan@...

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## John Cowan — 2009-02-18 23:27:57

    Don Groves scripsit:

     > Point taken. But your example is faulty. Blowing out the match

    > doesn't reduce to the previous problem as then you no longer

    > have a match! Try it with a cigarette lighter ;-)

     A cigarette lighter has only one bit of state (it's on or off), but a

    match has two bits of state: burning or not burning, plus unused or used.

    Once you have flipped the latter bit, there's no way to flop it.

    So a match has *history*, which is what makes it un-mathematical.

    --

    We are lost, lost.  No name, no business, no Precious, nothing.  Only empty.

    Only hungry: yes, we are hungry.  A few little fishes, nassty bony little

    fishes, for a poor creature, and they say death.  So wise they are; so just,

    so very just.  --Gollum        cowan@...  http://ccil.org/~cowan

## Don Groves — 2009-02-18 23:33:13

    On Feb 18, 2009, at 3:27 PM, John Cowan wrote:

     > Don Groves scripsit:

    >

    >> Point taken. But your example is faulty. Blowing out the match

    >> doesn't reduce to the previous problem as then you no longer

    >> have a match! Try it with a cigarette lighter ;-)

    >

    > A cigarette lighter has only one bit of state (it's on or off), but a

    > match has two bits of state: burning or not burning, plus unused or

    > used.

    > Once you have flipped the latter bit, there's no way to flop it.

    > So a match has *history*, which is what makes it un-mathematical.

     Actually, a cigarette lighter has two state bits also. The second bit

    tells whether or not there is enough fuel in the lighter for it to light

    one more time ;-)

    --

    don

     > --

    > We are lost, lost.  No name, no business, no Precious, nothing.

    > Only empty.

    > Only hungry: yes, we are hungry.  A few little fishes, nassty bony

    > little

    > fishes, for a poor creature, and they say death.  So wise they are;

    > so just,

    > so very just.  --Gollum        cowan@...  http://ccil.org/~cowan

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## John Cowan — 2009-02-18 23:35:26

    Don Groves scripsit:

     > Actually, a cigarette lighter has two state bits also. The second bit

    > tells whether or not there is enough fuel in the lighter for it to light

    > one more time ;-)

     Assume a perfectly spherical lighter with an infinite capacity for fuel....

    --

    John Cowan        http://ccil.org/~cowan   cowan@...

    Lope de Vega: "It wonders me I can speak at all.  Some caitiff rogue did

    rudely yerk me on the knob, wherefrom my wits still wander."

    An Englishman: "Ay, a filchman to the nab betimes 'll leave a man

    crank for a spell." --Harry Turtledove, Ruled Britannia

## William Tanksley — 2009-02-18 23:36:03

    John Cowan wrote:

     > Second puzzle: You are in a room with a gas stove, a lit match, a bucket

    > full of water, and a kettle. Your objective is to boil water. What,

    > exactly, do you do?  The same thing except not bothering to light

    > the match? Wrong. That's physicist/engineer thinking. A mathematician

    > would blow out the match and then say he had reduced the problem to the

    > previous problem!

     That's engineer thinking.

    The physicist would blow out the match slowly, and say that if we assume

    reversible processes, we've reduced the problem to the previous case.

    Also: make sure the problem statement doesn't incorporate the presence

    of thermite, or the engineer's solution to every problem becomes the

    same. (And he will never have the same problem twice!)

     > IOW, programming is about the Real World, and the Real World is

    > inherently stateful.

     Stateful and irreversible.

    But this doesn't tell us a lot about computation, only about the real

    world. Any model of computation will always eventually fail. Modeling it

    on physics fails quickly.

    -Wm

## Don Groves — 2009-02-18 23:42:01

    On Feb 18, 2009, at 3:35 PM, John Cowan wrote:

     > Don Groves scripsit:

    >

    >> Actually, a cigarette lighter has two state bits also. The second bit

    >> tells whether or not there is enough fuel in the lighter for it to

    >> light

    >> one more time ;-)

    >

    > Assume a perfectly spherical lighter with an infinite capacity for

    > fuel....

     Now *that's* a mathematician's thinking!

    --

    don

     > --

    > John Cowan        http://ccil.org/~cowan   cowan@...

    > Lope de Vega: "It wonders me I can speak at all.  Some caitiff rogue

    > did

    > rudely yerk me on the knob, wherefrom my wits still wander."

    > An Englishman: "Ay, a filchman to the nab betimes 'll leave a man

    > crank for a spell." --Harry Turtledove, Ruled Britannia

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## William Tanksley — 2009-02-18 23:50:02

    John Nowak wrote:

     > Don Groves wrote:

    > > Now, while this method of problem solving can be used in any

    > > programming language, concatenative languages are built upon

    > > this foundation. So, concatenative languages enable a programmer

    > > to use provably-correct formal methods by their very nature.

    > Interesting point. Two questions:

    > 1) How much of this is due to the "flatness" of concatenative

    > languages? In a flat concatenative language, it's as easy as it could

    > possibly be to concatenate, splice, and otherwise manipulate programs.

    > Nothing gets in your way.

    >From a formal analysis point of view, 'flat' isn't as useful a term as

     'associative'. (I invented 'flat', so shame on me!) All languages that

    have any concatenativity, to that extent have associative syntax and

    semantics.

    A completely flat language is completely associative -- there are no

    operators that block associativity in any way. This helps theoretical

    analysis because one can separate out any part of a word for analysis,

    and once one understands one sequence, that understanding is valid no

    matter what context it appears in. For an example where this isn't true,

    consider the word 'then' in most languages (including Forth). What does

    it mean? Its meaning is largely dependant on context. In PL/I it might

    be a variable name OR part of the if/then syntax. A milder example is

    the "[" and "]" in nested concatenative languages, and the definition

    boundaries in most languages (colorForth is an interesting exception,

    since almost everything's a definition, and the syntax that defines an

    entry point doesn't also terminate a word).

     > 2) If flatness helps, do first class quotations make things more

    > difficult? Instead of being able to split at any point, quotations

    > mean that you can only split within a certain context. I'm assuming

    > the answer here is "yes", but I've not attempted to show this yet.

     Quotations with listlike operations are very, very hard to analyse.

    Let's simply exclude them from discussion. Quotations themselves simply

    form a boundary point -- you can't associate across an "[" or "]", but

    you can freely associate within them. That's not a huge difficulty,

    unless the programmer uses a ton of fragmented quotations (and if the

    fragmentation follows simple syntactic rules, like always quoting

    exactly one word and never nesting, those difficulties reduce to the

    trivial).

     > If a large part of what makes concatenative languages well-suited to

    > formal methods is their flat nature, then that would be a strong

    > argument for the stack as the proper datatype for a concatenative

    > language.

     Nesting gets in the way... But not being able to quickly notate nesting

    gets in the way, too. I've never figured out how to implement a

    completely flat language that's any fun to program in. I may be looking

    in the wrong places.

    But I'm now as certain as I can be that associativity is the heart of

    why concatenative languages are generally easy to analyse. The more your

    language allows that, the more "concatenative" people will tend to think

    it is.

     > My experiments with other datatypes have all resulted in a

    > much more "nested" language with many additional functional forms.

    > William has correctly remarked that they don't even "feel"

    > concatenative.

     The stack might possibly be the simplest concatenative datatype. It's

    easy to add more complexity: A second stack, or a dictionary, or a

    readable/writable terminal, or a queue to handle continuations, etc.

    I've seen nothing that provides similar power to a stack, although I'd

    like to.

    Oh, by the way, ANS Forth has an optional floating point stack that it's

    possible to implement as a separate stack; the programmer is supposed to

    write code that's agnostic about whether floating point numbers are

    stored on the data stack or somewhere else.

     > If first class quotations make things more difficult, then that would

    > be a strong argument for trying the second order approach I've

    > described previously; it keeps most of the benefits of the higher

    > order approach while offering a trivial translation to a first order

    > (i.e. "flat") program.

     Your second order ideas look very interesting, actually. Have you taken

    a break on working with it -- I haven't heard anything... ?

     > - John

     -Wm

## Don Groves — 2009-02-18 23:52:51

    On Feb 18, 2009, at 3:36 PM, William Tanksley wrote:

     > John Cowan wrote:

    >> Second puzzle: You are in a room with a gas stove, a lit match, a

    >> bucket

    >> full of water, and a kettle. Your objective is to boil water. What,

    >> exactly, do you do?  The same thing except not bothering to light

    >> the match? Wrong. That's physicist/engineer thinking. A mathematician

    >> would blow out the match and then say he had reduced the problem to

    >> the

    >> previous problem!

    >

    > That's engineer thinking.

    >

    > The physicist would blow out the match slowly, and say that if we

    > assume

    > reversible processes, we've reduced the problem to the previous case.

    >

    > Also: make sure the problem statement doesn't incorporate the presence

    > of thermite, or the engineer's solution to every problem becomes the

    > same. (And he will never have the same problem twice!)

    >

    >> IOW, programming is about the Real World, and the Real World is

    >> inherently stateful.

    >

    > Stateful and irreversible.

    >

    > But this doesn't tell us a lot about computation, only about the real

    > world. Any model of computation will always eventually fail.

    > Modeling it

    > on physics fails quickly.

     The weird yet wonderful world of computation. What is it that drives

    us to beat our heads against this particular wall?

    --

    don

     > -Wm

## William Tanksley — 2009-02-19 00:22:44

    Don Groves wrote:

     > William Tanksley wrote:

    > > But this doesn't tell us a lot about computation, only about the real

    > > world. Any model of computation will always eventually fail.

    > > Modeling it on physics fails quickly.

    > The weird yet wonderful world of computation. What is it that drives

    > us to beat our heads against this particular wall?

     We reason about computation for the same reason I beat my head against

    the wall: because it feels so good when I halt.

    Seriously, computation is how we reason. If we don't think about that,

    we'll keep making the same errors. (Note that I'm not claiming whether

    or not computation is the *only* way we think. Such a discussion would

    be offtopic. Anyhow, the same problem is present with any system

    powerful enough to model the integers.)

     > don

     -Wm

## eas lab — 2009-02-19 01:10:52

    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.

## Don Groves — 2009-02-19 03:26:48

    On Feb 18, 2009, at 5:10 PM, eas lab wrote:

     > ... major snippage...

    >

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

     Exactly! So would you rather see the typical Pascal if-then-else

    statement or this:

    fun1 fun2 arg if-else

    where if-else is a function that examines arg, executes fun1

    if arg is true, executes fun2 otherwise, and cleans all three

    off the stack leaving the result of the appropriate function in

    their place?

    Once used to this way of actually forgetting about all the

    syntax crap, it becomes just as readable, and far more

    succinct than any Pascal-like language.

    --

    don

     > Thanks,

    >

    > == Chris Glur.

## Joe Bowbeer — 2009-02-19 03:49:55

    On Wed, Feb 18, 2009 at 7:26 PM, Don Groves wrote:

     > Once used to this way of actually forgetting about all the

    > syntax crap, it becomes just as readable, and far more

    > succinct than any Pascal-like language.

    > --

    > don

    >

     Can the same be said of shorthand w.r.t. natural language?  (

    http://en.wikipedia.org/wiki/Shorthand)

    In practice, I think a lot of the extra surface area (redundancy,

    delimiters, grammatical rules) that is built into popular programming

    languages (as well as natural writing systems), is there to serve the human

    mind.

    Joe

    [Non-text portions of this message have been removed]

## Don Groves — 2009-02-19 03:59:57

    On Feb 18, 2009, at 7:49 PM, Joe Bowbeer wrote:

     > On Wed, Feb 18, 2009 at 7:26 PM, Don Groves wrote:

    >

    >> Once used to this way of actually forgetting about all the

    >> syntax crap, it becomes just as readable, and far more

    >> succinct than any Pascal-like language.

    >> --

    >> don

    >>

    >

    > Can the same be said of shorthand w.r.t. natural language?  (

    > http://en.wikipedia.org/wiki/Shorthand)

    >

    > In practice, I think a lot of the extra surface area (redundancy,

    > delimiters, grammatical rules) that is built into popular programming

    > languages (as well as natural writing systems), is there to serve

    > the human

    > mind.

     Ok, how about this:

    function1 function2 logical-variable

    if-logical-variable-is-true-then-do-fun1-otherwise-do-fun2

    Concatenative languages be as human readable as you want

    them to.

    --

    don

     > Joe

    >

    >

    > [Non-text portions of this message have been removed]

    >

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## John Nowak — 2009-02-19 09:36:06

    On Feb 18, 2009, at 8:10 PM, 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.

     I can't make sense out of this. If you're saying that Baker hasn't

    provided the "hello world" for linear languages, look at his other

    papers. He has given several benchmarks.

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

     Ultimately, what's more productive is what I can use for eight hours

    straight without getting frustrated.

    I've no idea what sort of productivity "proof" you're looking for. Do

    you have an example of one? If not, how can I be expected to provide

    one?

     > No ! Obviously Pascal is closer to natural language than forth

    > or even C, which is a massive advantage ?

     Read Thinking Forth.

    And why would being closer to natural language necessarily be a

    massive advantage? Ever tried using AppleScript?

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

     What?

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

     Let's speak for ourselves now...

     > I want to formalise the job and replace art by science.

     Then start doing the science!

    - John

## John Nowak — 2009-02-19 09:38:41

    On Feb 18, 2009, at 10:26 PM, Don Groves wrote:

     > Exactly! So would you rather see the typical Pascal if-then-else

    > statement or this:

    >

    > fun1 fun2 arg if-else

    >

    > where if-else is a function that examines arg, executes fun1

    > if arg is true, executes fun2 otherwise, and cleans all three

    > off the stack leaving the result of the appropriate function in

    > their place?

     To be honest, I actually prefer a prefix 'if'. Having to read past

    quotations to see what they do is unfortunate in my opinion.

    - John

## John Nowak — 2009-02-19 09:44:53

    On Feb 18, 2009, at 6:50 PM, William Tanksley wrote:

     > Nesting gets in the way... But not being able to quickly notate

    > nesting

    > gets in the way, too. I've never figured out how to implement a

    > completely flat language that's any fun to program in.

     I agree. I wouldn't suggest doing away with this. To be clear, what I

    was suggesting was only allowing nesting that is statically removable

    (with the exception of some primitives like 'if' and 'dip').

     > But I'm now as certain as I can be that associativity is the heart of

    > why concatenative languages are generally easy to analyse. The more

    > your

    > language allows that, the more "concatenative" people will tend to

    > think

    > it is.

     This is a very good observation, and I'd agree. The reason my FP-like

    experiments didn't feel concatenative was that each function "chain"

    was only about two or three functions long; there wasn't much you

    could do in terms of associative operations.

     > Your second order ideas look very interesting, actually. Have you

    > taken

    > a break on working with it -- I haven't heard anything... ?

     Been busy trying to make money to feed myself unfortunately. Hopefully

    I'll be back to work on more interesting things soon.

    - John

## Don Groves — 2009-02-19 22:02:37

    On Feb 19, 2009, at 1:38 AM, John Nowak wrote:

     >

    > On Feb 18, 2009, at 10:26 PM, Don Groves wrote:

    >

    >> Exactly! So would you rather see the typical Pascal if-then-else

    >> statement or this:

    >>

    >> fun1 fun2 arg if-else

    >>

    >> where if-else is a function that examines arg, executes fun1

    >> if arg is true, executes fun2 otherwise, and cleans all three

    >> off the stack leaving the result of the appropriate function in

    >> their place?

    >

    > To be honest, I actually prefer a prefix 'if'. Having to read past

    > quotations to see what they do is unfortunate in my opinion.

     I guess I don't consider reading past anything, I just start from

    the right.

    We use Arabic numerals, why not Arabic reading order.

    --

    don

     > - John

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## Don Groves — 2009-02-20 01:06:10

    On Feb 18, 2009, at 3:50 PM, William Tanksley wrote:

     > ...

    >

    > The stack might possibly be the simplest concatenative datatype. It's

    > easy to add more complexity: A second stack, or a dictionary, or a

    > readable/writable terminal, or a queue to handle continuations, etc.

    > I've seen nothing that provides similar power to a stack, although I'd

    > like to.

     I really wish we could come up with a different name for the "stack"

    in these languages. The canonical stack only has two methods,

    push and pop, and they only operate on the top item in the stack.

    All other items are invisible. This data structure has several uses as

    it stands and shouldn't be corrupted, in my view.

    Maybe we could call ours a "reorderable stack" (rstack) or a

    "shufflestack" (s-stack) or something that differentiates it from what

    is taught in Comp Sci 101.

    Granted, the additional stack operators we define can be defined

    in terms of push and pop, but that isn't the way we usually implement

    them and would be inefficient if we did (on register machines anyway).

    Maybe I'm too picky but I've seen too many other previously-defined

    names reused in ways that only cause confusion (mostly mine).

    --

    don

     > -Wm

## William Tanksley — 2009-02-20 05:14:04

    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

## William Tanksley — 2009-02-20 16:36:53

    Joe Bowbeer wrote:

     > Don Groves wrote:

    > > Once used to this way of actually forgetting about all the

    > > syntax crap, it becomes just as readable, and far more

    > > succinct than any Pascal-like language.

    > Can the same be said of shorthand w.r.t. natural language?  (

    > http://en.wikipedia.org/wiki/Shorthand)

     I'm not sure.

     > In practice, I think a lot of the extra surface area (redundancy,

    > delimiters, grammatical rules) that is built into popular programming

    > languages (as well as natural writing systems), is there to serve the human

    > mind.

     That's unlikely. Yes, some of those features were deliberately chosen;

    but most of them were 'chosen' for other reasons than "because it's

    efficient for humans". Ease of parsing drove Pascal's design; it's now

    clear that Pascal's strength is its simplicity, not its particular

    choice of parsers.

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

    Actual human languages are parseable by a structure known as a

    "unification grammar" (to one extent or another), but defining a

    unification grammar takes a LOT of work, and is immensely slow to parse

    (currently). In addition, the linguistic features of unification

    grammars lend themselves poorly to directing machines -- for example,

    ambiguity and multiple meanings are inherent.

     > Joe

     -Wm

## William Tanksley — 2009-02-20 17:57:11

    Don Groves wrote:

     > William Tanksley wrote:

    > > The stack might possibly be the simplest concatenative datatype. It's

    > > easy to add more complexity: A second stack, or a dictionary, or a

    > > readable/writable terminal, or a queue to handle continuations, etc.

    > > I've seen nothing that provides similar power to a stack, although I'd

    > > like to.

    > I really wish we could come up with a different name for the "stack"

    > in these languages. The canonical stack only has two methods,

    > push and pop, and they only operate on the top item in the stack.

    > All other items are invisible. This data structure has several uses as

    > it stands and shouldn't be corrupted, in my view.

     This is a good point. Actually, it ties in with what I was saying:

    concatenative languages don't really use _merely_ a stack; they all have

    something more in addition.

    In this case, you're pointing out that "stack" languages all have the

    stack plus something more to allow shuffling. Most of the formal

    languages use 'dip' as their model, which in turn can be implemented by

    means of a second stack (Forth's return stack, or Factor's old retain

    stack).

     > Maybe we could call ours a "reorderable stack" (rstack) or a

    > "shufflestack" (s-stack) or something that differentiates it from what

    > is taught in Comp Sci 101.

     I don't think there's really a need. "The stack" is different from "a

    stack", and truly, the difference is merely that some words use

    auxiliary data structures; this doesn't make the stack itself less of a

    stack.

    Of course, if we're truly going to understand concatenative languages at

    a formal level, we must not gloss over these auxiliary data structures.

    We have to explain what words use them, and which ones actually mutate

    persistent structures versus which ones use only transient ones.

    (Forth's >R and R> mutate a persistent structure; Joy's 'dip' creates a

    transient one.)

     > Granted, the additional stack operators we define can be defined

    > in terms of push and pop, but that isn't the way we usually implement

    > them and would be inefficient if we did (on register machines anyway).

     I don't think implementations details matter that much to a formal

    model.

     > Maybe I'm too picky but I've seen too many other previously-defined

    > names reused in ways that only cause confusion (mostly mine).

     This is true. But the 'stack' in stack languages truly is a stack, I

    think.

     > don

     -Wm

## Joe Bowbeer — 2009-02-20 18:00:22

    Backing up a bit, to this question:

     > So would you rather see the typical Pascal if-then-else statement or "fun1

     fun2 arg if-else" ?

    Even when faced with reasoned arguments about the simplicity and utility of

    the post-fix syntax on the right, almost everyone (outside of this list)

    would rather see Pascal.  For many people, in fact, the syntax on the right

    is a non-starter.

    As Lojban reminds us, reasoned arguments do little to change people's

    preferences.  As the old saying goes: in matters of taste, there's no

    argument.

    However, if you change the conditions, by saying, for example, that this

    language is to be used for on-device programming of an iPhone, where the

    screen is small and typing is relatively awkward, then you might get a

    different answer.  (How many remember programming those old HP calculators?)

    By the way, I think my analogies with natural language are flawed.

    Shorthand is too harsh, I think, and Textese (SMS chatspeak) is not harsh

    enough.

    Joe

     On Fri, Feb 20, 2009 at 8:36 AM, William Tanksley wrote:

    > Joe Bowbeer wrote:

    > > Don Groves wrote:

    > > > Once used to this way of actually forgetting about all the

    > > > syntax crap, it becomes just as readable, and far more

    > > > succinct than any Pascal-like language.

    > > Can the same be said of shorthand w.r.t. natural language?  (

    > > http://en.wikipedia.org/wiki/Shorthand)

    >

    > I'm not sure.

    >

    > > In practice, I think a lot of the extra surface area (redundancy,

    > > delimiters, grammatical rules) that is built into popular programming

    > > languages (as well as natural writing systems), is there to serve the

    > human

    > > mind.

    >

    > That's unlikely. Yes, some of those features were deliberately chosen;

    > but most of them were 'chosen' for other reasons than "because it's

    > efficient for humans". Ease of parsing drove Pascal's design; it's now

    > clear that Pascal's strength is its simplicity, not its particular

    > choice of parsers.

    >

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

    >

    > Actual human languages are parseable by a structure known as a

    > "unification grammar" (to one extent or another), but defining a

    > unification grammar takes a LOT of work, and is immensely slow to parse

    > (currently). In addition, the linguistic features of unification

    > grammars lend themselves poorly to directing machines -- for example,

    > ambiguity and multiple meanings are inherent.

    >

    > > Joe

    >

    > -Wm

    [Non-text portions of this message have been removed]

## William Tanksley — 2009-02-20 22:04:01

    Joe Bowbeer wrote:

     > Backing up a bit, to this question:

    > > So would you rather see the typical Pascal if-then-else statement or "fun1

    > > fun2 arg if-else" ?

    > Even when faced with reasoned arguments about the simplicity and utility of

    > the post-fix syntax on the right, almost everyone (outside of this list)

    > would rather see Pascal.  For many people, in fact, the syntax on the right

    > is a non-starter.

     As much as I'd argue with you (and everyone on this list knows I would),

    there are also reasons why you and all those people are _right_. The

    completely postfix form of 'if' necessarily leaves the reader wondering

    what the purpose of the quotation is; the answer doesn't come until they

    see the 'if' -- and if the programmer's being clever, it's possible that

    they might have to trace back through some dataflow instructions to see

    which quotation got passed to 'if'.

    Forth's or 5th's second level constructs are actually easier to read,

    even though they're not as concatenatively clean.

     > As Lojban reminds us, reasoned arguments do little to change people's

    > preferences.  As the old saying goes: in matters of taste, there's no

    > argument.

     Not so much. There are a LOT of people totally convinced by Lojban at

    one time or another. My point was that in spite of being convinced, they

    still couldn't learn Lojban up to the point of fluency.

    To design a truly natural language, you have to start with a /complex/

    grammar.

     > However, if you change the conditions, by saying, for example, that this

    > language is to be used for on-device programming of an iPhone, where the

    > screen is small and typing is relatively awkward, then you might get a

    > different answer.  (How many remember programming those old HP calculators?)

     The language was called 'RPN'. Good times. IIRC, their 'if' construct

    wasn't RPN :-).

     > By the way, I think my analogies with natural language are flawed.

    > Shorthand is too harsh, I think, and Textese (SMS chatspeak) is not harsh

    > enough.

     Analogies are never perfect :-).

    But shorthand and court-reporter typing are both superficial

    optimizations, not a profoundly different type of language.

     > Joe

     -Wm

## Don Groves — 2009-02-20 22:11:31

    On Feb 20, 2009, at 10:00 AM, Joe Bowbeer wrote:

     > Backing up a bit, to this question:

    >

    >> So would you rather see the typical Pascal if-then-else statement

    >> or "fun1

    > fun2 arg if-else" ?

    >

    > Even when faced with reasoned arguments about the simplicity and

    > utility of

    > the post-fix syntax on the right, almost everyone (outside of this

    > list)

    > would rather see Pascal.  For many people, in fact, the syntax on

    > the right

    > is a non-starter.

    >

    > As Lojban reminds us, reasoned arguments do little to change people's

    > preferences.  As the old saying goes: in matters of taste, there's no

    > argument.

     So true. Let's think about the syntax question a bit. Most people seem

    to prefer infix to either prefix or postfix when it comes to writing

    down

    an algorithm. We are trained from a very early age to write a + b + c

    instead of either (+ a b c) or a b + c +, or its equivalent a b c + +.

    However, we don't *think* or *speak* that way. We say "Here's a list

    of numbers, add them up (postfix) or "Add a to b" (prefix).

    Each method has its advantages and disadvantages. For example,

    prefix can add more than two numbers in one command, but it also

    needs parens to delimit the list.

    Infix is eminently readable due to our early education but it requires

    a more complicated compiler.

    Postfix gets rid of the parens and simplifies its compiler) but loses

    readability due to our infix mindset.

    What I notice in this is that the main disadvantage of postfix is only

    in our minds while the other disadvantages are real and measurable.

    When Forth was first made public in the early '70s, I had the same

    sort of negative reaction to its postfix syntax. But other things about

    it were so intriguing, such as being able to put an entire multitasking

    OS in 8K of memory, that I stuck with it long enough to overcome my

    initial aversion to the syntax. What I got in return was a marvelous

    tool for solving certain kinds of problems.

    And, I haven't been corrupted, I can still work in infix whenever

    necessary ;-)

    --

    don

     > However, if you change the conditions, by saying, for example, that

    > this

    > language is to be used for on-device programming of an iPhone, where

    > the

    > screen is small and typing is relatively awkward, then you might get a

    > different answer.  (How many remember programming those old HP

    > calculators?)

    >

    > By the way, I think my analogies with natural language are flawed.

    > Shorthand is too harsh, I think, and Textese (SMS chatspeak) is not

    > harsh

    > enough.

    >

    > Joe

    >

    >

    > On Fri, Feb 20, 2009 at 8:36 AM, William Tanksley wrote:

    >

    >> Joe Bowbeer wrote:

    >>> Don Groves wrote:

    >>>> Once used to this way of actually forgetting about all the

    >>>> syntax crap, it becomes just as readable, and far more

    >>>> succinct than any Pascal-like language.

    >>> Can the same be said of shorthand w.r.t. natural language?  (

    >>> http://en.wikipedia.org/wiki/Shorthand)

    >>

    >> I'm not sure.

    >>

    >>> In practice, I think a lot of the extra surface area (redundancy,

    >>> delimiters, grammatical rules) that is built into popular

    >>> programming

    >>> languages (as well as natural writing systems), is there to serve

    >>> the

    >> human

    >>> mind.

    >>

    >> That's unlikely. Yes, some of those features were deliberately

    >> chosen;

    >> but most of them were 'chosen' for other reasons than "because it's

    >> efficient for humans". Ease of parsing drove Pascal's design; it's

    >> now

    >> clear that Pascal's strength is its simplicity, not its particular

    >> choice of parsers.

    >>

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

    >>

    >> Actual human languages are parseable by a structure known as a

    >> "unification grammar" (to one extent or another), but defining a

    >> unification grammar takes a LOT of work, and is immensely slow to

    >> parse

    >> (currently). In addition, the linguistic features of unification

    >> grammars lend themselves poorly to directing machines -- for example,

    >> ambiguity and multiple meanings are inherent.

    >>

    >>> Joe

    >>

    >> -Wm

    >

    >

    > [Non-text portions of this message have been removed]

    >

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## Don Groves — 2009-02-20 22:21:19

    On Feb 20, 2009, at 9:57 AM, William Tanksley wrote:

     > Don Groves wrote:

    >> William Tanksley wrote:

    >>> The stack might possibly be the simplest concatenative datatype.

    >>> It's

    >>> easy to add more complexity: A second stack, or a dictionary, or a

    >>> readable/writable terminal, or a queue to handle continuations, etc.

    >>> I've seen nothing that provides similar power to a stack, although

    >>> I'd

    >>> like to.

    >

    >> I really wish we could come up with a different name for the "stack"

    >> in these languages. The canonical stack only has two methods,

    >> push and pop, and they only operate on the top item in the stack.

    >> All other items are invisible. This data structure has several uses

    >> as

    >> it stands and shouldn't be corrupted, in my view.

    >

    > This is a good point. Actually, it ties in with what I was saying:

    > concatenative languages don't really use _merely_ a stack; they all

    > have

    > something more in addition.

    >

    > In this case, you're pointing out that "stack" languages all have the

    > stack plus something more to allow shuffling. Most of the formal

    > languages use 'dip' as their model, which in turn can be implemented

    > by

    > means of a second stack (Forth's return stack, or Factor's old retain

    > stack).

    >

    >> Maybe we could call ours a "reorderable stack" (rstack) or a

    >> "shufflestack" (s-stack) or something that differentiates it from

    >> what

    >> is taught in Comp Sci 101.

    >

    > I don't think there's really a need. "The stack" is different from "a

    > stack", and truly, the difference is merely that some words use

    > auxiliary data structures; this doesn't make the stack itself less

    > of a

    > stack.

     Maybe that's the solution, call it "The Stack" (Al'lah be praised ;-)

    Forth, after all, has been called a religion.

     > Of course, if we're truly going to understand concatenative

    > languages at

    > a formal level, we must not gloss over these auxiliary data

    > structures.

    > We have to explain what words use them, and which ones actually mutate

    > persistent structures versus which ones use only transient ones.

    > (Forth's >R and R> mutate a persistent structure; Joy's 'dip'

    > creates a

    > transient one.)

    >

    >> Granted, the additional stack operators we define can be defined

    >> in terms of push and pop, but that isn't the way we usually implement

    >> them and would be inefficient if we did (on register machines

    >> anyway).

    >

    > I don't think implementations details matter that much to a formal

    > model.

     True.

     >> Maybe I'm too picky but I've seen too many other previously-defined

    >> names reused in ways that only cause confusion (mostly mine).

    >

    > This is true. But the 'stack' in stack languages truly is a stack, I

    > think.

     I will agree, not that I have much choice. Each new generation

    sometimes names things with little regard for the past, so it only

    bothers old farts like me. We need is an ICANN-like organization

    to control naming in Comp. Sci ;-)

    --

    don

     >> don

    >

    > -Wm

    >

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## John Cowan — 2009-02-20 23:18:51

    William Tanksley scripsit:

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

     All your facts are correct, but your inference is unsupported: there

    is zero evidence that the LALR(1) grammar (which is only so if you

    do some pre-aggregating of certain words) has anything to do with

    the problems people have had in becoming fluent.  Fluency requires a

    tightly interacting speaker community, and because Lojban materials

    are available only in English, and Lojban users are scattered all over

    the planet, it's hard to create that speaker community.  By contrast,

    Esperanto-speakers came from all over Europe and often met face-to-face

    with no common language but Esperanto.

    I'm not in touch with it myself, but I understand there is a Skype

    community chat now, with speakers at varying fluency levels.

    --

    How they ever reached any  conclusion at all    <cowan@...>

    is starkly unknowable to the human mind.        http://www.ccil.org/~cowan

            --"Backstage Lensman", Randall Garrett

## Daniel Ehrenberg — 2009-02-20 23:27:43

    In fact, most modern linguistic theories (Minimalism, Government &

    Binding, Lexical-Functional grammar, or any other one I can think of)

    don't hold that natural language is even context-free. There's too

    much stuff to be checked (for example, case and pronouns) for this to

    be possible. But maybe this is off-topic.

    Dan

     On Fri, Feb 20, 2009 at 5:18 PM, John Cowan <cowan@...> wrote:

    > All your facts are correct, but your inference is unsupported: there

    > is zero evidence that the LALR(1) grammar (which is only so if you

    > do some pre-aggregating of certain words) has anything to do with

    > the problems people have had in becoming fluent. Fluency requires a

    > tightly interacting speaker community, and because Lojban materials

    > are available only in English, and Lojban users are scattered all over

    > the planet, it's hard to create that speaker community. By contrast,

    > Esperanto-speakers came from all over Europe and often met face-to-face

    > with no common language but Esperanto.

    >

    > I'm not in touch with it myself, but I understand there is a Skype

    > community chat now, with speakers at varying fluency levels.

    >

    > --

    > How they ever reached any conclusion at all <cowan@...>

    > is starkly unknowable to the human mind. http://www.ccil.org/~cowan

    > --"Backstage Lensman", Randall Garrett

    >

    >

## John Cowan — 2009-02-21 00:47:13

    Daniel Ehrenberg scripsit:

     > In fact, most modern linguistic theories (Minimalism, Government &

    > Binding, Lexical-Functional grammar, or any other one I can think of)

    > don't hold that natural language is even context-free. There's too

    > much stuff to be checked (for example, case and pronouns) for this to

    > be possible. But maybe this is off-topic.

     Human language is not context-free, but the counterexamples are few:

    most languages are context-free, and the ones that sometimes aren't,

    are still context-free most of the time.

    Here's Shieber's 1985 paper nailing down the non-CF-ness of Swiss

    German: http://www.eecs.harvard.edu/~shieber/Biblio/Papers/shieber85.pdf

    --

    John Cowan                                cowan@...

    I amar prestar aen, han mathon ne nen,    http://www.ccil.org/~cowan

    han mathon ne chae, a han noston ne 'wilith.  --Galadriel, LOTR:FOTR

## John Nowak — 2009-02-21 09:49:21

    On Feb 20, 2009, at 1:00 PM, Joe Bowbeer wrote:

     > As the old saying goes: in matters of taste, there's no argument.

     True, but I don't think syntax is a "matter of taste" the same way raw

    eel is. Different syntaxes have different qualities. For example,

    Scheme has a syntax that is well-suited to meta-programming and

    structural editing. Joy's syntax makes algebraic manipulation very

    easy. Such qualities aren't subjective or matters of taste.

    Of course, some elements of syntax are subjective. My concern though

    is that it's too easy to throw out objectively useful things because

    someone said "ewww" upon first seeing them.

    - John

## Stevan Apter — 2009-02-22 15:11:28

    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.

    when i'm programming, all my thinking takes place within a very

    simple framework:  find a data representation for my problem, then

    find the best set of functions which transform these representations

    to solve my problem.  r <- f[a;...;z].  iterate until done.

    as a k guy, two things about joy stood out immediately:  (i) joy

    is a scalar language, and (ii) the syntax is concatenative and

    not applicative.  but it turned out to be a simple matter to

    enhance joy (actually, the false language) with the k primitives

    (www.nsl.com/k//f/f.htm).  ok, i had to think about "the stack",

    but that was a small price to pay for the reduction in syntactic

    complexity.

    factor is way too complicated for me.  i gave up early on.  i

    really don't want to think about the internals of the implementation

    when i'm coding.  the ONLY thing i want floating around in my head

    in addition to the problem i'm working on is at most 20 or 30 purely

    functional primitives, and ideally these should be divided into a

    few classes of a few members each.  (granted, i haven't kept up

    with factor development, so things might have gotten simpler, but

    that's not the direction things seemed to be taking a few years

    ago.)

    typing is another language feature i don't want to think about.

    i was discouraged from learning haskell because half the messages

    posted in their newsgroup involved some typing conundrum.  the last

    thing i need is to get stopped in my tracks by one of these.  don't

    get me wrong.  the problems john and christopher are working on

    interest me, but there's no way i would ever use a language in

    my day job which required this extra level of attention.  i guess

    the easiest way to put it is that i don't want my programs to

    fail in more than five or six ways.

    oddly enough, the only language proposed in this forum i can

    imagine using is enchilada, and that's mainly for two reasons:

    (i) i've seen robbert use the language to solve hard problems

    very easily, and (ii) whenever i tried to learn it, my brain

    exploded.  those facts indicate to me that there are some

    powerful new ideas (but very simple ones) going on in that

    language.  (i had the same experience reading john conway's

    book on surreal numbers many years ago.)

    now billy, who's a very creative thinker, has reported similar

    problems with j and k, so this might be (it probably is) entirely

    a matter of thinking-style, or maybe a function of what languages

    you learned first and used most.

     ----- Original Message -----

    From: "John Nowak" <john@...>

    To: <concatenative@yahoogroups.com>

    Sent: Saturday, February 21, 2009 4:49 AM

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

    >

    > On Feb 20, 2009, at 1:00 PM, Joe Bowbeer wrote:

    >

    >> As the old saying goes: in matters of taste, there's no argument.

    >

    > True, but I don't think syntax is a "matter of taste" the same way raw

    > eel is. Different syntaxes have different qualities. For example,

    > Scheme has a syntax that is well-suited to meta-programming and

    > structural editing. Joy's syntax makes algebraic manipulation very

    > easy. Such qualities aren't subjective or matters of taste.

    >

    > Of course, some elements of syntax are subjective. My concern though

    > is that it's too easy to throw out objectively useful things because

    > someone said "ewww" upon first seeing them.

    >

    > - John

    >

## Robbert van Dalen — 2009-02-22 22:11:59

    k and j is one of the few languages that really *forces* you to think

    differently. i know, i'm still trying to wrap my head around it :)

    that said, k's successor - q - is much more accessible. however,

    (re-)reading q code can be as daunting as (re-)reading k code, especially if

    the code is written by coding gurus like stevan :)

    k and j are termed to be 'array' languages. but the way i see it is that an

    array is a special, but very concrete case of a function. an array is a

    function that maps (a consecutive domain of) integers to anything (untyped).

    the function is *the*unifying concept that works in many wondrous ways in k.

    and  i believe *that* is the real power of k.

    i feel stevan is right about factor. sure, factor does force you to think

    differently: the stack *does* that to you. but what really new concepts does

    factor bring to the table? for example, for factor to be efficiently

    compiled to a register based architecture, it must leave the stack model. it

    also feeds my suspicion that - if a language primitive can be compiled to

    x84 one-to-one - that language primitive is not far away from - say - a

    pascal primitive.

    but how does k stack up against pascal? i believe k is a magnitude different

    from pascal, because it puts collections *before* the scalars. and while k

    is interpreted, it beats heavily optimized (and compiled) pascal programs in

    many cases.

    so my guess is that collection based languages are the future. and i do hope

    that such collection oriented language is (optionally) strongly typed, and

    hopefully, written in postfix syntax :)

    that's it: postfix syntax is the most economic way to *syntactically*

    express computations. now match postfix with q and you might have to most

    economical language ever...

    in the end, the primitives make the difference ....

    are they scalar or ....?

    - robbert

     On Sun, Feb 22, 2009 at 4:11 PM, Stevan Apter <sa@...> wrote:

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

    >

    > when i'm programming, all my thinking takes place within a very

    > simple framework: find a data representation for my problem, then

    > find the best set of functions which transform these representations

    > to solve my problem. r <- f[a;...;z]. iterate until done.

    >

    > as a k guy, two things about joy stood out immediately: (i) joy

    > is a scalar language, and (ii) the syntax is concatenative and

    > not applicative. but it turned out to be a simple matter to

    > enhance joy (actually, the false language) with the k primitives

    > (www.nsl.com/k//f/f.htm). ok, i had to think about "the stack",

    > but that was a small price to pay for the reduction in syntactic

    > complexity.

    >

    > factor is way too complicated for me. i gave up early on. i

    > really don't want to think about the internals of the implementation

    > when i'm coding. the ONLY thing i want floating around in my head

    > in addition to the problem i'm working on is at most 20 or 30 purely

    > functional primitives, and ideally these should be divided into a

    > few classes of a few members each. (granted, i haven't kept up

    > with factor development, so things might have gotten simpler, but

    > that's not the direction things seemed to be taking a few years

    > ago.)

    >

    > typing is another language feature i don't want to think about.

    > i was discouraged from learning haskell because half the messages

    > posted in their newsgroup involved some typing conundrum. the last

    > thing i need is to get stopped in my tracks by one of these. don't

    > get me wrong. the problems john and christopher are working on

    > interest me, but there's no way i would ever use a language in

    > my day job which required this extra level of attention. i guess

    > the easiest way to put it is that i don't want my programs to

    > fail in more than five or six ways.

    >

    > oddly enough, the only language proposed in this forum i can

    > imagine using is enchilada, and that's mainly for two reasons:

    > (i) i've seen robbert use the language to solve hard problems

    > very easily, and (ii) whenever i tried to learn it, my brain

    > exploded. those facts indicate to me that there are some

    > powerful new ideas (but very simple ones) going on in that

    > language. (i had the same experience reading john conway's

    > book on surreal numbers many years ago.)

    >

    > now billy, who's a very creative thinker, has reported similar

    > problems with j and k, so this might be (it probably is) entirely

    > a matter of thinking-style, or maybe a function of what languages

    > you learned first and used most.

    >

    > ----- Original Message -----

    > From: "John Nowak" <john@... <john%40johnnowak.com>>

    > To: <concatenative@yahoogroups.com <concatenative%40yahoogroups.com>>

    > Sent: Saturday, February 21, 2009 4:49 AM

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

    >

    > >

    > > On Feb 20, 2009, at 1:00 PM, Joe Bowbeer wrote:

    > >

    > >> As the old saying goes: in matters of taste, there's no argument.

    > >

    > > True, but I don't think syntax is a "matter of taste" the same way raw

    > > eel is. Different syntaxes have different qualities. For example,

    > > Scheme has a syntax that is well-suited to meta-programming and

    > > structural editing. Joy's syntax makes algebraic manipulation very

    > > easy. Such qualities aren't subjective or matters of taste.

    > >

    > > Of course, some elements of syntax are subjective. My concern though

    > > is that it's too easy to throw out objectively useful things because

    > > someone said "ewww" upon first seeing them.

    > >

    > > - John

    > >

    >

    >

    >

    [Non-text portions of this message have been removed]

## John Nowak — 2009-02-22 23:15:32

    On Feb 22, 2009, at 10:11 AM, Stevan Apter wrote:

     > typing is another language feature i don't want to think about.

    > i was discouraged from learning haskell because half the messages

    > posted in their newsgroup involved some typing conundrum. the last

    > thing i need is to get stopped in my tracks by one of these.

     GHC is really a type systems research vehicle. It has piles of

    extensions with overlapping (or even identical) goals that interact in

    complicated ways. There are a few extensions I don't understand at all.

    The system in Cat is nothing like this. It's a very straightforward

    extension of Hindley-Milner. On top of that, all collections are

    essentially dynamically typed. I see no reason you couldn't implement

    your K-style primitives in Cat.

    I'm not saying you'd like it or find the types useful, but I'm sure

    you'd not get hung up on it the way people can with GHC's extensions.

    It's simple stuff.

     > i guess the easiest way to put it is that i don't want my programs to

    > fail in more than five or six ways.

     Aye, that's why I like types!

    - John

## John Nowak — 2009-02-22 23:37:26

    On Feb 22, 2009, at 5:11 PM, Robbert van Dalen wrote:

     > for example, for factor to be efficiently compiled to a register

    > based architecture, it must leave the stack model. ... if a language

    > primitive can be compiled to x84 one-to-one - that language primitive

    > is not far away from - say - a pascal primitive.

     It never leaves the "stack model". The implementation doesn't always

    shuffle things around on a stack, but that seems immaterial. I think

    it's better to look at the semantics than to assume a language isn't

    that different because it happens to permit efficient compilation.

     > so my guess is that collection based languages are the future. and i

    > do hope

    > that such collection oriented language is (optionally) strongly typed

     You may want to look at these:

        http://www-staff.it.uts.edu.au/~cbj/FISh/Announcement/

        http://www.sac-home.org/

    SaC is probably the most advanced language with shape inference, but

    it manages to do it by throwing away parametric polymorphism, ad hoc

    polymorphism, and higher order functions. As such, its use is limited.

    Typing something like J is currently out of the question.

    - John

## John Nowak — 2009-02-23 00:55:41

    On Feb 22, 2009, at 6:37 PM, John Nowak wrote:

     > Typing something like J is currently out of the question.

     I should be more clear. A typed J that eliminates all shape-related

    errors at runtime is not currently possible. A typed J that prevents

    some errors (e.g. attempting to mix atomic types within an array) but

    not others (e.g. 1 2 3 + 1 2) is certainly possible.

    - John

## Stevan Apter — 2009-02-23 15:58:30

    ----- Original Message -----

    From: "Robbert van Dalen" <robbert.van.dalen@...>

    To: <concatenative@yahoogroups.com>

    Sent: Sunday, February 22, 2009 5:11 PM

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

    >k and j is one of the few languages that really *forces* you to think

    > differently. i know, i'm still trying to wrap my head around it :)

    well, they want you to think *harder* about the *problem*, viz. to

    find "the array solution" (if there is one.)  a beginner's example:

    chop leading blanks from a string = (+/^\x=" ")_x.

        x:"   this has 3 leading blanks"

        x=" "

      1110001000101 ...

        ^\x=" "

      1110000000000 ...

        +/^\x=" "

      3

        3_x

      "this has 3 leading blanks"

    this solution has five primitives:  = ^ + / \, three "loops")

    (alternative:  ((x<>" ")?1b)_ x.  three primitives and one "loop".)

    >

    > that said, k's successor - q - is much more accessible. however,

    > (re-)reading q code can be as daunting as (re-)reading k code, especially if

    > the code is written by coding gurus like stevan :)

    whitney is the master.  here's the game of life in k:

        g:{3=a-x*4=a:2{+x+(1_x,0)+-1_0,x}/x}

    primitives:  = - * + _ / and transpose (+x ...)

    >

    > k and j are termed to be 'array' languages. but the way i see it is that an

    > array is a special, but very concrete case of a function. an array is a

    > function that maps (a consecutive domain of) integers to anything (untyped).

    absolutely right!  and k has a mapping primitive !, so the list 10 20 30 is

    (conceptually) just the map 0 1 2!10 20 30.

    >

    > the function is *the*unifying concept that works in many wondrous ways in k.

    > and  i believe *that* is the real power of k.

    yes, i think so too.

    >

    > i feel stevan is right about factor. sure, factor does force you to think

    > differently: the stack *does* that to you. but what really new concepts does

    > factor bring to the table? for example, for factor to be efficiently

    > compiled to a register based architecture, it must leave the stack model. it

    > also feeds my suspicion that - if a language primitive can be compiled to

    > x84 one-to-one - that language primitive is not far away from - say - a

    > pascal primitive.

    in fairness to slava, most languages look simple and clean until they

    leave the toy stage and get ramped up to do real work.  and i think

    people have been doing real work with factor.  i would say that the

    underlying problem is that factor doesn't have a high-level unifying vision

    of computation (like say lisp, prolog, or APL ... or enchilada for

    that matter).  ANY language which reduces computation in this way

    is going to demand that you do some extra thinking about the problem

    BEFORE you start coding.)

    the way i see the stack is that it's the price you pay for postfix

    syntax.  information is subtracted from expressions written in

    applicative syntax and shoved into the stack order.  to recover

    that information, you shuffle the stack around.  mentally, you're

    now doing work that the syntax previously did for you.  that *may*

    not be a bad trade-off.  it depends on whether the syntactic

    simplification offers new benefits in writing, extending, re-

    reading, &c., e.g. factoring.

    >

    > but how does k stack up against pascal? i believe k is a magnitude different

    > from pascal, because it puts collections *before* the scalars. and while k

    > is interpreted, it beats heavily optimized (and compiled) pascal programs in

    > many cases.

    this is true.

    >

    > so my guess is that collection based languages are the future. and i do hope

    > that such collection oriented language is (optionally) strongly typed, and

    > hopefully, written in postfix syntax :)

    well, i'm skeptical that collection-based languages will make any

    further headway, mainly for cultural/economic reasons.

    >

    > that's it: postfix syntax is the most economic way to *syntactically*

    > express computations. now match postfix with q and you might have to most

    > economical language ever...

    >

    > in the end, the primitives make the difference ....

    yes, i agree with this.

    >

    > are they scalar or ....?

    >

    > - robbert

    > On Sun, Feb 22, 2009 at 4:11 PM, Stevan Apter <sa@...> wrote:

    >

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

    >>

    >> when i'm programming, all my thinking takes place within a very

    >> simple framework: find a data representation for my problem, then

    >> find the best set of functions which transform these representations

    >> to solve my problem. r <- f[a;...;z]. iterate until done.

    >>

    >> as a k guy, two things about joy stood out immediately: (i) joy

    >> is a scalar language, and (ii) the syntax is concatenative and

    >> not applicative. but it turned out to be a simple matter to

    >> enhance joy (actually, the false language) with the k primitives

    >> (www.nsl.com/k//f/f.htm). ok, i had to think about "the stack",

    >> but that was a small price to pay for the reduction in syntactic

    >> complexity.

    >>

    >> factor is way too complicated for me. i gave up early on. i

    >> really don't want to think about the internals of the implementation

    >> when i'm coding. the ONLY thing i want floating around in my head

    >> in addition to the problem i'm working on is at most 20 or 30 purely

    >> functional primitives, and ideally these should be divided into a

    >> few classes of a few members each. (granted, i haven't kept up

    >> with factor development, so things might have gotten simpler, but

    >> that's not the direction things seemed to be taking a few years

    >> ago.)

    >>

    >> typing is another language feature i don't want to think about.

    >> i was discouraged from learning haskell because half the messages

    >> posted in their newsgroup involved some typing conundrum. the last

    >> thing i need is to get stopped in my tracks by one of these. don't

    >> get me wrong. the problems john and christopher are working on

    >> interest me, but there's no way i would ever use a language in

    >> my day job which required this extra level of attention. i guess

    >> the easiest way to put it is that i don't want my programs to

    >> fail in more than five or six ways.

    >>

    >> oddly enough, the only language proposed in this forum i can

    >> imagine using is enchilada, and that's mainly for two reasons:

    >> (i) i've seen robbert use the language to solve hard problems

    >> very easily, and (ii) whenever i tried to learn it, my brain

    >> exploded. those facts indicate to me that there are some

    >> powerful new ideas (but very simple ones) going on in that

    >> language. (i had the same experience reading john conway's

    >> book on surreal numbers many years ago.)

    >>

    >> now billy, who's a very creative thinker, has reported similar

    >> problems with j and k, so this might be (it probably is) entirely

    >> a matter of thinking-style, or maybe a function of what languages

    >> you learned first and used most.

    >>

    >> ----- Original Message -----

    >> From: "John Nowak" <john@... <john%40johnnowak.com>>

    >> To: <concatenative@yahoogroups.com <concatenative%40yahoogroups.com>>

    >> Sent: Saturday, February 21, 2009 4:49 AM

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

    >>

    >> >

    >> > On Feb 20, 2009, at 1:00 PM, Joe Bowbeer wrote:

    >> >

    >> >> As the old saying goes: in matters of taste, there's no argument.

    >> >

    >> > True, but I don't think syntax is a "matter of taste" the same way raw

    >> > eel is. Different syntaxes have different qualities. For example,

    >> > Scheme has a syntax that is well-suited to meta-programming and

    >> > structural editing. Joy's syntax makes algebraic manipulation very

    >> > easy. Such qualities aren't subjective or matters of taste.

    >> >

    >> > Of course, some elements of syntax are subjective. My concern though

    >> > is that it's too easy to throw out objectively useful things because

    >> > someone said "ewww" upon first seeing them.

    >> >

    >> > - John

    >> >

    >>

    >>

    >>

    >

    >

    > [Non-text portions of this message have been removed]

    >

    >

## William Tanksley — 2009-02-23 18:07:56

    Stevan Apter wrote:

     > the way i see the stack is that it's the price you pay for postfix

    > syntax.  information is subtracted from expressions written in

    > applicative syntax and shoved into the stack order.  to recover

    > that information, you shuffle the stack around.  mentally, you're

    > now doing work that the syntax previously did for you.  that *may*

    > not be a bad trade-off.  it depends on whether the syntactic

    > simplification offers new benefits in writing, extending, re-

    > reading, &c., e.g. factoring.

     I think this is a nuanced and accurate view of the situation. Yes, the

    applicative syntax carries information that can't be carried by the much

    lighter concatenative syntax.

    Because of this, converting from applicative to concatenative requires

    information processing, and the final result will normally be more

    verbose (because words, normally stack shuffle words, will be used to

    replace what used to be done with syntax).

    In fact, stack languages require MORE information than data-name

    languages, because every item is associated with a unique, non-constant

    stack depth. This additional information is troublesome to track, but

    does have one useful benefit: an optimizer can use it as a quick

    heuristic for how soon the data item will be used. This means that items

    deep in the stack can (conceptually) be stored in slower memory, while

    items at the top should be stored in fast registers or on a cache line.

    Because this information is actually present in every stack-based

    program and NOT present (in general) in non-stack programs, it means

    that when the optimizer uses it, it's actually using information that

    the programmer put there on purpose. Thus, when you're writing

    neat-looking stack code, you're accidentally writing efficient stack

    code.

    There's a big problem with this "insight" (which is not a new one).

    There's a LOT more information involved in assigning a total order to

    the stack than an optimizer can use. The optimizer can only assign a few

    datums to the registers and ten or twenty items to each cache line, and

    there's overhead from managing all those levels of caching. I'm not

    aware of any optimizer that actually manages more than two levels

    (register and memory); to the best of my knowledge, none of them try to

    manage cache beyond following simple best-practice static rules. This

    means that although every stack programmer tracks each level of the

    stack uniquely and in detail, the optimizer blurs out most of that

    information and uses only a few very broad levels.

     > well, i'm skeptical that collection-based languages will make any

    > further headway, mainly for cultural/economic reasons.

     I hope you're wrong.

    I think one severe problem with array languages has been the insularity

    of their application... Their notation was itself difficult to approach,

    and then their implementations were placed under extremely proprietary

    licenses, so that learning them would be profitable only when one is

    well-funded. The notation problem was gone with the introduction of J,

    although K improved on that; but the license problem is still present.

    Kx can take away every non-customer's ability to even run ANY K or Q

    software at any time, and the specific capabilities of such software is

    limited to what Kx wants to provide.

    A+ is open source, but it has the same notation problem as APL (and

    providing an ASCII encoding doesn't solve that; it's not what the

    language is designed for, and the shortcoming is immediately obvious).

    Q'NIAL is open source and has a nice encoding. After I learn Q (because

    of its excellent freely available book) I plan to learn Q'NIAL. I'm not

    confident in its design... The fact that the "I" stands for

    "Interpreted" makes me nervous. Perhaps the fact that I want to design

    an entirely different (stack based) language makes me happier.

    Anyhow, I have one more thing to add to this huge, inconclusive essay.

    Elsewhere in this thread there's been some discussion about static

    shapechecking of arrays. IMO, there's a huge win in making the stack

    static, but arrays dynamic. Arrays can represent iteration, while the

    stack represents sequencing.

    -Wm

## chris glur — 2009-02-24 02:59:25

    >> In practice, I think a lot of the extra surface area (redundancy,

    >> delimiters, grammatical rules) that is built into popular programming

    >> languages (as well as natural writing systems), is there to serve the human

    >> mind.

     Yes, of course, and what could be more important ?

    William Tanksley wrote:

     >That's unlikely. Yes, some of those features were deliberately

    >chosen; but most of them were 'chosen' for other reasons than

    >"because it's efficient for humans". Ease of parsing drove

    >Pascal's design; it's now clear that Pascal's strength is its

    >simplicity, not its particular choice of parsers.

     Yes, ease of parsing too was more important then. IMO it's irrelevant

    today. OTOH I was amazed how long a linux [C] pakage takes to compile.

    The bloke who tried Oberon [the Pascal descendant] for the first time,

    said he though the compiler was broken, because it just returned --

    finished the job < 1sec.

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

    Look how popular it was for the herd to gamble with their

    credit cards.

    ---------

    OK, reading further is this tread, I realise there's been a big

    misunderstanding, I agree 'natural languages are the worst disaster

    ito [in terms of] complexity. 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 ..........

     >>As Lojban reminds us, reasoned arguments do little to change people's

    >>preferences. As the old saying goes: in matters of taste, there's no

    >>argument.

    >Not so much. There are a LOT of people totally convinced by

    >Lojban at one time or another. My point was that in spite of

    >being convinced, they still couldn't learn Lojban up to the

    >point of fluency.

     'people convinced' or the SCIENTISTS who researched and designed it ?

    Finding the reason for its purported failure could make some PhDs ?

    BTW-related, I've got this further 'quirk' related to minimalist

    menu-driven programming: the same for natural languages - menu

    driven canonical form composer, which gives output in any

    languages. Firstly think of existing 'aviation talk' with syntax:

    1. who I'm calling; 2, who I AM, 3. Where I AM, 4. What I want.

    So a valid mesg. would be:--

    1. Brakpan ground control,

    2. bravo tango lima,

    3. approaching your airfiel from the south at 7'500 feet,

    4. requesting permission to join the circuit.

    You can't write poetry, but you could 'ask when the next bus

    arrives from X' in Korean or Zulu ?

    BTW. related: did any body ever understand the 'fractal thicket'?

    Don Groves wrote:-

     >Infix is eminently readable due to our early education but it

    >requires a more complicated compiler.

     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.

    --------------------

    John Nowak wrote:

     >Joy's syntax makes algebraic manipulation very easy.

     Is the data easily manipulatable or the 'programs

    structure transformable to prove its correctness' ?

     >Such qualities aren't subjective or matters of taste.

     Yes there are objective metrics.

    ----------------

    Stevan Apter gave valuable insight to his subjective view

     of PLs:

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

     >when i'm programming, all my thinking takes place within a very

    >simple framework: find a data representation for my problem,

    >then find the best set of functions which transform these

    >representations to solve my problem. r <- f[a;...;z]. iterate

    >until done.

     I like that:

      InitialData -->f[a;...;z]--> Solution

    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.

    With procedural languages, you 'leave NextToken(MaxOf(BlueOnes)'

    in the source code, and the compiler does the stack-shuffling.

    But AFAI-can-see the problem concept/statement is 'nested'

    that's why natural languages must handles 'nested concepts',

    so the PL must also handle nesting. So stack-push/pop is

    inevitable. But I want to off-load as much metal work to

    the compiler.

    OK, it seems difficult to get away from postfix.

    Thanks,

    == Chris Glur.

## John Cowan — 2009-02-24 03:04:04

    chris glur scripsit:

     > Yes, ease of parsing too was more important then. IMO it's irrelevant

    > today. OTOH I was amazed how long a linux [C] pakage takes to compile.

    > The bloke who tried Oberon [the Pascal descendant] for the first time,

    > said he though the compiler was broken, because it just returned --

    > finished the job < 1sec.

     There are C compilers that are that quick, notably the Plan 9 compiler.

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

     As I posted earlier, I very much doubt that the grammar has anything at

    all to do with that.

     > * work left to right, top to bottom:

    >   '7 -> counter' is better than counter := 7

     What about those of us who read from right to left?

     > 'people convinced' or the SCIENTISTS who researched and designed it ?

     I'm not even a scientist, never mind a SCIENTIST.

     > Finding the reason for its purported failure could make some PhDs ?

     Unfortunately no.

    --

    John Cowan              cowan@...          http://www.ccil.org/~cowan

    Historians aren't constantly confronted with people who carry on

    self-confidently about the rule against adultery in the sixth amendment to

    the Declamation of Independence, as written by Benjamin Hamilton. Computer

    scientists aren't always having to correct people who make bold assertions

    about the value of Objectivist Programming, as examplified in the HCNL

    entities stored in Relaxational Databases.  --Mark Liberman

## Don Groves — 2009-02-24 04:01:20

    On Feb 23, 2009, at 6:59 PM, chris glur wrote:

     >>> In practice, I think a lot of the extra surface area (redundancy,

    >>> delimiters, grammatical rules) that is built into popular

    >>> programming

    >>> languages (as well as natural writing systems), is there to serve

    >>> the human

    >>> mind.

    >

    > Yes, of course, and what could be more important ?

     Correctness?

     > OK, reading further is this tread, I realise there's been a big

    > misunderstanding, I agree 'natural languages are the worst disaster

    > ito [in terms of] complexity. 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"

     Most of us already do that. "cdr" made perfectly good sense to early

    Lispers as "contents of decrement register," but, I agree, "tail" would

    have been better even then.

     >  work left to right, top to bottom:

     Ah, so your "existing human/societal assets" refers to only those of

    the Western Hemisphere.

     >  '7 -> counter' is better than counter := 7

     But then how do you indicate a pointer? An arrow makes perfect

    sense for a pointer, no? Counter <- 7 could work though, since our

    already existing convention is for the variable to be on the left.

     > * iteration is more 'natural' than recursion - all things being

    >   equal ..........

     Only for someone not used to thinking recursively. In many cases

    though, iteration is less resource hungry. Of course, modern

    languages already convert recursion to iteration in those cases.

    --

    don

## John Cowan — 2009-02-24 04:20:29

    Don Groves scripsit:

     > Most of us already do that. "cdr" made perfectly good sense to early

    > Lispers as "contents of decrement register," but, I agree, "tail" would

    > have been better even then.

     I doubt if it made sense to anybody except the assembly-language hackers

    who implemented it.  "First" and "rest", I think, go back to nearly

    the beginning.

    --

    Values of beeta will give rise to dom!          John Cowan

    (5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan

    to rename '.' or '..' entries; see              cowan@...

    http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)

## Don Groves — 2009-02-24 04:35:42

    On Feb 23, 2009, at 8:20 PM, John Cowan wrote:

     > Don Groves scripsit:

    >

    >> Most of us already do that. "cdr" made perfectly good sense to early

    >> Lispers as "contents of decrement register," but, I agree, "tail"

    >> would

    >> have been better even then.

    >

    > I doubt if it made sense to anybody except the assembly-language

    > hackers

    > who implemented it.  "First" and "rest", I think, go back to nearly

    > the beginning.

     I thought those assembly language hackers were the early Lispers.

    --

    don

     > --

    > Values of beeta will give rise to dom!          John Cowan

    > (5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan

    > to rename '.' or '..' entries; see              cowan@...

    > http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)

## John Cowan — 2009-02-24 04:50:23

    Don Groves scripsit:

     > I thought those assembly language hackers were the early Lispers.

     Well, a subset of them.

    --

    Not to perambulate                 John Cowan <cowan@...>

        the corridors                  http://www.ccil.org/~cowan

    during the hours of repose

        in the boots of ascension.       --Sign in Austrian ski-resort hotel

## William Tanksley — 2009-02-24 15:49:51

    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

## William Tanksley — 2009-02-24 15:59:07

    Don Groves wrote:

     > I thought those assembly language hackers were the early Lispers.

     Lisp, like APL, was originally created as a tool for thought, not for

    computers. car and cdr could not have been in the original at all; they

    were an artifact of the first implementation.

    APL was actually used for a while before it was ever implemented on a

    computer. After it had been used a while for business process

    improvement, the first APL compiler was built by assigning graduate

    students who did not know APL to translate APL expressions into machine

    code; the intent was to test whether APL was clearer than other

    notations, including natural language. The result was, according to the

    person who carried out the experiment, a success; bugs were much rarer

    and the instructor had to spend much less time explaining than when the

    task was explained in natural language.

    This experiment tells us a lot about APL, natural languages,

    experimenters, and the proper care and feeding of graduate students.

     > don

     -Wm

## John Cowan — 2009-02-24 17:48:32

    William Tanksley scripsit:

     > I have to admit -- as someone pointed out --

     That would be me: author of _The Complete Lojban Language_ and coeditor

    of _What Is Lojban?_  I never learned much Lojban vocabulary, but at

    one time I understood Lojban grammar better than anyone else,

    despite not being a designer or non-trivial user of Lojban myself.

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

     Unambiguity was (and remains) an explicit design point.  Fluency is

    a much higher bar than learnability and usability.  People can and

    have learned Lojban in the way that people learn programming language,

    but being able to use it to express all your thoughts _in real time_,

    as in conversation, is a lot more like passing the Turing test.

    As it is, there are Lojban-only blogs, a Lojban-only mailing list, and

    a Lojban-only IRC channel, and there have been quite a few Lojban-only

    telephone calls.  But you can't live your life nor do business nor get

    an education through the medium of Lojban, and until at least some of

    that becomes possible, fluency is probably unattainable.  (There have

    been formal Lojban classes with instructors in the past; I think almost

    all learners are self-learners now.)

     > One possible reason for this is that the designer didn't know enough

    > about the problems to be able to do the design work.

     True, although there wasn't a single designer for everything, but an

    evolving design tradition.  Loglan/Lojban, like Lisp and Fortran, goes

    back to the 1950s.

     > The reason that this explanation seems possible to me is that the

    > designer wasn't a linguist,

     Hoo boy, you're not kidding.  James Cooke Brown was a games designer.

    He understood formal logic fairly well, but his grasp of linguistics

    was perilously close to zero.  A lot has been improved since then.

     > and even modern linguists and cognitive

    > scientists don't generally claim to know enough to achieve Lojban's

    > goals.

     True again.

    --

    John Cowan    http://ccil.org/~cowan  cowan@...

    'Tis the Linux rebellion / Let coders take their place,

    The Linux-nationale / Shall Microsoft outpace,

    We can write better programs / Our CPUs won't stall,

    So raise the penguin banner of / The Linux-nationale.  --Greg Baker

## John Cowan — 2009-02-24 17:51:47

    William Tanksley scripsit:

     > Lisp, like APL, was originally created as a tool for thought, not for

    > computers. car and cdr could not have been in the original at all; they

    > were an artifact of the first implementation.

     The "Early Lisp History" paper at

    http://www8.informatik.uni-erlangen.de/html/lisp/histlit1.html definitely

    shows otherwise: Lisp was designed from the beginning as a programming

    language, and was specific to the IBM 704: in addition to car and cdr,

    there were also cpr, csr, cir, and ctr selectors (and cwr to select the

    whole word) and corresponding setters, and two relatives of cons, consw

    (whole word) and consls (sublist).

    --

    Work hard,                                      John Cowan

    play hard,                                      cowan@...

    die young,                                      http://www.ccil.org/~cowan

    rot quickly.

## William Tanksley — 2009-02-24 19:19:05

    John Cowan wrote:

     > William Tanksley scripsit:

    > > Lisp, like APL, was originally created as a tool for thought, not for

    > > computers. car and cdr could not have been in the original at all; they

    > > were an artifact of the first implementation.

    > The "Early Lisp History" paper at

    > http://www8.informatik.uni-erlangen.de/html/lisp/histlit1.html definitely

    > shows otherwise: Lisp was designed from the beginning as a programming

    > language,

     This wouldn't be the first time that Wikipedia got something wrong, but

    it cites Paul Graham as quoting McCarthy saying, "Steve Russell said,

    look, why don't I program this eval..., and I said to him, ho, ho,

    you're confusing theory with practice, this eval is intended for

    reading, not for computing. But he went ahead and did it. That is, he

    compiled the eval in my paper into IBM 704 machine code, fixing bug ,

    and then advertised this as a Lisp interpreter, which it certainly was.

    So at that point Lisp had essentially the form that it has today..."

    This also wouldn't be the first time that Paul Graham got something

    wrong. :-) As much as I enjoyed his "On Lisp" book.

    I think you're right and Wikipedia (at best) is failing to apply proper

    context to Graham's quote; he was probably talking about how the

    precursor to LISP (which used a different syntax) became LISP.

    -Wm

## John Cowan — 2009-02-24 19:51:14

    William Tanksley scripsit:

     > I think you're right and Wikipedia (at best) is failing to apply proper

    > context to Graham's quote; he was probably talking about how the

    > precursor to LISP (which used a different syntax) became LISP.

     Just so.

    Also, McCarthy's memory is fallible (not suprising at age 81) and has

    many times been proved wrong with reference to original documents.

    --

    John Cowan   http://ccil.org/~cowan  cowan@...

    [P]olice in many lands are now complaining that local arrestees are insisting

    on having their Miranda rights read to them, just like perps in American TV

    cop shows.  When it's explained to them that they are in a different country,

    where those rights do not exist, they become outraged.  --Neal Stephenson

## John Nowak — 2009-02-24 20:13:47

    On Feb 24, 2009, at 10:49 AM, William Tanksley wrote:

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

     A concatenative-style FP-like language doesn't need shufflers. You can

    define them if you want, but they're not really useful. The trick, it

    seems to me, is to get rid of the stack and only enlist items when

    dealing with two or more. This is the trick to making construction

    (aka 'cleave') really useful.

    As an example, here's the definition of 'map' in a Joy-like language:

        map = [swap null?] [drop] [[uncons] dip [dip] keep map cons] ifte

    And here's the same thing in an FP-like language. You read right to

    left instead of left to right. 'a' is defined as 'head' and 'b' is

    defined as 'head tail'. Parentheses are cleave and brackets are

    quotation:

        map = if([null? a],

                 [a],

                 [cons(i(head a, b),

                       map(tail a, b))])

    (Apologies if you're not using a monospace font.)

    Essentially, you make heavier use of a cleave-like form to add some

    useful "nesting" to the language.

    I'm pretty sold on the FP-style approach at this point. I find it much

    easier to work with than dealing with a stack and it retains all of

    the properties I'm after. I do, however, prefer a first-order approach

    with compile-time substitution for functions. Some additional syntax

    for conditionals is also useful. For example:

        map[F] = null? -> id; cons[F head, map[F] tail]

    Not sure if this all makes sense. My point is this: Concatenative

    languages don't necessarily need shufflers. Only stack-based

    concatenative languages do.

    - John

## Daniel Ehrenberg — 2009-02-24 20:29:10

    Have you written anything non-trivial with this system? Before you go

    ahead and spend a lot of time using this formalism, I suggest you

    write a few hundred lines of useful code, and run it in a simple

    hacked-up interpreter if you don't have a full compiler yet. This will

    show you how appropriate the system is for expressing the flow of data

    elegantly.

    Dan

     > A concatenative-style FP-like language doesn't need shufflers. You can

    > define them if you want, but they're not really useful. The trick, it

    > seems to me, is to get rid of the stack and only enlist items when

    > dealing with two or more. This is the trick to making construction

    > (aka 'cleave') really useful.

    >

    > As an example, here's the definition of 'map' in a Joy-like language:

    >

    > map = [swap null?] [drop] [[uncons] dip [dip] keep map cons] ifte

    >

    > And here's the same thing in an FP-like language. You read right to

    > left instead of left to right. 'a' is defined as 'head' and 'b' is

    > defined as 'head tail'. Parentheses are cleave and brackets are

    > quotation:

    >

    > map = if([null? a],

    > [a],

    > [cons(i(head a, b),

    > map(tail a, b))])

    >

    > (Apologies if you're not using a monospace font.)

    >

    > Essentially, you make heavier use of a cleave-like form to add some

    > useful "nesting" to the language.

    >

    > I'm pretty sold on the FP-style approach at this point. I find it much

    > easier to work with than dealing with a stack and it retains all of

    > the properties I'm after. I do, however, prefer a first-order approach

    > with compile-time substitution for functions. Some additional syntax

    > for conditionals is also useful. For example:

    >

    > map[F] = null? -> id; cons[F head, map[F] tail]

    >

    > Not sure if this all makes sense. My point is this: Concatenative

    > languages don't necessarily need shufflers. Only stack-based

    > concatenative languages do.

    >

    > - John

    >

## John Nowak — 2009-02-24 20:41:26

    On Feb 24, 2009, at 3:29 PM, Daniel Ehrenberg wrote:

     > Have you written anything non-trivial with this system? Before you go

    > ahead and spend a lot of time using this formalism, I suggest you

    > write a few hundred lines of useful code, and run it in a simple

    > hacked-up interpreter if you don't have a full compiler yet. This will

    > show you how appropriate the system is for expressing the flow of data

    > elegantly.

     I just posted Felix Winkelmann's FP -> C compiler to the list. It is

    written in FP and certainly represents a non-trivial program (of

    roughly 1500 lines).

    - John

## William Tanksley — 2009-02-24 21:03:29

    John Nowak wrote:

     > William Tanksley wrote:

    > And here's the same thing in an FP-like language. You read right to

    > left instead of left to right. 'a' is defined as 'head' and 'b' is

    > defined as 'head tail'. Parentheses are cleave and brackets are

    > quotation:

    >     map = if([null? a],

    >              [a],

    >              [cons(i(head a, b),

    >                    map(tail a, b))])

     This looks very much like an applicative language with optional

    parentheses for single-argument functions.

     > Essentially, you make heavier use of a cleave-like form to add some

    > useful "nesting" to the language.

     I agree with the concept of adding nesting to express forms; but I don't

    see the form in this case.

     > I'm pretty sold on the FP-style approach at this point. I find it much

    > easier to work with than dealing with a stack and it retains all of

    > the properties I'm after.

     My understanding is that "an FP approach" (function-level programming)

    works very well with a stack, so I'm not particularly enlightened on

    what this means.

     > I do, however, prefer a first-order approach

    > with compile-time substitution for functions. Some additional syntax

    > for conditionals is also useful. For example:

    >     map[F] = null? -> id; cons[F head, map[F] tail]

     Here you're clearly defining an adverb, and your language doesn't allow

    functions to be passed on the stack. I like this, but once again, this

    isn't an example of a concatenative language without a stack, because

    there's no concatenation happening.

     > Not sure if this all makes sense. My point is this: Concatenative

    > languages don't necessarily need shufflers. Only stack-based

    > concatenative languages do.

     You haven't offered an example of a concatenative language without

    shufflers. Your best approach was (in the wikipedia thread):

    a = hd

    b = hd tl

    c = hd tl tl

    hypot = sqrt + [sq a, sq b]

    ...the problem is that in this language even this trivial example

    requires the 'hd' and 'tl' shufflers.

    Nonetheless I'm starting to see your point in this language, I think.

    Every function takes and produces one datum, which is a tuple.

    Meanwhile, a literal tuple is also a function of one argument, and that

    argument will be passed to all of the components of the list.

    Conceptually, the big difference between this and a stack-based language

    -- if I'm reading it correctly -- is that this language uses a data tree

    rather than a data stack. That's fascinating!

    So how do nodes of this tree get constructed? I can see that once

    they're constructed your language can pass them around and generate new

    trees (or, equivalently, mutate the existing tree), but I don't see how

    to express a cons.

     > - John

     -Wm

## Stevan Apter — 2009-02-24 21:16:11

    >

    > Nonetheless I'm starting to see your point in this language, I think.

    > Every function takes and produces one datum, which is a tuple.

    > Meanwhile, a literal tuple is also a function of one argument, and that

    > argument will be passed to all of the components of the list.

    >

    > Conceptually, the big difference between this and a stack-based language

    > -- if I'm reading it correctly -- is that this language uses a data tree

    > rather than a data stack. That's fascinating!

     this is starting to look/sound like enchilada.

    robbert?

     >

    > So how do nodes of this tree get constructed? I can see that once

    > they're constructed your language can pass them around and generate new

    > trees (or, equivalently, mutate the existing tree), but I don't see how

    > to express a cons.

    >

    >> - John

    >

    > -Wm

    >

    >

    >

## John Nowak — 2009-02-24 22:08:53

    On Feb 24, 2009, at 4:03 PM, William Tanksley wrote:

     > This looks very much like an applicative language with optional

    > parentheses for single-argument functions.

     Aye, that's the idea.

     >> Essentially, you make heavier use of a cleave-like form to add some

    >> useful "nesting" to the language.

    >

    > I agree with the concept of adding nesting to express forms; but I

    > don't

    > see the form in this case.

     Not quite sure what you mean by "don't see the form".

     > My understanding is that "an FP approach" (function-level programming)

    > works very well with a stack, so I'm not particularly enlightened on

    > what this means.

     Oh, the stack does work for functional-level programming. By "an FP

    approach", I simply meant something more like Backus's FP language.

    Getting rid of the stack though is necessary to make cleave more useful.

    One problem with cleave in a stack-based language is that you need one

    version for every number of items you want to pass to the cleave. This

    is because the entire state of the program is passed to every function

    and you need to "tell" the cleave how many items it cases about. This

    is not the case in FP.

    Additionally, functions do not return a list/stack in the FP approach

    when just returning a "single" value. This allows you to do something

    like '[id, id] 5' and get '[5, 5]' instead of a tuple of two stacks

    containing 5 (which is considerably more difficult to operate on).

    This works because the '5' is just '5', not a stack containing '5'.

    Another benefit of the FP approach to construction is that functions

    in the construction cannot interact. This is not the case with cleave

    as I've pointed out previously.

    Finally, construction in FP always returns N elements where N is the

    number of functions used in the construction. This is *much& easier to

    deal with than cleave in a stack-based language where the output of

    each cleave is essentially concatenated together into a flat stack.

    For example, say you have the program 'hd [foo, bar]'. If you know

    that 'bar' terminates, you can simplify this program to 'foo' without

    knowing the arities of 'foo' and 'bar'. You cannot do this with cleave

    in a stack-based language. Similarly, you get nice properties like

    distributivity that allows you to convert '[foo, bar] baz quux' to

    '[foo baz, bar baz] quux', and so on.

    Hopefully that ramble makes some sense. I've done a lot of thinking

    about why cleave works better in FP, but I'm still having a bit of

    trouble articulating it.

     >> for conditionals is also useful. For example:

    >>    map[F] = null? -> id; cons[F head, map[F] tail]

    >

    > Here you're clearly defining an adverb, and your language doesn't

    > allow

    > functions to be passed on the stack.

     Yes that's true. To be clear, the earlier example I gave did offer

    first class functions.

     > I like this, but once again, this isn't an example of a

    > concatenative language without a stack, because there's no

    > concatenation happening.

     Well there is, just not much of it in that particular example. All of

    the usual associative laws of concatenative languages apply:

        APPENDING:

        a c == b c IF a == b

        PREPENDING:

        c a == c b IF a == b

        FACTORING:

        a f d == e IF f == b c AND a b c d == e

    You also get new distributive laws related to construction as

    mentioned above.

     > You haven't offered an example of a concatenative language without

    > shufflers. Your best approach was (in the wikipedia thread):

    > ...

    > hypot = sqrt + [sq a, sq b]

     This is the same language I just used to give the map example except

    that I swapped the meaning of () and []. I'll go back to using [] to

    mean construction.

     > ...the problem is that in this language even this trivial example

    > requires the 'hd' and 'tl' shufflers.

     Yes, but they're not really "shufflers" like swap, rot, tuck, dup,

    etc. You can even define pseudo-variables in terms of 'hd' and 'tl'.

    For example:

        hypot[length, width] = sqrt +[sq length, sq width]

    Here, 'length' is really 'hd' and 'width' is really 'hd tl'. A simple

    substitution of 'hd' for 'length' and 'hd tl' for 'width' will get you

    a point-free program. The compiler can check that the pseudo-variables

    are not used in a way that would prevent this trivial substitution

    from being valid. For example, the following would be illegal because

    'x' cannot be easily replaced with 'hd' to get a point-free program:

        foo[x, y] = x[y, x]

    The rule for what is and isn't legal is a bit more than I want to

    state here but it's not too bad. It's never something I have to think

    about when programming; it tends to flow naturally.

    I should note that Backus's FL and Felix's FP offer such a mechanism

    for defining pseudo-variables. The important thing to remember here is

    that they're just syntactic sugar and not a core part of the semantics

    like they are in languages based on substitution.

     > Conceptually, the big difference between this and a stack-based

    > language

    > -- if I'm reading it correctly -- is that this language uses a data

    > tree

    > rather than a data stack. That's fascinating!

     Yes, that's exactly it! Much better way of putting it than I've been

    using.

     > So how do nodes of this tree get constructed? I can see that once

    > they're constructed your language can pass them around and generate

    > new trees (or, equivalently, mutate the existing tree), but I don't

    > see how to express a cons.

     I'm not quite sure what you're asking here, so I'll guess.

    Construction doubles as a list syntax. For example, the function '[1,

    2, 3, 4, 5]' always returns a list containing the numbers one through

    five. This is because '1' is just a constant function that, when

    applied to anything, returns the value 1. This is different from a

    stack-based language where '1' is a function that pushes the value 1

    onto the stack.

    (Note that Backus's FP is a different here: '~1' denotes the function

    that returns the value 1 and '1' denotes the value one. I dislike this

    as it is incompatible with the property of concatenative languages

    where the simplification of a function is another function. This is

    why I've adopted the approach of having '1' represent a constant

    function.)

    Not sure if that helps at all. Probably not. Feel free to try again...

    - John

## John Nowak — 2009-02-24 22:20:16

    On Feb 24, 2009, at 5:08 PM, John Nowak wrote:

    Minor corrections, sorry.

    > This  is because the entire state of the program is passed to every

    > function

    > and you need to "tell" the cleave how many items it cases about.

    That should be "cares about". In other words, you need cleave,

    2cleave, 3cleave, etc in Joy. You don't need this in FP.

    > (Note that Backus's FP is a different here: '~1' denotes the function

    > that returns the value 1 and '1' denotes the value one. I dislike this

    > as it is incompatible with the property of concatenative languages

    > where the simplification of a function is another function. This is

    > why I've adopted the approach of having '1' represent a constant

    > function.)

    Simplification is the wrong word here. I really mean a partial

    reduction or something to that effect. For example, in Joy, the

    function '1 2 + 3 +' can be partially reduced to the function '3 3 +'.

    The small change I'm making to the syntax of FP ensures this same sort

    of property holds there as well. For example, the function '+[+[1, 2],

    3]' can be partially reduced to the function '+[3, 3]', which can then

    be further reduced to the function '6'.

    - John

## Stevan Apter — 2009-02-25 16:29:17

    howzabout writing up a spec for your proposed language?  it would be

    handy to have it all in a single doc, instead of spread over several

    weeks of emails.  i thought you'd written up a wiki somewhere, but

    i haven't been able to locate it.

     ----- Original Message -----

    From: "John Nowak" <john@...>

    To: <concatenative@yahoogroups.com>

    Sent: Tuesday, February 24, 2009 5:20 PM

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

    >

    > On Feb 24, 2009, at 5:08 PM, John Nowak wrote:

    >

    > Minor corrections, sorry.

    >

    >> This  is because the entire state of the program is passed to every

    >> function

    >> and you need to "tell" the cleave how many items it cases about.

    >

    > That should be "cares about". In other words, you need cleave,

    > 2cleave, 3cleave, etc in Joy. You don't need this in FP.

    >

    >> (Note that Backus's FP is a different here: '~1' denotes the function

    >> that returns the value 1 and '1' denotes the value one. I dislike this

    >> as it is incompatible with the property of concatenative languages

    >> where the simplification of a function is another function. This is

    >> why I've adopted the approach of having '1' represent a constant

    >> function.)

    >

    > Simplification is the wrong word here. I really mean a partial

    > reduction or something to that effect. For example, in Joy, the

    > function '1 2 + 3 +' can be partially reduced to the function '3 3 +'.

    > The small change I'm making to the syntax of FP ensures this same sort

    > of property holds there as well. For example, the function '+[+[1, 2],

    > 3]' can be partially reduced to the function '+[3, 3]', which can then

    > be further reduced to the function '6'.

    >

    > - John

    >

## John Nowak — 2009-02-26 00:16:13

    On Feb 25, 2009, at 11:29 AM, Stevan Apter wrote:

     > howzabout writing up a spec for your proposed language?  it would be

    > handy to have it all in a single doc, instead of spread over several

    > weeks of emails.

     Tell me about it. I'm going to pour through the list archives and

    collect my progress. Apologies if this list sometimes seems like my

    personal idea pad; that's not the intent.

    - John

## John Nowak — 2009-02-26 00:18:15

    On Feb 25, 2009, at 7:16 PM, John Nowak wrote:

     > On Feb 25, 2009, at 11:29 AM, Stevan Apter wrote:

    >

    >> howzabout writing up a spec for your proposed language?  it would be

    >> handy to have it all in a single doc, instead of spread over several

    >> weeks of emails.

    >

    > Tell me about it. I'm going to pour through the list archives and

    > collect my progress.

     I'm also going to pore through the list archives.

    Egh.

    - John

## Don Groves — 2009-02-26 00:28:39

    On Feb 25, 2009, at 4:16 PM, John Nowak wrote:

     >

    > On Feb 25, 2009, at 11:29 AM, Stevan Apter wrote:

    >

    >> howzabout writing up a spec for your proposed language?  it would be

    >> handy to have it all in a single doc, instead of spread over several

    >> weeks of emails.

    >

    > Tell me about it. I'm going to pour through the list archives and

    > collect my progress. Apologies if this list sometimes seems like my

    > personal idea pad; that's not the intent.

     No apology necessary, ideas are what we are all about, no?

    --

    don

     > - John

    >

    >

    > ------------------------------------

    >

    > Yahoo! Groups Links

    >

    >

    >

## chris glur — 2009-02-26 14:00:09

    John Cowan wrote:-

     >Here's Shieber's 1985 paper nailing down the non-CF-ness of Swiss

    > German: http://www.eecs.harvard.edu/~shieber/Biblio/Papers/shieber85.pdf

     I'd love to know what he tells, but working from

    3rd-world [S.A becoming 4th-world] I can't d/l

    6M2 pdfs !

    Wirth [the Pascal, Modula, Oberon] hi-priest, a native Swiss-german,

    has a remarkable english-text writing style which I've been trying

    [unsuccessfuly] to analyse.

    Is Lojban a minalal syntax, canonical, framework ?

    I speculate that such a system would allow english, russian, japanese

    collaborators to communicate -- in writing, so fluency becaomes

    irrelevant.

    == Chris Glur.

## William Tanksley — 2009-02-26 15:41:20

    chris glur wrote:

     > Is Lojban a minalal syntax, canonical, framework ?

     I don't know what you mean; but Lojban probably one of the simpler

    syntaxes of the constructed languages, but its semantics is complex.

    There are some derivatives that attempt to make the semantics more

    closely tied to syntax, but they don't have as much work done on them,

    so they're probably not suitable for immediate use.

     > I speculate that such a system would allow english, russian, japanese

    > collaborators to communicate -- in writing, so fluency becaomes

    > irrelevant.

     Fluency is always relevant.

    A lot of work has been done with Esperanto and Ido (there are huge

    communities); on the other hand, "Basic English" is a commonly used

    standard subset of English that isn't as hard to learn (although it'll

    be deceptively hard for a native English speaker to write, since it's

    very much more restricted so that non-native speakers will have an

    easier time learning it).

     > == Chris Glur.

     -Wm

## John Cowan — 2009-02-26 16:01:41

    chris glur scripsit:

     > I'd love to know what he tells, but working from

    > 3rd-world [S.A becoming 4th-world] I can't d/l

    > 6M2 pdfs !

     Sure.  The PDF is a scanned image of the original paper article, which

    is why it is so big.

    Here's the argument in a nutshell.  In English we can have sentences

    like "Frank said that John saw Mary help Peter make the children swim",

    which parses as "Frank said (that John saw (Mary help (Peter make (the

    children swim))))."  Because all the embedding is on the right, this

    can be processed iteratively, and anglophones have no trouble with it.

    The other Germanic languages, however, like their verbs at the end

    in subordinate clauses.  In German the expected equivalent would be

    recursive: "Frank said (that John (that Mary (that Peter (that the

    children swim) make) help) saw)", but this is too complex for unaided

    human minds to parse: the stack overflows silently, and when we get to

    "swim make help saw" we cannot retrieve the supposedly stacked contexts

    any more.  So the sentence must be broken up and re-expressed using

    simpler pieces.

    Dutch and Swiss German, however, can use what is called a cross-serial

    dependency in cases like this: the verbs appear in the same order

    as the objects rather than in the opposite order, thus:  "Frank said

    (that John_1 Mary_2 Peter_3 the children_4 saw_1 help_2 make_3 swim_4)."

    Apparently, this is *not* beyond human ability to comprehend, and such

    sentences can get arbitrarily large.

    Now in the Dutch case, it is possible to construct a context-free parse

    that will handle this sentence, even though it associates the wrong

    verbs and objects, namely "Frank said (that John (Mary (Peter (the

    children saw) help) make) swim)."  Even though this parse is nonsense

    (corresponding to English "Frank said that John swam Mary make Peter

    help the children see"), it *is* a parse.  So Dutch can be parsed by a

    context-free parser provided you don't care about its semantics.

    Swiss German, however, cannot.  The reason is that Swiss German verbs are

    divisible into two classes, those which take accusative objects and those

    which take dative objects, and the distinction is marked on the nouns.

    Thus in Swiss German we must say "Frank said that John-ACC Mary-ACC

    Peter-DAT the children-ACC saw help make swim", and the Dutch trick will

    not get the right case endings on the right nouns, or even guarantee

    that there is the right *number* of accusative- and dative-marked nouns

    to correspond with the verbs.

    So Swiss German is mildly context-sensitive, and therefore so is natural

    language.

     > Wirth [the Pascal, Modula, Oberon] hi-priest, a native Swiss-german,

    > has a remarkable english-text writing style which I've been trying

    > [unsuccessfuly] to analyse.

     When asked by an anglophone how to pronounce his name, he replied

    "You may call me by value, and call me Worth, or you may call me

    by name, and call me Veert."

     > Is Lojban a minalal syntax, canonical, framework ?

     I hardly know whether to answer yes or no.  It's a natural language

    (except that it is artificially constructed rather than naturally

    evolved), complete with a general-purpose phonology, syntax, lexicon, etc.

    But it has the special property that it is syntactically unambiguous.

    All sentences have only one possible parse.

     > I speculate that such a system would allow english, russian, japanese

    > collaborators to communicate -- in writing, so fluency becaomes

    > irrelevant.

     Indeed.

    --

    John Cowan  cowan@...    http://ccil.org/~cowan

    No man is an island, entire of itself; every man is a piece of the

    continent, a part of the main.  If a clod be washed away by the sea,

    Europe is the less, as well as if a promontory were, as well as if a

    manor of thy friends or of thine own were: any man's death diminishes me,

    because I am involved in mankind, and therefore never send to know for

    whom the bell tolls; it tolls for thee.  --John Donne

## eas lab — 2009-02-26 16:10:31

    We seem to agree that 'human factor' is prime in compter-productivety.

    And that its hard to analyse/talk-about.

    But as JFK said "we're not doing it because it's easy .."

    So when reading :

    http://concatenative.org/wiki/view/Concatenative%20language/Name

       %20code%20not%20values

    and appreciating some advantages of 'cat', when I felt very uncomfortable

    with: ----------

     > extract

       Here is another dataflow pattern:

    var x = ...;

    bar(x,foo(x));

       In Factor, we call this dup. If the value x is at the top of the

       stack,

    dup foo bar

       applies foo to x, then applies bar to x and the result from foo.

     > end extract ===========

      I decided to dig deeper, and found:

    The reason why this is BAD compared to a blok-structured procedural langs.

    is that it doesn't 'express in the problem domain notation'.

    YOU have to 'factor' instead of writing in the problem-domain

    notation, and allowing

    the compiler to factor [for optimisation if it 'wants' to].

    Ie. if I write: UsePaintColorFor (red, red(dog)), I'm writing ito the

    problem-domain:

    'what colour paint to use on what item'. And I'm not interested in optimising

    technically that 'red' can be factored out.

    This is the same 'problem' as with forth: I have to do the stack

    shuffling, instead

    of having the compiler do it.

    Thanks,

    == Chris Glur.

## John Cowan — 2009-02-26 16:17:23

    William Tanksley scripsit:

     > A lot of work has been done with Esperanto and Ido (there are huge

    > communities); on the other hand, "Basic English" is a commonly used

    > standard subset of English that isn't as hard to learn (although it'll

    > be deceptively hard for a native English speaker to write, since it's

    > very much more restricted so that non-native speakers will have an

    > easier time learning it).

     If you mean Ogden's Basic English, it's hopeless as a subset language,

    because its semantics is relentlessly non-compositional: to say "succeed"

    you say "make good" or "do well", but the meanings of "make" and "good",

    or of "do" and "well", have nothing to do with succeeding.

    What's more, you cannot coin new words, so "The officer led his soldiers

    against the enemy" turns into "The person in military authority was the

    guide of his men in the army against the nation at war".

    See

    http://recycledknowledge.blogspot.com/2005/06/why-basic-english-doesnt-work.html

    for more details.

    There are less drastically impaired simplified Englishes

    out there, like the Voice of America's Special English: see

    http://www.voanews.com/specialenglish/about_special_english.cfm .

    --

    If you understand,                      John Cowan

       things are just as they are;         http://www.ccil.org/~cowan

    if you do not understand,               cowan@...

       things are just as they are.

## John Nowak — 2009-02-26 16:26:40

    On Feb 26, 2009, at 11:01 AM, John Cowan wrote:

     > The other Germanic languages, however, like their verbs at the end

    > in subordinate clauses.  In German the expected equivalent would be

    > recursive: "Frank said (that John (that Mary (that Peter (that the

    > children swim) make) help) saw)", but this is too complex for unaided

    > human minds to parse: the stack overflows silently, and when we get to

    > "swim make help saw" we cannot retrieve the supposedly stacked

    > contexts

    > any more.  So the sentence must be broken up and re-expressed using

    > simpler pieces.

     Very interesting. The analogy to stack-based languages is certainly

    very clear (if unfortunate).

    - John

## William Tanksley — 2009-02-26 16:40:42

    This is barely relevant to concatenative anymore...

    John Cowan wrote:

     > William Tanksley scripsit:

    > > A lot of work has been done with Esperanto and Ido (there are huge

    > > communities); on the other hand, "Basic English" is a commonly used

    > > standard subset of English that isn't as hard to learn (although it'll

    > > be deceptively hard for a native English speaker to write, since it's

    > > very much more restricted so that non-native speakers will have an

    > > easier time learning it).

    > If you mean Ogden's Basic English, it's hopeless as a subset language,

    > because its semantics is relentlessly non-compositional: to say "succeed"

    > you say "make good" or "do well", but the meanings of "make" and "good",

    > or of "do" and "well", have nothing to do with succeeding.

     I don't quite understand. Do you mean that Ogden defined idioms for BE

    in an attempt to reduce the word-vocabulary? That is very interesting.

    It sounds like a serious potential problem: the word-vocabulary is

    small, but the idiom-vocabulary might be unmanageably large. Is that the

    case? I can't tell from your post.

     > See

    > http://recycledknowledge.blogspot.com/2005/06/why-basic-english-doesnt-work.html

    > for more details.

     Actually, that post has LESS details -- you give more examples, but you

    don't explain why these problems are actually inherent to the language

    rather than just problems with the examples you chose. Anyone can choose

    bad examples and make a language look bad.

    I'm not saying you're wrong (nor malicious); I'm just saying that I

    don't understand your explanation.

     > There are less drastically impaired simplified Englishes

    > out there, like the Voice of America's Special English: see

    > http://www.voanews.com/specialenglish/about_special_english.cfm .

     Thank you -- interesting. Special English appears to be much better

    tested than Basic English; I definitely accept your recommendation on

    that basis. A glance through Wikipedia shows other interesting

    English-derived standard simplified languages.

    I note that Wikipedia has a Special English translation of its own.

    -Wm

## John Cowan — 2009-02-26 16:59:32

    William Tanksley scripsit:

     > I don't quite understand. Do you mean that Ogden defined idioms for BE

    > in an attempt to reduce the word-vocabulary? That is very interesting.

     No, he just licensed the use of any and all such idioms that already exist

    in Full English.  So "put out" in BE may mean not only "place outside",

    but also "expel", "anger", or "copulate", just as in FE.

     > It sounds like a serious potential problem: the word-vocabulary is

    > small, but the idiom-vocabulary might be unmanageably large. Is that the

    > case? I can't tell from your post.

     Yes, that's what I meant.

    --

    All Gaul is divided into three parts: the part          John Cowan

    that cooks with lard and goose fat, the part            http://ccil.org/~cowan

    that cooks with olive oil, and the part that            cowan@...

    cooks with butter. --David Chessler

## William Tanksley — 2009-02-26 17:41:31

    John Cowan wrote:

     > William Tanksley scripsit:

    > > I don't quite understand. Do you mean that Ogden defined idioms for BE

    > > in an attempt to reduce the word-vocabulary? That is very interesting.

    > No, he just licensed the use of any and all such idioms that already exist

    > in Full English.  So "put out" in BE may mean not only "place outside",

    > but also "expel", "anger", or "copulate", just as in FE.

     That is truly terrible. It baffles me that he didn't realize what a bad

    idea that was. In other words, anyone may use any sequence of words to

    mean anything; but you're not allowed invent a new word.

    That's the worst of all worlds: the reader can't recognise a new concept

    as unknown to you, AND the writer can't tersely express new concepts.

    I see why you're unhappy with it.

    -Wm

## eas lab — 2009-03-13 02:27:17

    Thanks to John Cowan's ample explanation of Lojban & Dutch/Swiss-German

    structure. I want to investigate this further - later.

    IMO the  Lojban idea [as I understand it so far] has great merit.

    The emphasis on fluency/speed-of-output reminds me of the

    bloke who boasts that his CPU is 10 times faster: so he can save

    5 msec. of CPU time for the 2 hour job.

    IMO natural languages are a disaster for scientific work.

    We need to move to constrained/designed syntax.

    I wonder how Korean-script is ?

    It apparently was designed, instead of evolved ?

    IMO the aviation industry leads in the way of how procedures

    ought-to/will be in future; eg. their syntax is minimal & constrained,

     as proven appropriate to reduce accidents.

    I speculate that they should/will replace natural/talk by 'elect'

     mesgs.  Although sound has the advantage that it can 'interrupt'

     and be an input-channel additional to sight.

    I'm going to goog to find out how to join/test the Lojban

    community.     Being of the dominant language/culture can cause

    you to miss a lot of 'value' of the other-side/s.

    Yesterday I debugged my ex's 'misunderstanding', which may be

    due to the gender or that she's Finnish: she insists that "it's in the

    right passage of the area of the building", wheras I say "after you

    enter, you turn left and then right, so it's the left passage".

    OTOH for a vehicle/boat the left/right is considered from inside.

    And for a house, from inside looking towards the front-door.

    Since the area in the building has a single door/entry,

    seeing the area like a house, you turn left to go to the right

    passage.  So the foreigner/wrong-gender is not so wrong ?

    Thanks,

    == Chris Glur

     On 2/24/09, John Cowan <cowan@...> wrote:

    > William Tanksley scripsit:

    >

    >> I have to admit -- as someone pointed out --

    >

    > That would be me: author of _The Complete Lojban Language_ and coeditor

    > of _What Is Lojban?_  I never learned much Lojban vocabulary, but at

    > one time I understood Lojban grammar better than anyone else,

    > despite not being a designer or non-trivial user of Lojban myself.

    >

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

    >

    > Unambiguity was (and remains) an explicit design point.  Fluency is

    > a much higher bar than learnability and usability.  People can and

    > have learned Lojban in the way that people learn programming language,

    > but being able to use it to express all your thoughts _in real time_,

    > as in conversation, is a lot more like passing the Turing test.

    >

    > As it is, there are Lojban-only blogs, a Lojban-only mailing list, and

    > a Lojban-only IRC channel, and there have been quite a few Lojban-only

    > telephone calls.  But you can't live your life nor do business nor get

    > an education through the medium of Lojban, and until at least some of

    > that becomes possible, fluency is probably unattainable.  (There have

    > been formal Lojban classes with instructors in the past; I think almost

    > all learners are self-learners now.)

    >

    >> One possible reason for this is that the designer didn't know enough

    >> about the problems to be able to do the design work.

    >

    > True, although there wasn't a single designer for everything, but an

    > evolving design tradition.  Loglan/Lojban, like Lisp and Fortran, goes

    > back to the 1950s.

    >

    >> The reason that this explanation seems possible to me is that the

    >> designer wasn't a linguist,

    >

    > Hoo boy, you're not kidding.  James Cooke Brown was a games designer.

    > He understood formal logic fairly well, but his grasp of linguistics

    > was perilously close to zero.  A lot has been improved since then.

    >

    >> and even modern linguists and cognitive

    >> scientists don't generally claim to know enough to achieve Lojban's

    >> goals.

    >

    > True again.

    >

    > --

    > John Cowan    http://ccil.org/~cowan  cowan@...

    > 'Tis the Linux rebellion / Let coders take their place,

    > The Linux-nationale / Shall Microsoft outpace,

    > We can write better programs / Our CPUs won't stall,

    > So raise the penguin banner of / The Linux-nationale.  --Greg Baker

    >

## William Tanksley — 2009-03-21 18:45:40

    John Nowak wrote:

     > Getting rid of the stack though is necessary to make cleave more useful.

     Hmmmmmm. Is that a well-supported conclusion? It seems a little strong.

    It also seems to presume the need to "make cleave more useful" (as

    opposed to finding a more useful operation, or redefining cleave in a

    more useful way).

    By the way, are the words "cleave" and "spread" actually standard use? I

    always get them backwards, because it SEEMS to me that "cleaving"

    dataflow should separate one datum from another, while "spreading" data

    should take the same data and make it available to more code (like

    spreading butter over bread). Yet that's the opposite of how Factor uses

    the words. Does anyone know the reason for the naming convention?

     > One problem with cleave in a stack-based language is that you need one

    > version for every number of items you want to pass to the cleave. This

    > is because the entire state of the program is passed to every function

    > and you need to "tell" the cleave how many items it cases about. This

    > is not the case in FP.

     This is perfectly true, and I admit is a very interesting problem. FP

    has its own converse form of the same problem: when you need to combine

    multiple flows into one function you need to tell the language. FP has a

    very nice syntax for that, of course.

    It occurs to me, in passing, that if the problem is merely telling the

    notation *how many* inputs it cares about, the solution might be to add

    tally marks to the notation. A 2cleave might look like "<<( *,

    + )>" (meaning that each branch takes 2 params and when all is done each

    branch pushes 1 result onto the main stack). I chose those tally marks

    to make it look like a forked dataflow -- this is a cleave. I don't have

    a suggestion for denoting a spread; the obvious idea of using / to tally

    the items falls short because it's not obvious how many items go to each

    branch.

     > Another benefit of the FP approach to construction is that functions

    > in the construction cannot interact. This is not the case with cleave

    > as I've pointed out previously.

     Not the way you and Factor define it, no. But that's something that I've

    complained about in the past: I think the elements of a cleave should

    execute independent of each other.

     > Finally, construction in FP always returns N elements where N is the

    > number of functions used in the construction. This is *much& easier to

    > deal with than cleave in a stack-based language where the output of

    > each cleave is essentially concatenated together into a flat stack.

    > For example, say you have the program 'hd [foo, bar]'. If you know

    > that 'bar' terminates, you can simplify this program to 'foo' without

    > knowing the arities of 'foo' and 'bar'. You cannot do this with cleave

    > in a stack-based language. Similarly, you get nice properties like

    > distributivity that allows you to convert '[foo, bar] baz quux' to

    > '[foo baz, bar baz] quux', and so on.

     I have to disagree --- not about those properties being present in FP,

    but about your implied claim that there are no complimentary properties

    in concatenative languages. There's an algebra available to them too,

    even without knowledge of specific dataflow behavior; Manfred has worked

    out some of the details already, and there's more to do. In particular,

    the algebra of some of the syntax proposals is open to work. Factor's

    cleave isn't distributive, but if the two branches are put infra their

    own stacks there is a distributive property.

     > Hopefully that ramble makes some sense. I've done a lot of thinking

    > about why cleave works better in FP, but I'm still having a bit of

    > trouble articulating it.

     I'm glad you're exploring it; thanks to your careful explanations I've

    gained an appreciation for FP and the various APL's dataflow

    capabilities. The nice thing about these languages is that they provide

    explicit syntactic support for the programmer to keep multiple distinct

    dataflows. In a concatenative language, there's syntactic support for

    only one dataflow; because most problems need more, you wind up having

    to do some amount of shuffling.

    Do concatenative languages have any advantage? I can see two distinct

    differences (which may amount to advantages in some situations): first,

    concatenative dataflow points in the same direction as program execution

    or reading; and second, merging two concatenative dataflows requires no

    explicit syntax.

    I'm not claiming these are innate advantages; I'm just saying that

    they're differences.

     > - John

     -Wm

## John Cowan — 2009-03-21 20:23:00

    William Tanksley scripsit:

     > By the way, are the words "cleave" and "spread" actually standard use? I

    > always get them backwards, because it SEEMS to me that "cleaving"

    > dataflow should separate one datum from another, while "spreading" data

    > should take the same data and make it available to more code (like

    > spreading butter over bread). Yet that's the opposite of how Factor uses

    > the words. Does anyone know the reason for the naming convention?

     Perhaps because _cleave_ has two opposed meanings: 'split', which is

    the one you are using, and 'stick together'.  The first is more common

    nowadays.  In Old English they were two separate words that have come

    to be spelled and pronounced alike.

    --

    John Cowan  cowan@...    http://ccil.org/~cowan

    No man is an island, entire of itself; every man is a piece of the

    continent, a part of the main.  If a clod be washed away by the sea,

    Europe is the less, as well as if a promontory were, as well as if a

    manor of thy friends or of thine own were: any man's death diminishes me,

    because I am involved in mankind, and therefore never send to know for

    whom the bell tolls; it tolls for thee.  --John Donne

## John Nowak — 2009-03-21 21:42:06

    On Mar 21, 2009, at 2:45 PM, William Tanksley wrote:

     > John Nowak wrote:

    >

    >> Getting rid of the stack though is necessary to make cleave more

    >> useful.

    >

    > Hmmmmmm. Is that a well-supported conclusion? It seems a little

    > strong.

     I'm confident in that claim. I've given some sporadic explanation for

    this claim previously; I can try and condense my explanation if you'd

    like.

    As far as evidence in the wild, I think it's telling that FP,

    Squiggol, J, etc, have all had something like "cleave" from the very

    beginning. Stack-based languages went a long time without it, and now

    that they have it, they require many variants of it.

    Again, if you want me to explain myself in full, I don't mind. Perhaps

    expressing my confidence that I'm right isn't enough to convince

    anyone...

     > It also seems to presume the need to "make cleave more useful" (as

    > opposed to finding a more useful operation, or redefining cleave in

    > a more useful way).

     Good point. That said, I've tried to come up with some better

    alternatives for stack-based languages (the "banana" combinator, etc),

    but I still fact the stack-based nature of things makes it difficult.

     > By the way, are the words "cleave" and "spread" actually standard use?

     I don't think so. I've no idea where the terms originated.

     > I always get them backwards, because it SEEMS to me that "cleaving"

    > dataflow should separate one datum from another, while "spreading"

    > data should take the same data and make it available to more code

    > (like spreading butter over bread).

     Now you'll have me doing it too! Indeed, your explanation does make

    perfect sense.

     >> Another benefit of the FP approach to construction is that functions

    >> in the construction cannot interact. This is not the case with cleave

    >> as I've pointed out previously.

    >

    > Not the way you and Factor define it, no.

     Or in Joy or Cat. The obvious definition for 'bi' is '[keep] dip i'.

    This doesn't get you independent evaluation. Actually getting it is

    surprisingly tricky. My banana combinator is one suggestion, but it

    requires each function return a single value which isn't always good.

    Your suggestion for having a prelude and postlude to construct and

    destruct individual stacks works, but I think it's less pleasant than

    how things work in FP. We've been over this though, so I'm sure you'll

    find that I'm just repeating myself now.

     > The nice thing about these languages is that they provide

    > explicit syntactic support for the programmer to keep multiple

    > distinct

    > dataflows. In a concatenative language, there's syntactic support for

    > only one dataflow; because most problems need more, you wind up having

    > to do some amount of shuffling.

     This is a good point. In fact, they often offer multiple syntaxes for

    the same data flow. For example, FL has a "general prefix" syntax

    where 'g f h' == 'f.[g,h]'. You can use whichever feels more

    appropriate. Writing '+.[a,+.[b,c]]' is pretty awkward, but luckily

    you have the equivalent expression 'a + b + c'.

    - John

## William Tanksley — 2009-03-23 18:03:16

    John Nowak wrote:

     > William Tanksley wrote:

    > > John Nowak wrote:

    > >> Getting rid of the stack though is necessary to make cleave more

    > >> useful.

    > > Hmmmmmm. Is that a well-supported conclusion? It seems a little

    > > strong.

    > I'm confident in that claim. I've given some sporadic explanation for

    > this claim previously; I can try and condense my explanation if you'd

    > like.

     I've seen your arguments; and I have to agree that it's clear that

    there's a lot of benefits to providing syntactic support for multiple

    dataflows, which is something that a fully concatenative language simply

    cannot give.

     > As far as evidence in the wild, I think it's telling that FP,

    > Squiggol, J, etc, have all had something like "cleave" from the very

    > beginning. Stack-based languages went a long time without it, and now

    > that they have it, they require many variants of it.

     I don't see this as significant in any way; the whole idea of a

    concatenative language is brand new, and most of them were purely

    practical in emphasis.

     > Again, if you want me to explain myself in full, I don't mind. Perhaps

    > expressing my confidence that I'm right isn't enough to convince

    > anyone...

     Strange how that works :-). No, I think we've got the basics down. I

    agree with everything you said ... but you haven't shown that there's

    _nothing_ equally compelling and useful for a stack, merely that we know

    of nothing. I'm gonna keep hunting :-), but I'm glad you're explaining

    your work here even if it's not (perhaps) _strictly_ concatenative.

     > > I always get them backwards, because it SEEMS to me that "cleaving"

    > > dataflow should separate one datum from another, while "spreading"

    > > data should take the same data and make it available to more code

    > > (like spreading butter over bread).

    > Now you'll have me doing it too! Indeed, your explanation does make

    > perfect sense.

     Cowan pointed out that English has two different words with the same

    'cleave' spelling, with opposite meanings. Cowan, I did know that

    meaning of 'cleave', and thought about it, but I can't think of any way

    to apply it sensibly to this particular problem. Can you explain how it

    helps?

     > >> Another benefit of the FP approach to construction is that functions

    > >> in the construction cannot interact. This is not the case with cleave

    > >> as I've pointed out previously.

    > > Not the way you and Factor define it, no.

    > Or in Joy or Cat. The obvious definition for 'bi' is '[keep] dip i'.

     According to Factor, yes. That doesn't make it "The Definition", it's

    just how it's defined for them.

     > surprisingly tricky. My banana combinator is one suggestion, but it

    > requires each function return a single value which isn't always good.

     Correct; it's a kind-of-smart combinator. This is the big thing I don't

    like about stack-copying behavior... Aside from the fact that

    implementing it without an immutable stack is _hard_, it also assumes

    the output for every operation is a single value at the top of the

    stack.

     > Your suggestion for having a prelude and postlude to construct and

    > destruct individual stacks works, but I think it's less pleasant than

    > how things work in FP. We've been over this though, so I'm sure you'll

    > find that I'm just repeating myself now.

     I think we may indeed have reached the edge of how useful cleave/spread

    can be in stack-based languages. That's an interesting thought! There

    are still (at least) two obvious reasons to keep thinking about stack

    languages, even if that's true:

    1. There might be an advantage to being able to merge and mix up

    dataflows without syntax -- by definition, languages with syntactic

    dataflow can't do that.

    2. There might be an operator more appropriate for stack languages.

    #1 seems absolutely certain, so let's make it a bit harder by requiring

    that any advantage ALSO be reasonably "structured". It's no good if the

    only advantage is the ability to be able to write spaghetti

    dataflow :-).

     > > The nice thing about these languages is that they provide

    > > explicit syntactic support for the programmer to keep multiple

    > > distinct

    > > dataflows. In a concatenative language, there's syntactic support for

    > > only one dataflow; because most problems need more, you wind up having

    > > to do some amount of shuffling.

    > This is a good point. In fact, they often offer multiple syntaxes for

    > the same data flow. For example, FL has a "general prefix" syntax

    > where 'g f h' == 'f.[g,h]'. You can use whichever feels more

    > appropriate. Writing '+.[a,+.[b,c]]' is pretty awkward, but luckily

    > you have the equivalent expression 'a + b + c'.

     Interesting point -- I didn't even notice. That's actually a close

    equivalent to how your banana notation works: in a "strict"

    concatenative sense you'd write it as quotations plus a combinator, but

    there's an alternative syntax that makes the structure of your intention

    much clearer.

    Naturally, I'm now wondering if the entire advantage of FL syntactic

    dataflow is lost if you take away the alternate syntax -- and,

    conversely, whether there's an "alternate syntax" for concatenative

    languages which would provide them with something equally nice.

    If there is, I rather suspect you're working on something that will lead

    to it. I especially like the variant of your language (is it still

    called 'fifth'?) which uses juxtaposition to denote composition.

     > - John

     -Wm

## John Cowan — 2009-03-23 18:42:27

    William Tanksley scripsit:

     > Cowan pointed out that English has two different words with the same

    > 'cleave' spelling, with opposite meanings. Cowan, I did know that

    > meaning of 'cleave', and thought about it, but I can't think of any way

    > to apply it sensibly to this particular problem. Can you explain how it

    > helps?

     On the contrary, my intent was to point out that it makes matters worse.

    Not only is the metaphorical sense of "cleave" unclear, its literal

    sense is unclear too.  IMHO it should be banned.

    --

    John Cowan    cowan@...    http://ccil.org/~cowan

       There was an old man                Said with a laugh, "I

         From Peru, whose lim'ricks all      Cut them in half, the pay is

           Look'd like haiku.  He              Much better for two."

                                                 --Emmet O'Brien

## John Nowak — 2009-03-23 20:44:39

    On Mar 23, 2009, at 2:03 PM, William Tanksley wrote:

     >> surprisingly tricky. My banana combinator is one suggestion, but it

    >> requires each function return a single value which isn't always good.

    >

    > Correct; it's a kind-of-smart combinator.

     I prefer the term "kind-of-stupid combinator".

     > This is the big thing I don't

    > like about stack-copying behavior... Aside from the fact that

    > implementing it without an immutable stack is _hard_, it also assumes

    > the output for every operation is a single value at the top of the

    > stack.

     This may be a source of some confusion for us. If your programming

    language is typed (or requires that all functions have inferable stack

    effects), you don't need to use a stack in the implementation *at

    all*. Accordingly, you certainly never need to copy it. There's no

    efficiency penalty or implementation difficulty for something like the

    banana combinator in this situation.

    You're right that the single value output is unacceptable in the

    context of a stack-based language in many cases.

     > I especially like the variant of your language (is it still called

    > 'fifth'?) which uses juxtaposition to denote composition.

     I'm calling this current "concatenative FP" thing "Forthus". It has

    the concatenative elements of Forth and the ideas of John Backus.

    Back. Forth. Backus. Forthus. You get it.

    - John

## John Nowak — 2009-03-23 20:55:23

    On Mar 23, 2009, at 2:42 PM, John Cowan wrote:

     > On the contrary, my intent was to point out that it makes matters

    > worse.

    > Not only is the metaphorical sense of "cleave" unclear, its literal

    > sense is unclear too.  IMHO it should be banned.

     In all seriousness, I prefer the J term "fork" for cleave. For spread,

    I'd suggest "par", or "parallel". Both of these come from how you

    visualize the computation:

    FORK

        x

       / \

      F   G

    PAR

      x  y

      |  |

      F  G

    "Par" is also nice because you're sort of "pairing off" objects and

    functions. Maybe "pair" is better than "par" actually.

    - John

## John Nowak — 2009-03-23 20:47:53

    On Mar 23, 2009, at 2:42 PM, John Cowan wrote:

     > William Tanksley scripsit:

    >

    >> Cowan pointed out that English has two different words with the same

    >> 'cleave' spelling, with opposite meanings. Cowan, I did know that

    >> meaning of 'cleave', and thought about it, but I can't think of any

    >> way

    >> to apply it sensibly to this particular problem. Can you explain

    >> how it

    >> helps?

    >

    > On the contrary, my intent was to point out that it makes matters

    > worse.

    > Not only is the metaphorical sense of "cleave" unclear, its literal

    > sense is unclear too.  IMHO it should be banned.

     I've had a friend propose the term "construction" (from FP) for what

    is currently cleave and "combination" for what is currently spread.

    Part of the motivation here was finding yet another term that begins

    with "c" for the special forms of an FP-like language:

    1. Construction

    2. Combination

    3. Condition

    4. Constant

    5. Curry

    6. Case

    Perhaps not the best motivation...

    - John

## William Tanksley — 2009-03-23 21:39:00

    John Nowak wrote:

     > John Cowan wrote:

    > > On the contrary, my intent was to point out that it makes matters

    > > worse.

    > > Not only is the metaphorical sense of "cleave" unclear, its literal

    > > sense is unclear too.  IMHO it should be banned.

    > In all seriousness, I prefer the J term "fork" for cleave. For spread,

    > I'd suggest "par", or "parallel". Both of these come from how you

    > visualize the computation:

    > FORK

    >     x

    >    / \

    >   F   G

    > PAR

    >   x  y

    >   |  |

    >   F  G

    > "Par" is also nice because you're sort of "pairing off" objects and

    > functions. Maybe "pair" is better than "par" actually.

     I like that. But 'pair' is a dangerous pun, since it's commonly used to

    join list nodes. Perhaps another good word would be 'cut' or 'knife', to

    evoke cutting the data apart to make it go with the data. The one word

    we can't use is cleave.

    But the 'knife' and 'fork' expressions just seem to go together. Except

    that there is no spoon.

     > - John

     -Wm

## William Tanksley — 2009-03-23 21:29:09

    John Nowak wrote:

     > William Tanksley wrote:

    > > This is the big thing I don't

    > > like about stack-copying behavior... Aside from the fact that

    > > implementing it without an immutable stack is _hard_, it also assumes

    > > the output for every operation is a single value at the top of the

    > > stack.

    > This may be a source of some confusion for us. If your programming

    > language is typed (or requires that all functions have inferable stack

    > effects), you don't need to use a stack in the implementation *at

    > all*. Accordingly, you certainly never need to copy it. There's no

    > efficiency penalty or implementation difficulty for something like the

    > banana combinator in this situation.

     You're right in that I shouldn't have said "immutable stack". I don't

    think that need be a source of confusion, because it's true that "stack

    copying" behavior always introduces complexity, whether or not the

    underlying implementation actually involves a stack. If your stack is

    only a bookkeeping notion, then your bookkeeping is going to get a

    little more complicated.

     > I'm calling this current "concatenative FP" thing "Forthus". It has

    > the concatenative elements of Forth and the ideas of John Backus.

    > Back. Forth. Backus. Forthus. You get it.

     I like it. I definitely look forward to reading more about it when it's

    ready for that.

     > - John

     -Wm

## John Nowak — 2009-03-24 05:57:05

    On Mar 23, 2009, at 5:39 PM, William Tanksley wrote:

     > John Nowak wrote:

    >

    >> In all seriousness, I prefer the J term "fork" for cleave. For

    >> spread,

    >> I'd suggest "par", or "parallel".

    >

    > I like that. But 'pair' is a dangerous pun, since it's commonly used

    > to

    > join list nodes.

     I've finally gotten my hands on a copy of Bird and de Moor's "Algebra

    of Programming" today. It uses the following terminology:

         fork a = (a, a)

         cross (f, g) (a, b) = (f a, g b)

         pair (f, g) a = (f a, g a)

    In other words, they use "fork" for our "swap", "cross" for our

    "spread" (for which I proposed "pair"), and "pair" for our

    "cleave" (for which I propose "fork"). Just to make things extra

    confusing.

    - John

## John Nowak — 2009-03-24 06:01:50

    On Mar 24, 2009, at 1:57 AM, John Nowak wrote:

     >     fork a = (a, a)

    >

    > In other words, they use "fork" for our "swap"

     And by "swap", I mean "dup". Oops.

    They actually do use "swap" for "swap" thankfully.

    - John