Advantages of cat, joy ..?

[chris glur]

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]

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]

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]

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@...>
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, Jr]

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]

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

----- Original Message -----
From: "Stevan Apter" <sa@...>
To: <concatenative@...>
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]

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]

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

a k implementation of 10:

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

no examples.


----- Original Message -----
From: "John Nowak" <john@...>
To: <concatenative@...>
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, Jr]

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, Jr]

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]

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]

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, Jr]

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

[LittleDan]

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, Jr]

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, Jr]

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, Jr]

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]

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