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