the concatenative wikipedia article
John Nowak — 2008-12-31 05:27:10
The Wikipedia article on concatenative languages has a number of
issues that I think should be addressed. I'm willing to make the
changes, but I'd like to make sure I'm not off-base first.
I realize many of these concerns are rather tired at this point. I
apologize. However, that doesn't change the fact that they've gone
unresolved. Indeed, there seems to be almost a resistance to resolving
them. I personally think that the non-applicative style of programming
has important properties and that it would be great to have a term for
them so I could stop redefining "concatenative" every time I talk to
someone (including those knowledgeable about concatenative languages).
Here are my issues with the article:
1. Concatenative should not be conflated with "stack-based". I have
already shown that the counter-examples are beyond mere curiosities.
2. It should be more clearly stressed that concatenative languages are
not applicative. The reduction of a concatenative expression is the
simplification of one function to another function (e.g. '1 2 + + ==>
3 +'). Never is it necessary to deal with objects or application, and
much is gained by not doing so (as is mentioned at
http://www.latrobe.edu.au/philosophy/phimvt/joy/j08cnt.htm)
.
3. There is no reason concatenative languages must use a postfix
syntax. A prefix syntax is also a valid approach. Other syntaxes are
useful (as I've shown recently with my infix construction syntax
similar to that of in FL and J) but ruled out by the need for
concatenation to always denote composition (which I think is probably
unfortunate).
4. Not all concatenative languages have parsing words or an equivalent
to macros. Talking about them here makes as much sense as talking
about macros on a page about applicative programming.
5. It should be stressed that concatenative languages are function-
level and pointfree. They also go beyond languages like Backus's FP in
that objects are entirely removed from the language; The expression
'3' represents a *function*, not an object.
6. I dislike the sentence "The term 'concatenative' is not universally
accepted as a particularly useful term". It's an objectively useful
term if some care is given to its definition; What's "universally
accepted" is unimportant. Hell, even Slava (who says it's unimportant)
has started concatenative.org (which lists C++ and Java as
"interesting languages"... ugh).
So, should I make the changes or should I just define a new term so I
that can communicate with people without boring myself? I did like
Diggins's "compositional" suggestion which is more to the point; The
fact that it is already used in various vague ways doesn't disturb me
too much.
Sorry for bringing this up *again*, but I'm trying to write a paper
and keep stumbling over how to describe what it is that I'm talking
about.
- John
William Tanksley, Jr — 2008-12-31 17:07:49
John Nowak <
john@...> wrote:
> The Wikipedia article on concatenative languages has a number of
> issues that I think should be addressed. I'm willing to make the
> changes, but I'd like to make sure I'm not off-base first.
I'd like to see that. For some reason I've never felt adequate to
munge the page...
> Here are my issues with the article:
The number one problem is the motivation for the definition. As given,
it sounds like a mathematical or historical curiosity.
> 1. Concatenative should not be conflated with "stack-based". I have
> already shown that the counter-examples are beyond mere curiosities.
Agreed entirely.
I'd like to see your examples, specifically emphasizing how you know
it's concatenative. I didn't notice them.
> 2. It should be more clearly stressed that concatenative languages are
> not applicative. The reduction of a concatenative expression is the
This is a very big point, and should be strongly emphasized.
> 3. There is no reason concatenative languages must use a postfix
> syntax. A prefix syntax is also a valid approach. Other syntaxes are
> useful (as I've shown recently with my infix construction syntax
> similar to that of in FL and J) but ruled out by the need for
> concatenation to always denote composition (which I think is probably
> unfortunate).
Technically it's not prefix or postfix; it's beginning-to-end or
end-to-beginning. I really don't see any utility in the latter.
It can also be ruled out by the use of other definitions for
concatenativity -- I really like the one we arrived at a year ago.
Here are a couple of (hopefully) alternative phrasings (that is,
they're intended to imply the same things):
1. For the mathematically oriented: "A concatenative language consists
of a mapping from a syntactic monoid over program concatenation to a
semantic monoid over an associative operation on functions." This
language is motivated by von Thun's "Mathematical Foundations of Joy",
http://www.latrobe.edu.au/philosophy/phimvt/joy/j02maf.html (but I'm
to blame for applying it here, so don't shoot at Manfred if I've got
it wrong).
2. A simple definition: "A concatenative language is a programming
language where the syntactic concatenation of terms expresses an
associative operation on the functions that the terms represent." This
was built by Christopher Diggins.
3. Purely language-theoretical: "A language's syntax is concatenative
if it is its own Kleene closure."
My favorite is #2. I'd really want to call out the advantages granted
by associativity; I think that's the single biggest thing experienced
concatenative programmers enjoy, even if they never know to name it.
It's the property that allows one to refactor merely using cut and
paste.
> 4. Not all concatenative languages have parsing words or an equivalent
> to macros. Talking about them here makes as much sense as talking
> about macros on a page about applicative programming.
Granted. I'd be okay with removing this... Although Forth (for
example) has a very simple and powerful macro system, it's interesting
that its creator recommends that it be entirely avoided. The theory of
macros on top of a concatenative language is simple and clear, but is
really a different issue.
> 5. It should be stressed that concatenative languages are function-
> level and pointfree. They also go beyond languages like Backus's FP in
> that objects are entirely removed from the language; The expression
> '3' represents a *function*, not an object.
Okay, that's good. I'd worry a little about the expression "objects
are entirely removed"... There's an obvious way to entirely
misunderstand that. The terminology in the Wikipedia definition of
"function-level" suggests that perhaps you should say something along
the lines of "the distinction between data and functions is entirely
removed from the language, and all functions are built up from other
functions, with constant functions standing in for data."
> 6. I dislike the sentence "The term 'concatenative' is not universally
> accepted as a particularly useful term". It's an objectively useful
> term if some care is given to its definition;
I agree... I suspect this is one of Wikipedia's famous controversy
edits. It doesn't fit well with the rest of the page, and it serves no
purpose.
> So, should I make the changes or should I just define a new term so I
> that can communicate with people without boring myself? I did like
> Diggins's "compositional" suggestion which is more to the point; The
> fact that it is already used in various vague ways doesn't disturb me
> too much.
I'd like the changes made -- it would be nice to have an encyclopedic
reference for this list's discussions. I'd rather not branch to
another term; I think "concatenative" is well-established and
fruitful, even if it is a bit vague. (But what isn't vague?)
> - John
-Wm
Christopher Diggins — 2008-12-31 19:34:16
>> 1. Concatenative should not be conflated with "stack-based". I have
>> already shown that the counter-examples are beyond mere curiosities.
>
> Agreed entirely.
>
> I'd like to see your examples, specifically emphasizing how you know
> it's concatenative. I didn't notice them.
Allow me to present the deque language that I just made up.
1! - Pushes a one to the right of the deque
!1 - Pushes a one to the leftt of the deque
...
add! - Adds the right two numbers of the deque
!add - Adds the left two numbers of the deque
...
3! !5 !2 sub! !add
If applied to an empty deque this will leave the value 4 on the deque.
So is this a concatenative language? It satisfies many of the
criteria, but I am not sure. If we could agree that this is or is not
concatenative, it may prove useful.
>> So, should I make the changes or should I just define a new term so I
>> that can communicate with people without boring myself? I did like
>> Diggins's "compositional" suggestion which is more to the point; The
>> fact that it is already used in various vague ways doesn't disturb me
>> too much.
>
> I'd like the changes made -- it would be nice to have an encyclopedic
> reference for this list's discussions. I'd rather not branch to
> another term; I think "concatenative" is well-established and
> fruitful, even if it is a bit vague. (But what isn't vague?)
Agreed, I think there is value in refining the term concatenative.
However, I think it is more important to define it here than somewhere
else like a wiki where people with no knowledge of the subject can
make arbitrary uninformed edits. Besides whatever is agreed upon in
the list can serve as a source of citation for the Wikipedia article.
- Christopher
William Tanksley, Jr — 2008-12-31 20:21:53
Christopher Diggins <
cdiggins@...> wrote:
>>> 1. Concatenative should not be conflated with "stack-based". I have
>>> already shown that the counter-examples are beyond mere curiosities.
>> I'd like to see your examples, specifically emphasizing how you know
>> it's concatenative. I didn't notice them.
> Allow me to present the deque language that I just made up.
> 1! - Pushes a one to the right of the deque
> !1 - Pushes a one to the leftt of the deque
> add! - Adds the right two numbers of the deque
> !add - Adds the left two numbers of the deque
> ...
> 3! !5 !2 sub! !add
> If applied to an empty deque this will leave the value 4 on the deque.
> So is this a concatenative language? It satisfies many of the
> criteria, but I am not sure. If we could agree that this is or is not
> concatenative, it may prove useful.
By all three of the definitions I posted, as well as the Wikipedia one
(stripped of its parochial insistence on stacks), this qualifies. As a
bonus, my gut feeling is that it's concatenative. It's definitely more
complex than working with a stack, but there's nothing inherently
wrong about that -- and perhaps there's a data structure that's
inherently simpler than a stack.
OTOH, can a concatenative language ever be infix? I'd find it odd... A
fundamental property is syntactic associativity, and infix isn't
associative... Or can it be made so by means of currying?
> Agreed, I think there is value in refining the term concatenative.
> However, I think it is more important to define it here than somewhere
> else like a wiki where people with no knowledge of the subject can
> make arbitrary uninformed edits. Besides whatever is agreed upon in
> the list can serve as a source of citation for the Wikipedia article.
Granted, but a mailing list is ephemeral.
> - Christopher
-Wm
John Nowak — 2008-12-31 22:49:40
On Dec 31, 2008, at 3:21 PM, William Tanksley, Jr wrote:
> OTOH, can a concatenative language ever be infix? I'd find it odd...
The general idea that I've had for a prefix/infix language is as
follows:
1. 'f g' denotes the composition of 'f' and 'g'
2. 'f g h' denotes the composition of 'g' with the construction of 'f'
and 'h' (construction is basically a cleave combinator)
3. Grouping is to the right such that 'f g h i j k == f g (h i (j k))'
4. Composition is associative such that '(f g) h == f (g h)'
5. Literals (e.g. '42') are constant functions such that '42 f == 42'
6. Multiple arguments are passed via lists
7. 'a == head', 'b == head tail', 'c == head (head tail)', etc --
these are essentially used to index into lists
As such, you write functions like this:
discriminant = (sq b) - 4 * a * c
And here's the definition in use
# composition of discriminant and the construction [1,3,-4]
discriminant [1,3,-4]
# expansion of discriminant
((sq b) - 4 * a * c) [1,3,-4]
# fully parenthesized
((sq b) - (4 * (a * c))) [1,3,-4]
# replacing infix with composition + construction
(- [sq b, * [4, * [a, c]]) [1,3,-4]
# law of associativity: (f g) h == f (g h)
- ([sq b, * [4, * [a, c]]) [1,3,-4])
# law of distributivity: [f0..fN] g == [f0 g..fN g]
- [(sq b) [1,3,-4], * [4 [1,3,-4], (* [a, c]) [1,3,-4]]
# simplification
- [(sq b) [1,3,-4], * [4, (* [a, c]) [1,3,-4]]
- [(sq b) [1,3,-4], * [4, * [1, -4]]
- [sq (b [1,3,-4]), * [4, * [1, -4]]
- [sq 3, * [4, * [1, -4]]
- [sq 3, * [4, -4]]
- [sq 3, -16]
- [9, -16]
25
The infix syntax makes the manipulation a little awkward, but I've
found it often makes the definitions shorter and more readable. The
fact that any function can be used infix is a nice touch.
So, is this concatenative? It's just composition and cleave combinators.
- John
Adam — 2008-12-31 23:01:37
Slava recently created a nice description of Concatenative languages
in the following four articles:
http://www.concatenative.org/wiki/view/Concatenative%20language
http://www.concatenative.org/wiki/view/Concatenative%20language/Name%20code%20not%20values
http://www.concatenative.org/wiki/view/Concatenative%20language/Multiple%20return%20values
http://www.concatenative.org/wiki/view/Concatenative%20language/Concatenation%20is%20composition
-Adam
--- In concatenative@yahoogroups.com, John Nowak <john@...> wrote:
>
> The Wikipedia article on concatenative languages has a number of
> issues that I think should be addressed. I'm willing to make the
> changes, but I'd like to make sure I'm not off-base first.
>
> I realize many of these concerns are rather tired at this point. I
> apologize. However, that doesn't change the fact that they've gone
> unresolved. Indeed, there seems to be almost a resistance to resolving
> them. I personally think that the non-applicative style of programming
> has important properties and that it would be great to have a term for
> them so I could stop redefining "concatenative" every time I talk to
> someone (including those knowledgeable about concatenative languages).
>
> Here are my issues with the article:
>
> 1. Concatenative should not be conflated with "stack-based". I have
> already shown that the counter-examples are beyond mere curiosities.
>
> 2. It should be more clearly stressed that concatenative languages are
> not applicative. The reduction of a concatenative expression is the
> simplification of one function to another function (e.g. '1 2 + + ==>
> 3 +'). Never is it necessary to deal with objects or application, and
> much is gained by not doing so (as is mentioned at http://www.latrobe.edu.au/philosophy/phimvt/joy/j08cnt.htm)
> .
>
> 3. There is no reason concatenative languages must use a postfix
> syntax. A prefix syntax is also a valid approach. Other syntaxes are
> useful (as I've shown recently with my infix construction syntax
> similar to that of in FL and J) but ruled out by the need for
> concatenation to always denote composition (which I think is probably
> unfortunate).
>
> 4. Not all concatenative languages have parsing words or an equivalent
> to macros. Talking about them here makes as much sense as talking
> about macros on a page about applicative programming.
>
> 5. It should be stressed that concatenative languages are function-
> level and pointfree. They also go beyond languages like Backus's FP in
> that objects are entirely removed from the language; The expression
> '3' represents a *function*, not an object.
>
> 6. I dislike the sentence "The term 'concatenative' is not universally
> accepted as a particularly useful term". It's an objectively useful
> term if some care is given to its definition; What's "universally
> accepted" is unimportant. Hell, even Slava (who says it's unimportant)
> has started concatenative.org (which lists C++ and Java as
> "interesting languages"... ugh).
>
> So, should I make the changes or should I just define a new term so I
> that can communicate with people without boring myself? I did like
> Diggins's "compositional" suggestion which is more to the point; The
> fact that it is already used in various vague ways doesn't disturb me
> too much.
>
> Sorry for bringing this up *again*, but I'm trying to write a paper
> and keep stumbling over how to describe what it is that I'm talking
> about.
>
> - John
>
Adam — 2008-12-31 23:12:00
Also, concatenative.org is editable by the public as well if you register.
--- In concatenative@yahoogroups.com, Adam <hiatoms@...> wrote:
>
> Slava recently created a nice description of Concatenative languages
> in the following four articles:
>
> http://www.concatenative.org/wiki/view/Concatenative%20language
>
>
http://www.concatenative.org/wiki/view/Concatenative%20language/Name%20code%20not%20values
>
>
http://www.concatenative.org/wiki/view/Concatenative%20language/Multiple%20return%20values
>
>
http://www.concatenative.org/wiki/view/Concatenative%20language/Concatenation%20is%20composition
>
> -Adam
>
> --- In concatenative@yahoogroups.com, John Nowak <john@> wrote:
> >
> > The Wikipedia article on concatenative languages has a number of
> > issues that I think should be addressed. I'm willing to make the
> > changes, but I'd like to make sure I'm not off-base first.
> >
> > I realize many of these concerns are rather tired at this point. I
> > apologize. However, that doesn't change the fact that they've gone
> > unresolved. Indeed, there seems to be almost a resistance to resolving
> > them. I personally think that the non-applicative style of programming
> > has important properties and that it would be great to have a term for
> > them so I could stop redefining "concatenative" every time I talk to
> > someone (including those knowledgeable about concatenative languages).
> >
> > Here are my issues with the article:
> >
> > 1. Concatenative should not be conflated with "stack-based". I have
> > already shown that the counter-examples are beyond mere curiosities.
> >
> > 2. It should be more clearly stressed that concatenative languages are
> > not applicative. The reduction of a concatenative expression is the
> > simplification of one function to another function (e.g. '1 2 + + ==>
> > 3 +'). Never is it necessary to deal with objects or application, and
> > much is gained by not doing so (as is mentioned at
http://www.latrobe.edu.au/philosophy/phimvt/joy/j08cnt.htm)
> > .
> >
> > 3. There is no reason concatenative languages must use a postfix
> > syntax. A prefix syntax is also a valid approach. Other syntaxes are
> > useful (as I've shown recently with my infix construction syntax
> > similar to that of in FL and J) but ruled out by the need for
> > concatenation to always denote composition (which I think is probably
> > unfortunate).
> >
> > 4. Not all concatenative languages have parsing words or an equivalent
> > to macros. Talking about them here makes as much sense as talking
> > about macros on a page about applicative programming.
> >
> > 5. It should be stressed that concatenative languages are function-
> > level and pointfree. They also go beyond languages like Backus's FP in
> > that objects are entirely removed from the language; The expression
> > '3' represents a *function*, not an object.
> >
> > 6. I dislike the sentence "The term 'concatenative' is not universally
> > accepted as a particularly useful term". It's an objectively useful
> > term if some care is given to its definition; What's "universally
> > accepted" is unimportant. Hell, even Slava (who says it's unimportant)
> > has started concatenative.org (which lists C++ and Java as
> > "interesting languages"... ugh).
> >
> > So, should I make the changes or should I just define a new term so I
> > that can communicate with people without boring myself? I did like
> > Diggins's "compositional" suggestion which is more to the point; The
> > fact that it is already used in various vague ways doesn't disturb me
> > too much.
> >
> > Sorry for bringing this up *again*, but I'm trying to write a paper
> > and keep stumbling over how to describe what it is that I'm talking
> > about.
> >
> > - John
> >
>
John Nowak — 2008-12-31 23:25:51
On Dec 31, 2008, at 6:01 PM, Adam wrote:
> Slava recently created a nice description of Concatenative languages
> in the following four articles
Thanks, I had hadn't seen that before.
Slava's description seems decent enough. It is, however, stack-
focused. He says that concatenative languages and stack-based
languages are similar, but then never clarifies the differences and
goes on to conflate the two. I also have some minor niggles (in no
particular order):
1. There's no reason a concatenative language has to support
recursion. My initial version of 5th did not.
2. Not all concatenative languages have multiple programmer-accessible
stacks. Forth and Factor do, Joy and Cat do not.
3. It isn't mentioned that the reduction of a function the
transformation of one function to another. This is the critical thing
I find lacking in FP and FL.
4. It says composition must be denoted by concatenation. I'd prefer to
say that some sort of concatenation operator is the primary means of
forming programs, be that operator whitespace, a dot, etc.
5. Quotation works quite differently in Factor and Joy compared to
Cat. In Cat, quotation is an abstraction mechanism (as Chris has
pointed out to me). In Factor and Joy, it is not. It is therefore not
accurate to say a quotation is a sequence of objects.
6. There's no reason that only one stack be live at any given point.
Joy's persistent stack semantics allow for parallel evaluation.
Ignoring IO, you can reduce programs using rewrite rules applied in
any order and/or simultaneously.
7. It it said that "literals are pushed onto the stack when
encountered by the evaluator". This implies that '5' is an object, not
a function, which I think is a less useful (and likely inaccurate)
characterization.
- John
John Nowak — 2008-12-31 23:49:17
On Dec 31, 2008, at 6:12 PM, Adam wrote:
> Also, concatenative.org is editable by the public as well if you
> register.
This is probably one of those "should wait 24 hours before sending
emails", but oh well...
Concatenative.org feels more like the future Factor wiki to me than a
general repository for information about concatenative languages. I
understand that Factor is a useful language (in contrast to Joy, Cat,
etc). I also understand that it's Slava's site. That said, I'd much
prefer it if the Factor-specifics were separated into their own wiki
(subdirectories on a wiki are meaningless) so the content could focus
exclusively on the theory of concatenative languages.
The dead links everywhere to things like "C++" and "garbage
collection" make it look like a bit of a wasteland and make the
purpose of the site less clear. I've asked if I could remove them but
was told not to. This is probably just be some overly territorial part
of my primitive mammalian brain going off, but I'm not comfortable
contributing to it in its current state.
A clear statement of intent for the site (and adherence to it) would
help me out. I'm not really interested in contributing to "The Factor
+ Some Concatenative Stuff Wiki". I'm sure such a thing is not Slava's
explicit intent, but it seems to be drifting in that general direction.
Then again, perhaps this is just my problem. It wouldn't be the first
time!
- John
Don Groves — 2008-12-31 23:54:31
On Dec 31, 2008, at 3:25 PM, John Nowak wrote:
>
> On Dec 31, 2008, at 6:01 PM, Adam wrote:
>
>> Slava recently created a nice description of Concatenative languages
>> in the following four articles
>
> Thanks, I had hadn't seen that before.
>
> Slava's description seems decent enough. It is, however, stack-
> focused. He says that concatenative languages and stack-based
> languages are similar, but then never clarifies the differences and
> goes on to conflate the two. I also have some minor niggles (in no
> particular order):
I haven't worked on this stuff for almost a year now, but when last
involved, I was fiddling with the terminology to eliminate the word
"stack," which is ingrained in the concatenative culture, but at times
not as descriptive as I would like. As these languages mature, their
operators become less and less stack-like.
I was leaning toward defining a concatenative (if that's the right
word) program as "a list of operators applied to a (possibly initially
empty) list of operands."
This definition seems to me to have two advantages: (1) it allows
for non-FIFO shuffle operations like swap, rot, etc..., which are fine
for a list but not so for a classically-defined stack; and (2) the order
of application is not specified.
Not being up on this topic at the moment, the order of application
may need to be specified -- [operand] [operators] -- I'm not sure
of this.
I'd appreciate any comments, as they may save me wasted effort
if/when I do return to this eternally intriguing subject (which is why
I've returned to it so often already ;-)
--
don
> 1. There's no reason a concatenative language has to support
> recursion. My initial version of 5th did not.
> 2. Not all concatenative languages have multiple programmer-accessible
> stacks. Forth and Factor do, Joy and Cat do not.
> 3. It isn't mentioned that the reduction of a function the
> transformation of one function to another. This is the critical thing
> I find lacking in FP and FL.
> 4. It says composition must be denoted by concatenation. I'd prefer to
> say that some sort of concatenation operator is the primary means of
> forming programs, be that operator whitespace, a dot, etc.
> 5. Quotation works quite differently in Factor and Joy compared to
> Cat. In Cat, quotation is an abstraction mechanism (as Chris has
> pointed out to me). In Factor and Joy, it is not. It is therefore not
> accurate to say a quotation is a sequence of objects.
> 6. There's no reason that only one stack be live at any given point.
> Joy's persistent stack semantics allow for parallel evaluation.
> Ignoring IO, you can reduce programs using rewrite rules applied in
> any order and/or simultaneously.
> 7. It it said that "literals are pushed onto the stack when
> encountered by the evaluator". This implies that '5' is an object, not
> a function, which I think is a less useful (and likely inaccurate)
> characterization.
>
> - John
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
John Nowak — 2009-01-01 00:24:08
On Dec 31, 2008, at 6:54 PM, Don Groves wrote:
> I was leaning toward defining a concatenative (if that's the right
> word) program as "a list of operators applied to a (possibly initially
> empty) list of operands."
I don't think this is a satisfactory definition for a few reason:
1. What exactly is a "list of operators"? Do you mean a sequence of
functions reified as a list of objects? I don't think that's necessary.
2. For me, the main advantage of a concatenative language is that you
get rid of application. Manfred von Thun pointed this out in his "Joy
compared with other functional languages" paper and I think it is
critical to the definition of concatenative languages.
3. There's no reason that the data structure the functions operate on
be a list or a stack. I recently proposed a language using vectors in
the style of More's array theory. Earlier today, Chris proposed a
language based on a deque. I believe XY works on a stack/queue tuple.
Other possibilities are easy to dream up.
> the order of application is not specified.
This would depend on the language in question. Various evaluation
strategies can be employed. In a language with side effects, the order
of reduction is going to be important. One could even imagine a
language with a term rewriting semantics that allows definitions of
the form 'dup drop -> id'. If your rewrite rules aren't confluent,
the way in which you reduce will matter.
- John
John Nowak — 2009-01-01 00:36:34
On Dec 31, 2008, at 2:34 PM, Christopher Diggins wrote:
>>> 1. Concatenative should not be conflated with "stack-based". I have
>>> already shown that the counter-examples are beyond mere curiosities.
>>
>> Agreed entirely.
>>
>> I'd like to see your examples, specifically emphasizing how you know
>> it's concatenative. I didn't notice them.
>
> Allow me to present the deque language that I just made up.
> ...
> So is this a concatenative language?
Looks like it to me.
The question is, which criteria would it *not* satisfy? I can't think
of any unless you restrict the forms of the language to composition
and quotation. Such a restriction would admit all current
"concatenative" languages but rule out things like language you
proposed (due to the '!' form) and the recent things I've been
proposing that use construction.
If that were the case, we could refer to concatenative languages as
the subset of compositional languages (i.e. languages that use
composition instead of application) that have quotation and
composition as their only program forming operations. I seem to recall
proposing this definition awhile back.
One issue with this definition is that Forth doesn't qualify as it
doesn't offer quotation. My proposed second-order 5th wouldn't qualify
either as it doesn't offer quotation and defines new combinators in
terms of (statically reducible) substitution. As my gut tells me that
both Forth and 5th should count, I think the composition+quotation
restriction may be too severe. You can't argue with the gut after all.
- John
William Tanksley, Jr — 2009-01-01 01:56:43
John Nowak <
john@...> wrote:
> The general idea that I've had for a prefix/infix language is as
> follows:
> 1. 'f g' denotes the composition of 'f' and 'g'
> 2. 'f g h' denotes the composition of 'g' with the construction of 'f'
> and 'h' (construction is basically a cleave combinator)
> 3. Grouping is to the right such that 'f g h i j k == f g (h i (j k))'
> 4. Composition is associative such that '(f g) h == f (g h)'
> So, is this concatenative? It's just composition and cleave combinators.
As I see it, no. The problem is that grouping is semantically
significant (rule 3), but not syntactically significant (rules 1&2).
It violates my rule that a concatenative language must have
associative semantics and syntax -- that means no required implicit
grouping.
> - John
-Wm
Christopher Diggins — 2009-01-01 03:48:50
Don Groves — 2009-01-01 04:07:57
On Dec 31, 2008, at 4:24 PM, John Nowak wrote:
> On Dec 31, 2008, at 6:54 PM, Don Groves wrote:
>
>> I was leaning toward defining a concatenative (if that's the right
>> word) program as "a list of operators applied to a (possibly
>> initially
>> empty) list of operands."
>
> I don't think this is a satisfactory definition for a few reason:
>
> 1. What exactly is a "list of operators"? Do you mean a sequence of
> functions reified as a list of objects? I don't think that's
> necessary.
As I now belatedly recall, no doubt prompted by your words, I was
using "sequence of operators" and "sequence of operands" rather
than lists.
> 2. For me, the main advantage of a concatenative language is that you
> get rid of application. Manfred von Thun pointed this out in his "Joy
> compared with other functional languages" paper and I think it is
> critical to the definition of concatenative languages.
I'll review that paper. Perhaps my use of of the word "application" to
indicate the catenation of two sequences, e.g., [a b] [+] is confusing.
> 3. There's no reason that the data structure the functions operate on
> be a list or a stack. I recently proposed a language using vectors in
> the style of More's array theory. Earlier today, Chris proposed a
> language based on a deque. I believe XY works on a stack/queue tuple.
> Other possibilities are easy to dream up.
The reason I picked "sequence" is that it seems to be the most basic
ordered structure.
>> the order of application is not specified.
>
> This would depend on the language in question. Various evaluation
> strategies can be employed. In a language with side effects, the order
> of reduction is going to be important. One could even imagine a
> language with a term rewriting semantics that allows definitions of
> the form 'dup drop -> id'. If your rewrite rules aren't confluent,
> the way in which you reduce will matter.
Many thanks for taking the time to comment, John. I'll tuck this away
with my notes for when the urge strikes again...
--
don
> - John
William Tanksley, Jr — 2009-01-01 06:37:35
Christopher Diggins <
cdiggins@...> wrote:
> I just posted my newest definition of concatenative language at
> http://dobbscodetalk.com/index.php?option=com_myblog&show=What-is-a-Concatenative-Language.html&Itemid=29
> with a deconstruction. I am happy to discuss it here (avoids the
> headache of having to register to leave comments).
That's a good definition.
I did like the one you posted in the last thread, though; the one I
listed as #2 in my list above. I like the fact that it explicitly
mentions concatenation (making the rationale for the name clear), and
it also depends on the concept of associativity, which directly drives
the ability to easily factor.
I do suspect that the definition might be a little improved by
hybridizing it with your newest one, perhaps something like this:
"A concatenative programming language is language in which terms
correspond to functions and in which the juxtaposition of terms
denotes an associative operation on functions."
Heh... That was simpler than I thought.
Is it TOO general? It seems to me to cover all the cases, even the
non-interesting ones (such as where the operation is multiplication).
> Christopher
-Wm
John Nowak — 2009-01-01 10:03:37
On Dec 31, 2008, at 8:56 PM, William Tanksley, Jr wrote:
> John Nowak <john@...> wrote:
>>
>
>> 1. 'f g' denotes the composition of 'f' and 'g'
>> 2. 'f g h' denotes the composition of 'g' with the construction of
>> 'f'
>> and 'h' (construction is basically a cleave combinator)
>> 3. Grouping is to the right such that 'f g h i j k == f g (h i (j
>> k))'
>> 4. Composition is associative such that '(f g) h == f (g h)'
>>
>> So, is this concatenative? It's just composition and cleave
>> combinators.
>
> As I see it, no. The problem is that grouping is semantically
> significant (rule 3), but not syntactically significant (rules 1&2).
> It violates my rule that a concatenative language must have
> associative semantics and syntax -- that means no required implicit
> grouping.
So if I got rid of rules 2 and 3, would it be concatenative? It would
have the same underlying semantics except concatenation is would
always mean composition.
This:
(sq b) - 4 * a * c
Would be written like this instead:
- [sq b, * [4, * [a, c]]]
If your answer is yes, my problem with that is that we don't impose
the same syntactic restrictions on the definition of an applicative
language. Tons of syntaxes are employed (Lisp, Haskell, J, FP, etc),
yet we still call them all applicative. Perhaps concatenative isn't
the right term, but I'd very much like a term focused strictly on
semantics like "applicative" is. Again, "compositional" or similar
seems like the obvious choice with "concatenative" being a subset
defined partially by its syntax.
- John
John Nowak — 2009-01-01 10:23:28
On Dec 31, 2008, at 10:48 PM, Christopher Diggins wrote:
> I just posted my newest definition of concatenative language at
> http://dobbscodetalk.com/index.php?option=com_myblog&show=What-is-a-Concatenative-Language.html&Itemid=29
Well lets see. Starting with your definition:
"A concatenative programming language is language in which terms
correspond to functions and in which the juxtaposition of terms
denotes the composition of functions."
The phrase "terms correspond to functions" is critical and I'm glad to
see you're included it. What you don't mention is that the language is
non-applicative. This is essentially a requirement of all terms being
functions, but perhaps you could cram it in there.
Here it is again with a few small changes:
"A concatenative programming language is A NON-APPLICATIVE language in
which ALL terms correspond to functions and in which the juxtaposition
of terms denotes the composition of functions."
I'm fine with this. It doesn't admit some things I'm working on, but
that's more than fine. The very term "concatenative" essentially
requires that concatenation mean something, and function composition
seems like the most likely choice. Yes, you could write a
concatenative-like language where '.' denoted composition, but why
would you? Narrowing the syntactic aspect of the definition without
restricting things that are possibly useful makes it easier to give
examples, state rules, etc. So yes, requiring juxtaposition mean
composition is fine.
Your definition doesn't mention quotation. I think this is a good
thing as Forth doesn't have it. It also leaves open the possibility
for other forms like construction, conditional (as in Forth), etc.
In short, you seem to have captured the essentials. I like it,
although I like it more with the non-applicative nature stressed.
I do have a question though. What about a language that allows
definition of this form:
dup drop => id
I think the answer is no because the terms denote *terms*, but I'd
like your answer anyway.
As for the remainder of your article, I completely disagree with this:
"In practical terms a concatenative language is not really different
from a functional language..."
If we consider Haskell a "functional language", then I think
concatenative languages are very different both in practical and
theoretical terms. Of course, it's not necessarily clear what you mean
by "functional" (which is another horribly abused term).
- John
John Nowak — 2009-01-01 10:28:39
On Dec 31, 2008, at 11:07 PM, Don Groves wrote:
>> 3. There's no reason that the data structure the functions operate on
>> be a list or a stack. I recently proposed a language using vectors in
>> the style of More's array theory. Earlier today, Chris proposed a
>> language based on a deque. I believe XY works on a stack/queue tuple.
>> Other possibilities are easy to dream up.
>
> The reason I picked "sequence" is that it seems to be the most basic
> ordered structure.
They need not be ordered. Consider a language that passed around a
dictionary. Primitive operations would assume their arguments were
stored at particular names. Essentially, it would be something like a
register machine (as opposed to a stack machine).
No, it isn't *useful*, but I'm not sure if you'd want to exclude it.
- John
John Nowak — 2009-01-01 10:54:20
On Jan 1, 2009, at 1:37 AM, William Tanksley, Jr wrote:
> I do suspect that the definition might be a little improved by
> hybridizing it with your newest one, perhaps something like this:
>
> "A concatenative programming language is language in which terms
> correspond to functions and in which the juxtaposition of terms
> denotes an associative operation on functions."
>
> Is it TOO general? It seems to me to cover all the cases, even the
> non-interesting ones (such as where the operation is multiplication).
I'd say yes. Ideally, we'd like to be both clear *and* precise. I
think such a definition would satisfy the first requirement (it's
clear) but not the latter (it's too broad to be useful). It might be
worth considering if we had some other interesting associative
operations to base a programming language on, but I (thankfully) can't
think of any.
- John
John Cowan — 2009-01-01 10:59:53
John Nowak scripsit:
> I'd say yes. Ideally, we'd like to be both clear *and* precise. I
> think such a definition would satisfy the first requirement (it's
> clear) but not the latter (it's too broad to be useful). It might be
> worth considering if we had some other interesting associative
> operations to base a programming language on, but I (thankfully) can't
> think of any.
I agree. It seems to me essential for a concatenative language that the
associative operation in question be composition and not something else.
--
John Cowan
http://ccil.org/~cowan cowan@...
[T]here is a Darwinian explanation for the refusal to accept Darwin.
Given the very pessimistic conclusions about moral purpose to which his
theory drives us, and given the importance of a sense of moral purpose
in helping us cope with life, a refusal to believe Darwin's theory may
have important survival value. --Ian Johnston
Christopher Diggins — 2009-01-01 15:57:34
On Thu, Jan 1, 2009 at 1:37 AM, William Tanksley, Jr
<
wtanksleyjr@...> wrote:
> Christopher Diggins <cdiggins@...> wrote:
>> I just posted my newest definition of concatenative language at
>>
>> http://dobbscodetalk.com/index.php?option=com_myblog&show=What-is-a-Concatenative-Language.html&Itemid=29
>> with a deconstruction. I am happy to discuss it here (avoids the
>> headache of having to register to leave comments).
>
> That's a good definition.
Thanks.
> I did like the one you posted in the last thread, though; the one I
> listed as #2 in my list above. I like the fact that it explicitly
> mentions concatenation (making the rationale for the name clear),
I think that "juxtaposition of terms" is almost synonymous with
concatenation. For a computer scientist familiar with language theory
the terminology juxtaposition is more immediately recognizable. This
is the terminology used by more than one expert in the field.
> and
> it also depends on the concept of associativity, which directly drives
> the ability to easily factor.
I agree that the associative property of function composition drives
some of the interesting characteristics of the class of languages, but
I think this is not necessary in the formal definition, but is a
statement about why we are interested.
> I do suspect that the definition might be a little improved by
> hybridizing it with your newest one, perhaps something like this:
>
> "A concatenative programming language is language in which terms
> correspond to functions and in which the juxtaposition of terms
> denotes an associative operation on functions."
>
> Heh... That was simpler than I thought.
>
> Is it TOO general? It seems to me to cover all the cases, even the
> non-interesting ones (such as where the operation is multiplication).
I think it is too general. There are no interesting languages that I
know of that don't use composition as the fundamental operation. I
think restricting the definition to composition helps keep the class
of languages more useful, and makes the relation to traditional
functional languages more obvious.
My goal is to relate concatenative languages to functional languages,
especially the lambda calculus. I think this will help spur serious
study of the languages.
>> Christopher
>
> -Wm
Don Groves — 2009-01-01 21:01:08
On Jan 1, 2009, at 2:28 AM, John Nowak wrote:
>
> On Dec 31, 2008, at 11:07 PM, Don Groves wrote:
>
>>> 3. There's no reason that the data structure the functions operate
>>> on
>>> be a list or a stack. I recently proposed a language using vectors
>>> in
>>> the style of More's array theory. Earlier today, Chris proposed a
>>> language based on a deque. I believe XY works on a stack/queue
>>> tuple.
>>> Other possibilities are easy to dream up.
>>
>> The reason I picked "sequence" is that it seems to be the most basic
>> ordered structure.
>
> They need not be ordered. Consider a language that passed around a
> dictionary. Primitive operations would assume their arguments were
> stored at particular names. Essentially, it would be something like a
> register machine (as opposed to a stack machine).
>
> No, it isn't *useful*, but I'm not sure if you'd want to exclude it.
Sure it's useful. We do that now only we call them "files."
--
don
> - John
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
Robbert Dalen — 2009-01-01 23:09:17
My (very broad) definition would be:
'A concatenative language is a language wherein syntactically valid
expressions can be concatenated to yield syntactically valid
expressions.'
For instance, this definition includes all of the following (postfix)
expressions to be concatenative:
1
1 2
1 2 +
+
3 +
3 4 +
(and with a postfix concatenation of +):
1 2 + 3 4 + + == 10
the latter are all valid syntactic expressions, but may be not
*semantically* valid, depending on the specific concatenative language
in question.
Postfix, prefix or infix doesn't really matter for a language to be
concatenative or not.
For instance, it is perfectly ok for prefix expressions to be
concatenative:
1
1 2
+ 1 2
+
+ 3
+ 3 4
(and with a prefix concatenation of +):
+ + 1 2 + 3 4 = 10
infix expressions:
1
1 +
1 + 2
4
+ 4
3 + 4
(and with an infix concatenation of +):
1 + 2 + 3 + 4 == 10
Moreover, I think the 'concatenative languages are non-applicative'
argument is mood:
It is perfectly ok - and convenient - to have (postfix,prefix,infix)
lambdas. Here are three different expressions that swap 1 and 2:
postfix: 1 2 {x y=y x} == 1 {x=2 x} == 2 1
prefix: {x y=y x} 1 2 == {y=y 1} 2 == 2 1
infix1: 1 {x y=y x} 2 == 1 {x=2 x} == 2 1
infix2: 1 {x y=y x} 2 == {y=y 1} 2 == 2 1
Here, {...} constructs are anonymous, (partially applied) functions
which can be concatenated to other expressions, just as any other
primitive function.
However, only in the infix case the application order is needs to be
defined - either left-to-right or right-to-left - but that's it.
- robbert
[Non-text portions of this message have been removed]
William Tanksley, Jr — 2009-01-02 00:10:35
Christopher Diggins <
cdiggins@...> wrote:
> William Tanksley, Jr <wtanksleyjr@...> wrote:
>> I did like the one you posted in the last thread, though; the one I
>> listed as #2 in my list above. I like the fact that it explicitly
>> mentions concatenation (making the rationale for the name clear),
> I think that "juxtaposition of terms" is almost synonymous with
> concatenation. For a computer scientist familiar with language theory
> the terminology juxtaposition is more immediately recognizable. This
> is the terminology used by more than one expert in the field.
Okay, I grant that there's value in the word "juxtaposition" (unlike
"concatenate", it allows whitespace to be interposed). Accepted.
>> and
>> it also depends on the concept of associativity, which directly drives
>> the ability to easily factor.
> I agree that the associative property of function composition drives
> some of the interesting characteristics of the class of languages, but
> I think this is not necessary in the formal definition, but is a
> statement about why we are interested.
Logically speaking, it is necessary; you're implying below that it's
not sufficient. It's kind of nice to have the definition touch on one
of the main interesting properties of the language being defined,
don't you think?
It's worth mentioning that Nowak's original language wasn't
concatenative because it isn't associative; it actually DOES use
composition.
>> "A concatenative programming language is language in which terms
>> correspond to functions and in which the juxtaposition of terms
>> denotes an associative operation on functions."
>> Is it TOO general? It seems to me to cover all the cases, even the
>> non-interesting ones (such as where the operation is multiplication).
> I think it is too general. There are no interesting languages that I
> know of that don't use composition as the fundamental operation. I
> think restricting the definition to composition helps keep the class
> of languages more useful, and makes the relation to traditional
> functional languages more obvious.
Well, I may have to accept that, since I like your definition. I'm
just not sure about it -- we do know that other operators are
possible, we just don't know of any interesting ones.
> My goal is to relate concatenative languages to functional languages,
> especially the lambda calculus. I think this will help spur serious
> study of the languages.
By all means.
I like your definition well enough to support it as the official
definition. I do think the Wikipedia page should discuss some ways of
testing for concatenativity.
-Wm
John Nowak — 2009-01-02 00:23:44
On Jan 1, 2009, at 7:10 PM, William Tanksley, Jr wrote:
>> I agree that the associative property of function composition drives
>> some of the interesting characteristics of the class of languages,
>> but
>> I think this is not necessary in the formal definition, but is a
>> statement about why we are interested.
>
> Logically speaking, it is necessary; you're implying below that it's
> not sufficient. It's kind of nice to have the definition touch on one
> of the main interesting properties of the language being defined,
> don't you think?
>
> It's worth mentioning that Nowak's original language wasn't
> concatenative because it isn't associative; it actually DOES use
> composition.
I think the actual problem was that the juxtaposition of two functions
denoted composition, but the juxtaposition of three functions denoted
composition and construction.
Did you have something in mind where concatenation solely means
composition but somehow isn't associative? I'm not sure how this could
be possible unless the operation wasn't actually function composition.
Perhaps I'm not understanding you correctly.
- John
John Nowak — 2009-01-02 00:31:01
On Jan 1, 2009, at 6:09 PM, Robbert Dalen wrote:
> My (very broad) definition would be:
>
> 'A concatenative language is a language wherein syntactically valid
> expressions can be concatenated to yield syntactically valid
> expressions.'
This definition seems so broad as to have no useful consequences. At
least Tanksley's associative requirement would allow factoring and
some other basic forms of manipulation.
I think the thing to remember here is that we have things we want to
describe and things we don't care to describe. Since the definition
should be useful for our purposes, including a great number of things
we don't care about as "concatenative" probably isn't the way to go.
Getting away from having to say things like "a concatenative language
where concatenation denotes function composition" is the point of this
exercise in my opinion.
- John
Stevan Apter — 2009-01-02 13:12:19
i've stayed out of this wrangle. i've fallen into the habit of
using/interpreting "concatenative" to mean nothing more than
"joy-like." if someone claims that L is concatenative, and L
doesn't look like joy, then i look for an argument which connects
L in some non-obvious way with joy.
but now i think that robbert is correct. "concatenative" is
purely syntactic, and picks out just those languages where
concatenation is used to make wfes from wfes. at any rate,
that seems to match my "pre-theoretical" use of the term.
and that reminds me: robbert, can we have a status update on
enchilada?
----- Original Message -----
From: "John Nowak" <john@...>
To: <concatenative@yahoogroups.com>
Sent: Thursday, January 01, 2009 7:31 PM
Subject: Re: [stack] the concatenative wikipedia article
>
> On Jan 1, 2009, at 6:09 PM, Robbert Dalen wrote:
>
>> My (very broad) definition would be:
>>
>> 'A concatenative language is a language wherein syntactically valid
>> expressions can be concatenated to yield syntactically valid
>> expressions.'
>
> This definition seems so broad as to have no useful consequences. At
> least Tanksley's associative requirement would allow factoring and
> some other basic forms of manipulation.
>
> I think the thing to remember here is that we have things we want to
> describe and things we don't care to describe. Since the definition
> should be useful for our purposes, including a great number of things
> we don't care about as "concatenative" probably isn't the way to go.
> Getting away from having to say things like "a concatenative language
> where concatenation denotes function composition" is the point of this
> exercise in my opinion.
>
> - John
>
Robbert van Dalen — 2009-01-02 14:18:22
i do agree with john (nowak) that - if concatenativity is defined to
be purely syntactic - it would include too many (non-interesting)
languages.
however, the syntactic standpoint does *exclude* a whole bunch of
useful languages such as c(++), java, haskell,etc, that are not
concatenative.
also, john's latest definition on wikipedia:
'A concatenative language is a non-applicative programming language in
which all terms denote functions and the juxtaposition of functions
denotes function composition......
.. would rule out enchilada (www.enchiladacode.nl) to be concatenative because:
- not all terms in enchilada are functions
- therefor, the juxtaposition of functions doesn't always denotes
function composition
and what about forth? surely, we don't want forth to be excluded!
- robbert
On 1/2/09, Stevan Apter <sa@...> wrote:
> i've stayed out of this wrangle. i've fallen into the habit of
> using/interpreting "concatenative" to mean nothing more than
> "joy-like." if someone claims that L is concatenative, and L
> doesn't look like joy, then i look for an argument which connects
> L in some non-obvious way with joy.
>
> but now i think that robbert is correct. "concatenative" is
> purely syntactic, and picks out just those languages where
> concatenation is used to make wfes from wfes. at any rate,
> that seems to match my "pre-theoretical" use of the term.
>
> and that reminds me: robbert, can we have a status update on
> enchilada?
William Tanksley, Jr — 2009-01-02 14:20:41
John Nowak <
john@...> wrote:
> William Tanksley, Jr wrote:
>>> 1. 'f g' denotes the composition of 'f' and 'g'
>>> 2. 'f g h' denotes the composition of 'g' with the construction of
>>> 'f'
>>> and 'h' (construction is basically a cleave combinator)
>>> 3. Grouping is to the right such that 'f g h i j k == f g (h i (j
>>> k))'
>>> 4. Composition is associative such that '(f g) h == f (g h)'
>>> So, is this concatenative? It's just composition and cleave
>>> combinators.
>> As I see it, no. The problem is that grouping is semantically
>> significant (rule 3), but not syntactically significant (rules 1&2).
>> It violates my rule that a concatenative language must have
>> associative semantics and syntax -- that means no required implicit
>> grouping.
> So if I got rid of rules 2 and 3, would it be concatenative? It would
> have the same underlying semantics except concatenation is would
> always mean composition.
Yes -- if you provide syntax for cleave, the rest of the language is
clearly listlike and associative.
Unfortunately, the example you give doesn't appear to conform to the
rules I listed above; you seem to be using some alternative
non-concatenative syntax.
> This:
> (sq b) - 4 * a * c
> Would be written like this instead:
> - [sq b, * [4, * [a, c]]]
How is that concatenative? It appears totally applicative. I certainly
don't see any opportunity for associativity in that example... If this
is how things must be done, then I take it back: your language may
possibly technically use composition, but if it's not associative in
practice, it's not concatenative.
> If your answer is yes, my problem with that is that we don't impose
> the same syntactic restrictions on the definition of an applicative
> language.
We talk about applicative languages here, but the reality is that
there are many different syntaxes for applicative languages, united in
common by one syntactic feature: the need for a tree structure.
Calling a language "applicative" doesn't tell you what its syntax is
like (except that it must be tree-structured), while calling a
language concatenative does tell you what its syntax is like.
I think it's proper to define and classify languages in terms of their
syntax, as long as one remembers that syntax and semantics are tied
together by definition of "language". "Applicative" is not such a
classification; "concatenative" was intended to be. Remember the
now-obsolete term "flat", that was intended to be a subset of
"concatenative"? I decided there was little need for flatness once we
realized that associativity neatly explained concatenative ease of
use; but flatness is syntactic too. Other syntactic classifications
include tree-structured, LL, LALR, etc...
> Tons of syntaxes are employed (Lisp, Haskell, J, FP, etc),
> yet we still call them all applicative. Perhaps concatenative isn't
> the right term, but I'd very much like a term focused strictly on
> semantics like "applicative" is. Again, "compositional" or similar
> seems like the obvious choice with "concatenative" being a subset
> defined partially by its syntax.
Composition is a possible term for semantics... I suppose you could
use it. It doesn't seem very useful, since as Chris and I have been
hammering out, it's neither a subset nor a superset, but rather just
one feature a language can have. An applicative language can have
compositional semantics in some part of its syntax (your language
appears to be an example of that), and that part of its syntax will be
concatenative... but it's kind of hard to say that it's a
concatenative language, since actual use of associativity is very
rare.
> - John
-Wm
John Nowak — 2009-01-02 21:26:32
On Jan 2, 2009, at 9:18 AM, Robbert van Dalen wrote:
> i do agree with john (nowak) that - if concatenativity is defined to
> be purely syntactic - it would include too many (non-interesting)
> languages.
>
> however, the syntactic standpoint does *exclude* a whole bunch of
> useful languages such as c(++), java, haskell,etc, that are not
> concatenative.
So would the category of all languages that use 'car' and 'cdr' to
take the head and tail of a list. Such a category would basically mean
Lisp and derivatives, but the definition of the category itself
wouldn't let us say anything useful. I think that's the danger with
your definition: It allows the things we want to allow, but doesn't
let us say anything about them.
> and what about forth? surely, we don't want forth to be excluded!
I don't think the definition Chris proposed would necessarily exclude
Forth. If you think there's an issue with parse words, perhaps there's
some way to alter the definition?
> - not all terms in enchilada are functions
> - therefor, the juxtaposition of functions doesn't always denotes
> function composition
Enchilada is what I'd call a postfix term rewriting language. I don't
think I'd consider it concatenative due to the presence of lambdas.
Discussions in the past have indicated that lexical scope and
substitution are not compatible with concatenativity. For example,
given the expression '{a b=a b +}', I cannot define 'f' to be 'b +'
and then say '{a b=a b +} == {a b=a f}'.
- John
John Nowak — 2009-01-02 21:41:03
On Jan 2, 2009, at 9:20 AM, William Tanksley, Jr wrote:
>> This:
>> (sq b) - 4 * a * c
>> Would be written like this instead:
>> - [sq b, * [4, * [a, c]]]
>
> How is that concatenative? It appears totally applicative. I certainly
> don't see any opportunity for associativity in that example
You're right, there isn't any opportunity for it in that example
because there's no contiguous composition of more than two functions.
Perhaps this is a better example:
a = hd
b = hd tl
c = hd tl tl
hypot = sqrt + [sq a, sq b]
Or, you could do something like this:
sq-top = cons [sq a, tl]
hypot = sqrt + sq swap sq
I don't think it would be reasonable to say this isn't concatenative
just because the average number of contiguous compositions is somewhat
lower than in a stack-based language. They both share the all
properties highlighted on the wikipedia entry-in-progress.
>> If your answer is yes, my problem with that is that we don't impose
>> the same syntactic restrictions on the definition of an applicative
>> language.
>
> We talk about applicative languages here, but the reality is that
> there are many different syntaxes for applicative languages, united in
> common by one syntactic feature: the need for a tree structure.
Applicative languages do not need a tree structure. The combinatory
calculus is applicative and can even be written with a "concatenative"
syntax. Look at Unlambda.
> I think it's proper to define and classify languages in terms of their
> syntax
Agreed, ideally provided another term is available for languages with
the same semantics but a different syntax. Lacking such a term, I
think we lack the capability to talk about an interesting family of
languages. In any case, I have no issue with making the term
"concatenative" have syntactic implications as the Wikipedia entry-in-
progress indicates.
- John
Robbert Dalen — 2009-01-02 22:15:36
> So would the category of all languages that use 'car' and 'cdr' to
>
> take the head and tail of a list. Such a category would basically mean
> Lisp and derivatives, but the definition of the category itself
> wouldn't let us say anything useful. I think that's the danger with
> your definition: It allows the things we want to allow, but doesn't
> let us say anything about them.
>
bad example: car and cdr talk about semantics not syntax.
but you are right: we want positive statements, not negative.
in true leo brouwer style:
'let's be constructive!'
> Enchilada is what I'd call a postfix term rewriting language. I don't
> think I'd consider it concatenative due to the presence of lambdas.
> Discussions in the past have indicated that lexical scope and
> substitution are not compatible with concatenativity. For example,
> given the expression '{a b=a b +}', I cannot define 'f' to be 'b +'
> and then say '{a b=a b +} == {a b=a f}'.
>
there is a catch:
a lambda in enchilada is an unary (monadic) operator that is also a
atomic term.
as a consequence, you can't substitute expressions that are within the
{scope} of a lambda.
also, definitions shouldn't contain free variables (or symbols as they
are called in enchilada)
> - John
- robbert.
John Nowak — 2009-01-02 22:31:27
On Jan 2, 2009, at 5:15 PM, Robbert Dalen wrote:
>> Enchilada is what I'd call a postfix term rewriting language. I don't
>> think I'd consider it concatenative due to the presence of lambdas.
>> Discussions in the past have indicated that lexical scope and
>> substitution are not compatible with concatenativity. For example,
>> given the expression '{a b=a b +}', I cannot define 'f' to be 'b +'
>> and then say '{a b=a b +} == {a b=a f}'.
>
> there is a catch:
>
> a lambda in enchilada is an unary (monadic) operator that is also a
> atomic term. as a consequence, you can't substitute expressions that
> are within the {scope} of a lambda.
Quotations are atomic terms too (i.e. they are a single element), but
you can still factor out subexpressions within them. Maybe what you're
trying to say is at the entire lambda is an atom in the sense that you
can't open it up any further. I would agree that this means you can't
substitute expressions (by definition), but it would also mean that
what you have inside isn't a concatenative expression because none of
the normal rules apply.
> also, definitions shouldn't contain free variables (or symbols as they
> are called in enchilada)
But variables can be free at points within a definition? That seems
like further evidence that something isn't compositional.
All that said, it's clear that Enchilada is "concatenativish". Perhaps
this is just a case where we need a mostly-concatenative/purely-
concatenative distinction.
- John
Joe Bowbeer — 2009-01-02 23:52:05
Keep in mind that wikipedia is not where new definitions should be blazed.
The articles should be written in layman's terms, from a neutral point of
view, and supported by citations.
See "No original research" and "Neutral point of view". In particular:
All Wikipedia articles and other encyclopedic content must be written from a
> neutral point of view, representing fairly, and as far as possible without
> bias, all significant views that have been published by reliable sources.
>
Can anyone find a reference for the statement that "concatenative" is not
universally accepted as a useful term?
Joe
On Tue, Dec 30, 2008 at 9:27 PM, John Nowak wrote:
> The Wikipedia article on concatenative languages has a number of
> issues that I think should be addressed. I'm willing to make the
> changes, but I'd like to make sure I'm not off-base first.
>
> I realize many of these concerns are rather tired at this point. I
> apologize. However, that doesn't change the fact that they've gone
> unresolved. Indeed, there seems to be almost a resistance to resolving
> them. I personally think that the non-applicative style of programming
> has important properties and that it would be great to have a term for
> them so I could stop redefining "concatenative" every time I talk to
> someone (including those knowledgeable about concatenative languages).
>
> Here are my issues with the article:
>
> 1. Concatenative should not be conflated with "stack-based". I have
> already shown that the counter-examples are beyond mere curiosities.
>
> 2. It should be more clearly stressed that concatenative languages are
> not applicative. The reduction of a concatenative expression is the
> simplification of one function to another function (e.g. '1 2 + + ==>
> 3 +'). Never is it necessary to deal with objects or application, and
> much is gained by not doing so (as is mentioned at
> http://www.latrobe.edu.au/philosophy/phimvt/joy/j08cnt.htm)
> .
>
> 3. There is no reason concatenative languages must use a postfix
> syntax. A prefix syntax is also a valid approach. Other syntaxes are
> useful (as I've shown recently with my infix construction syntax
> similar to that of in FL and J) but ruled out by the need for
> concatenation to always denote composition (which I think is probably
> unfortunate).
>
> 4. Not all concatenative languages have parsing words or an equivalent
> to macros. Talking about them here makes as much sense as talking
> about macros on a page about applicative programming.
>
> 5. It should be stressed that concatenative languages are function-
> level and pointfree. They also go beyond languages like Backus's FP in
> that objects are entirely removed from the language; The expression
> '3' represents a *function*, not an object.
>
> 6. I dislike the sentence "The term 'concatenative' is not universally
> accepted as a particularly useful term". It's an objectively useful
> term if some care is given to its definition; What's "universally
> accepted" is unimportant. Hell, even Slava (who says it's unimportant)
> has started concatenative.org (which lists C++ and Java as
> "interesting languages"... ugh).
>
> So, should I make the changes or should I just define a new term so I
> that can communicate with people without boring myself? I did like
> Diggins's "compositional" suggestion which is more to the point; The
> fact that it is already used in various vague ways doesn't disturb me
> too much.
>
> Sorry for bringing this up *again*, but I'm trying to write a paper
> and keep stumbling over how to describe what it is that I'm talking
> about.
>
> - John
>
>
[Non-text portions of this message have been removed]
John Nowak — 2009-01-03 00:07:43
On Jan 2, 2009, at 6:52 PM, Joe Bowbeer wrote:
> Keep in mind that wikipedia is not where new definitions should be
> blazed.
Agreed, but I don't think that's what we're doing. We're trying to
correct a definition that has obvious deficiencies. Given the nature
of things, I think the discussion we're having now is about as good of
a "source" as you're going to get.
> The articles should be written in layman's terms, from a neutral
> point of
> view, and supported by citations.
The "layman's terms" requirement is not so clear. Go look at the page
on type theory and tell me that it's in layman's terms. Do you have
any suggestions for how the article I've proposed might be simplified?
> Can anyone find a reference for the statement that "concatenative"
> is not
> universally accepted as a useful term?
I've not been able to find anything. The only thing I've seen along
this lines has been casual comments in the #concatenative chat room on
freenode. In either case, I don't think it really belongs in the
article. I don't think "dynamically typed" is a good term either, but
we're stuck with it. The same goes for "strong typing" which is used
to mean almost anything.
- John
John Nowak — 2009-01-03 00:18:40
On Jan 2, 2009, at 7:07 PM, John Nowak wrote:
> 've not been able to find anything. The only thing I've seen along
> this lines has been casual comments in the #concatenative chat room on
> freenode. In either case, I don't think it really belongs in the
> article. I don't think "dynamically typed" is a good term either, but
> we're stuck with it. The same goes for "strong typing" which is used
> to mean almost anything.
In retrospect, this is a pretty flawed analogy.
Perhaps it is worthwhile for the article to say that the term
"concatenative" is relatively new and its meaning is not well-
established. That's different than saying it isn't useful, which I
think it clearly is (as we, you know, use it).
- John
Joe Bowbeer — 2009-01-03 02:16:57
On Fri, Jan 2, 2009 at 4:18 PM, John Nowak wrote:
>
> On Jan 2, 2009, at 7:07 PM, John Nowak wrote:
>
> > 've not been able to find anything. The only thing I've seen along
> > this lines has been casual comments in the #concatenative chat room on
> > freenode. In either case, I don't think it really belongs in the
> > article. I don't think "dynamically typed" is a good term either, but
> > we're stuck with it. The same goes for "strong typing" which is used
> > to mean almost anything.
>
> In retrospect, this is a pretty flawed analogy.
>
> Perhaps it is worthwhile for the article to say that the term
> "concatenative" is relatively new and its meaning is not well-
> established. That's different than saying it isn't useful, which I
> think it clearly is (as we, you know, use it).
>
> - John
>
That sounds reasonable.
FWIW, I think of Joy and Factor when I think of concatenative. I would
describe Forth as a precursor.
Joe
[Non-text portions of this message have been removed]
William Tanksley, Jr — 2009-01-12 03:51:52
John Nowak <
john@...> wrote:
> William Tanksley, Jr wrote:
> Perhaps this is a better example:
Thanks :-).
> a = hd
> b = hd tl
> c = hd tl tl
> hypot = sqrt + [sq a, sq b]
> Or, you could do something like this:
> sq-top = cons [sq a, tl]
> hypot = sqrt + sq swap sq
> I don't think it would be reasonable to say this isn't concatenative
> just because the average number of contiguous compositions is somewhat
> lower than in a stack-based language. They both share the all
> properties highlighted on the wikipedia entry-in-progress.
I'm having a hard time grasping the rules, so I'm limited to asking
questions. But if a pair of definitions are valid, is their
juxtaposition also always valid? I don't see why not, so on those
grounds I think I'll say your language is concatenative. No, I don't
care to measure the average number of compositions either :-).
The interesting thing about a hybrid language like this is that we
might get a chance to compare which part of the language most people
wind up using. In this hybrid I'd say that concatenativity is favored,
since it's the default operation; I could also imagine a language
where composition is indicated by an explicit operator, and simple
juxtaposition indicated curried application.
>>> If your answer is yes, my problem with that is that we don't impose
>>> the same syntactic restrictions on the definition of an applicative
>>> language.
>> We talk about applicative languages here, but the reality is that
>> there are many different syntaxes for applicative languages, united in
>> common by one syntactic feature: the need for a tree structure.
> Applicative languages do not need a tree structure. The combinatory
> calculus is applicative and can even be written with a "concatenative"
> syntax. Look at Unlambda.
Every applicative language has a tree structure; unlambda is no
exception. The tree structure arises when a "parent" syntactic element
(a function) takes more than one "child" syntactic elements (the
parameters applied to the function). This is a hidden advantage that
applicative combinator languages have over concatenative combinators.
See the page that ieros/Kerby wrote on concatenative combinators. In
order to make up for this advantage, concatenative combinators have to
be more complex than applicative ones. In short, conc. combinators
have to provide a "make siblings" operation, while applicative
combinators don't need that because they have a sibling operation
implicit in their syntax.
>> I think it's proper to define and classify languages in terms of their
>> syntax
> Agreed, ideally provided another term is available for languages with
> the same semantics but a different syntax. Lacking such a term, I
> think we lack the capability to talk about an interesting family of
> languages. In any case, I have no issue with making the term
> "concatenative" have syntactic implications as the Wikipedia entry-in-
> progress indicates.
To me, the interesting thing about these languages is precisely that
the mathematical properties of their syntax and semantics match so
well.
If we called them "associative" languages perhaps I'd be mollified...
But it's already been used in computer language science.
> - John
-Wm
John Nowak — 2009-01-12 06:53:16
On Jan 11, 2009, at 10:51 PM, William Tanksley, Jr wrote:
>> Perhaps this is a better example:
>
> I'm having a hard time grasping the rules, so I'm limited to asking
> questions. But if a pair of definitions are valid, is their
> juxtaposition also always valid?
Yep. It's just composition in the opposite order.
> I could also imagine a language where composition is indicated by
> an explicit operator, and simple juxtaposition indicated curried
> application.
Sounds like Haskell to me! The reason Haskell sucks for pointfree
programming though is that most of the functions are curried. As such,
you need to modify the functions to get data into the correct places
(e.g. 'flip f') rather than manipulating the data directly (e.g. 'f .
swap'). All existing and proposed concatenative languages opt for
handling multiple values via products (stacks, lists, etc) rather than
using curried functions. All other pointfree language (FP, FL) or
mostly pointfree languages (APL, J, etc) that I can think of do the
same.
>> Applicative languages do not need a tree structure. The combinatory
>> calculus is applicative and can even be written with a
>> "concatenative"
>> syntax. Look at Unlambda.
>
> Every applicative language has a tree structure; unlambda is no
> exception.
I think I may've taken tree structure too literally. I see your point.
> See the page that ieros/Kerby wrote on concatenative combinators. In
> order to make up for this advantage, concatenative combinators have to
> be more complex than applicative ones. In short, conc. combinators
> have to provide a "make siblings" operation, while applicative
> combinators don't need that because they have a sibling operation
> implicit in their syntax.
I'm not quite sure I understand. I'm going to guess (correct me if I'm
wrong) that you mean concatenative functions need to preserve the
values they don't act upon:
Applicative:
\x y -> x + y
"Concatenative":
\((s, x), y) -> (s, x + y)
If that's what you mean, I don't think you're correct. I won't
elaborate though as I probably misunderstood things. Please clarify if
you can.
- John
William Tanksley, Jr — 2009-01-12 14:44:17
John Nowak <
john@...> wrote:
> William Tanksley, Jr wrote:
>> I could also imagine a language where composition is indicated by
>> an explicit operator, and simple juxtaposition indicated curried
>> application.
> Sounds like Haskell to me! The reason Haskell sucks for pointfree
> programming though is that most of the functions are curried. As such,
Interesting point... I wouldn't have expected that currying would
hurt. This just shows what little I know.
>> See the page that ieros/Kerby wrote on concatenative combinators. In
>> order to make up for this advantage, concatenative combinators have to
>> be more complex than applicative ones. In short, conc. combinators
>> have to provide a "make siblings" operation, while applicative
>> combinators don't need that because they have a sibling operation
>> implicit in their syntax.
> I'm not quite sure I understand. I'm going to guess (correct me if I'm
> wrong) that you mean concatenative functions need to preserve the
> values they don't act upon:
Sorry for the unclarity -- no. A 'sibling' operation refers to
something like 'pair'; a way to encode two data items at the same
level of nesting.
The most glaring example of where this comes into play is when I tried
to design a minimal-combinator basis for a concatenative languages.
The minimal basis for applicative languages contains one combinator;
the minimal basis for concatenative languages contains two
(
http://portal.acm.org/citation.cfm?id=967781.967785 has a proof). The
reason is that applicative languages hide some program complexity in
their syntax: a combinator that takes more than one parameter makes
its parameters siblings in the parse tree.
> - John
-Wm
John Nowak — 2009-01-12 17:33:33
On Jan 12, 2009, at 9:44 AM, William Tanksley, Jr wrote:
> Sorry for the unclarity -- no. A 'sibling' operation refers to
> something like 'pair'; a way to encode two data items at the same
> level of nesting.
Ah. Thanks for clarifying.
> The minimal basis for applicative languages contains one combinator;
> the minimal basis for concatenative languages contains two
> (http://portal.acm.org/citation.cfm?id=967781.967785 has a proof).
This doesn't seem to be the case for a concatenative language with
quotation (push). Okasaki is dealing with the additional limitation of
"flatness". I suppose you could count quotation as a combinator of
sorts, but in either case it's a very simple operation.
> See the page that ieros/Kerby wrote on concatenative combinators. In
> order to make up for this advantage, concatenative combinators have to
> be more complex than applicative ones
I'm not sure this is the case. Quotation, composition, and one
combinator doesn't seem more complex than application and one
combinator to me, just different. Here's Meertens on the subject (I
believe from
http://portal.acm.org/citation.cfm?id=746988):
"The basic problem is that the basic operation of the classical
combinator calculus (and also of the closely related lambda calculus)
is application instead of composition. Application has not a single
property. Function composition is associative and has an identity
element (if one believes in the 'generic' identity function)."
Perhaps I'm wrong, but I think you may be judging "complexity" simply
by counting the number of primitive elements. I don't think this is a
useful metric.
- John
William Tanksley, Jr — 2009-01-12 18:19:26
John Nowak <
john@...> wrote:
> William Tanksley, Jr wrote:
>> The minimal basis for applicative languages contains one combinator;
>> the minimal basis for concatenative languages contains two
>> (http://portal.acm.org/citation.cfm?id=967781.967785 has a proof).
> This doesn't seem to be the case for a concatenative language with
> quotation (push). Okasaki is dealing with the additional limitation of
> "flatness". I suppose you could count quotation as a combinator of
> sorts, but in either case it's a very simple operation.
I have to blush -- I'd forgotten that part. Yes, you're right; I was
thinking of a purely concatenative language, one with no
non-associative syntax at all (AKA "flat"). Quotation is a strange
thing to throw into an allegedly concatenative combinator base,
though; unlike application, it's not an inherent part of the language
paradigm; thus, I think my confusion is justified.
>> See the page that ieros/Kerby wrote on concatenative combinators. In
>> order to make up for this advantage, concatenative combinators have to
>> be more complex than applicative ones
> I'm not sure this is the case. Quotation, composition, and one
> combinator doesn't seem more complex than application and one
> combinator to me, just different. Here's Meertens on the subject (I
> believe from http://portal.acm.org/citation.cfm?id=746988):
I'm not saying that the entire language is more complex; I'm saying
that the combinator basis is more complex, as measured by the fact
that you must have two combinators rather than only one.
Meertens is interesting; thank you for the reference. I've put it on
my "read immediately" stack.
> Perhaps I'm wrong, but I think you may be judging "complexity" simply
> by counting the number of primitive elements. I don't think this is a
> useful metric.
http://barker.linguistics.fas.nyu.edu/Stuff/Iota/
There are many ways to measure the "complexity" of a combinator. None
of them are obviously correct.
> - John
-Wm
pml060912 — 2009-01-13 12:29:13
--- In
concatenative@yahoogroups.com, "William Tanksley, Jr"
<wtanksleyjr@...> wrote:
>
> John Nowak <john@...> wrote:
> > William Tanksley, Jr wrote:
> >> The minimal basis for applicative languages contains one combinator;
> >> the minimal basis for concatenative languages contains two
> >> (http://portal.acm.org/citation.cfm?id=967781.967785 has a proof).
>
> > This doesn't seem to be the case for a concatenative language with
> > quotation (push). Okasaki is dealing with the additional limitation of
> > "flatness". I suppose you could count quotation as a combinator of
> > sorts, but in either case it's a very simple operation.
>
> I have to blush -- I'd forgotten that part. Yes, you're right; I was
> thinking of a purely concatenative language, one with no
> non-associative syntax at all (AKA "flat"). Quotation is a strange
> thing to throw into an allegedly concatenative combinator base,
> though; unlike application, it's not an inherent part of the language
> paradigm; thus, I think my confusion is justified.
Well, where does Furphy fit in this breakdown?
(
http://users.beagle.com.au/peterl/furphy.html)
Although it does have quotation, as I mentioned elsewhere that's just
syntactic sugar. The fundamental constructs are Reverse Polish naming
and concatenation, which can use the complementary keywords FREEZE and
THAW to defer and invoke evaluation/execution - and those can be built
from the return stack manipulation keywords R> and >R already found in
Forth. That looks fairly associative/flat to me.
William Tanksley, Jr — 2009-01-13 14:39:03
pml060912 <
pml540114@...> wrote:
> "William Tanksley, Jr" <wtanksleyjr@...> wrote:
>> non-associative syntax at all (AKA "flat"). Quotation is a strange
>> thing to throw into an allegedly concatenative combinator base,
>> though; unlike application, it's not an inherent part of the language
>> paradigm; thus, I think my confusion is justified.
> Well, where does Furphy fit in this breakdown?
> (http://users.beagle.com.au/peterl/furphy.html)
> Although it does have quotation, as I mentioned elsewhere that's just
> syntactic sugar. The fundamental constructs are Reverse Polish naming
> and concatenation, which can use the complementary keywords FREEZE and
> THAW to defer and invoke evaluation/execution - and those can be built
> from the return stack manipulation keywords R> and >R already found in
> Forth. That looks fairly associative/flat to me.
Furphy is a fascinating language; I had no idea it had such an
interesting loop system. I'd say that Furphy probably is
flat/completely associative; but note that I'm not sure what to do
with the "Reverse Polish naming" system.
Furphy's loop system isn't strictly needed in order to be completely
associative; a ColorForth-like scheme would also work, where a label
(word name) is identified by a special character, tail recursion is
automatic, and the compiler recognizes the return operator.
For those who don't know ColorForth: Colorforth uses "labels" instead
of having distinct words; unlike Forth, where a word name begins a new
definition (which implies that the old definition is finished), a
ColorForth definition merely implies a new entry point.
Correspondingly, the ";" word in ColorForth compiles a return (which
will normally be optimized to a tail call) rather than strictly ending
the current definition.
ColorForth itself is not flat, because it keeps the concept of
immediate words; however, it would be easy to do the same thing a
Furphy and remove the need for all the immediates.
Unfortunately, Furphy is a foreign language to me, so I can't
understand the discussion of FREEZE and THAW. I think the use of
"Reverse Polish Naming" is blocking my understanding -- I can't tell
when a word I don't recognize is intended to be a definition versus
when it's simply unfamiliar to me. With all due respect, I'm pretty
sure that Reverse Polish Naming isn't a good idea; it's way too easy
to mess a file's semantics up by pre-defining one of the words it
intends to define. I'd far rather make definitions explicit.
-Wm
pml060912 — 2009-01-14 12:58:16
--- In
concatenative@yahoogroups.com, "William Tanksley, Jr"
<wtanksleyjr@...> wrote:
>
> pml060912 <pml540114@...> wrote:
.
.
.
> > Well, where does Furphy fit in this breakdown?
> > (http://users.beagle.com.au/peterl/furphy.html)
> > Although it does have quotation, as I mentioned elsewhere that's just
> > syntactic sugar. The fundamental constructs are Reverse Polish naming
> > and concatenation, which can use the complementary keywords FREEZE and
> > THAW to defer and invoke evaluation/execution - and those can be built
> > from the return stack manipulation keywords R> and >R already found in
> > Forth. That looks fairly associative/flat to me.
>
> Furphy is a fascinating language; I had no idea it had such an
> interesting loop system. I'd say that Furphy probably is
> flat/completely associative; but note that I'm not sure what to do
> with the "Reverse Polish naming" system.
.
.
.
> Unfortunately, Furphy is a foreign language to me, so I can't
> understand the discussion of FREEZE and THAW.
The discussion is mainly aimed at describing what is going on behind
the scenes and how to use the constructs in coding. Your comments
imply that I need to work on that part of the page. You might find it
easier to think of them in terms of continuations - FREEZE sets one up
and THAW uses it.
I think the use of
> "Reverse Polish Naming" is blocking my understanding -- I can't tell
> when a word I don't recognize is intended to be a definition versus
> when it's simply unfamiliar to me.
I can see how that would matter for following someone else's code, not
so much for the coding process itself. I was thinking of addressing it
with compiler warning messages and a prettyprinting standard for
coding (it would be easy for the compiler to generate that as part of
a log).
In my examples I've tried to separate code that way, so each
"paragraph" (maybe only one line) either ends with a definition or is
the last one (which will be run). Maybe I need to be clearer and
double check that there is always an "and run" paragraph for each
example or a clear indication that I'm not providing one (technically,
I am - a null one).
With all due respect, I'm pretty
> sure that Reverse Polish Naming isn't a good idea; it's way too easy
> to mess a file's semantics up by pre-defining one of the words it
> intends to define. I'd far rather make definitions explicit.
This comes as part of the larger problem of making typos - the low to
zero amount of syntax means that the compiler doesn't enforce/catch
things as much as many languages would. But I want to stay with the
Forth spirit of trusting and enabling the programmer, so I think
warnings for each new word are enough. Also, I don't want to introduce
"special" handling that would bring back modes or the equivalent,
except as syntactic sugar like the quotation system, to keep the
fundamentals simple and consistent. So I'll give some thought to
syntactic sugar for naming, i.e. something that could be handled by a
preprocessor even though actual implementation would use immediate
keywords to integrate it with the compiler - suggestions welcome.
William Tanksley, Jr — 2009-01-15 12:39:28
pml060912 <
pml540114@...> wrote:
> "William Tanksley, Jr" <wtanksleyjr@...> wrote:
>> I think the use of
>> "Reverse Polish Naming" is blocking my understanding -- I can't tell
>> when a word I don't recognize is intended to be a definition versus
>> when it's simply unfamiliar to me.
> I can see how that would matter for following someone else's code, not
> so much for the coding process itself.
If I come back to the same code tomorrow, it might as well be somebody
else's code :-).
> I was thinking of addressing it
> with compiler warning messages and a prettyprinting standard for
> coding (it would be easy for the compiler to generate that as part of
> a log).
> In my examples I've tried to separate code that way, so each
> "paragraph" (maybe only one line) either ends with a definition or is
> the last one (which will be run). Maybe I need to be clearer and
> double check that there is always an "and run" paragraph for each
> example or a clear indication that I'm not providing one (technically,
> I am - a null one).
I'm really not understanding 90% of what you're saying, so the
following is just a guess. I *think* you're proposing that Furphy be
made whitespace-sensitive, so that definitions have to/are recommended
to fall within certain formats. This reminds me of ColorForth, and I'm
in favor of it.
On the other hand, I'm not in favor of warning messages for syntax. If
you're going to make the compiler take cues from whitespace, make them
the ONLY cues it takes. For example, suppose that you wanted to make a
definition (by convention) be the last word in a paragraph; in that
case, set up the compiler so that if a word's terminated by a newline
it's automatically treated as a definition, and if the word's already
defined it's an error. I don't like that convention, but it'd work.
I'd prefer a visible convention, for example creating a label every
time a word begins on column zero (so definition names would be
against the left margin, and everything else would be indented). An
even more graceful requirement would be to use a visible character
tacked onto the desired definition, like a colon or equals sign.
> This comes as part of the larger problem of making typos - the low to
> zero amount of syntax means that the compiler doesn't enforce/catch
> things as much as many languages would. But I want to stay with the
> Forth spirit of trusting and enabling the programmer, so I think
> warnings for each new word are enough.
A compiler that trusts the programmer doesn't feel the need to emit
warning messages.
You definitely have gotten rid of an annoyance in Forth by inventing
this modeless compiler; but I think your first solution isn't as
modeless as you think. Instead of having one state variable, its state
is the entire dictionary.
> Also, I don't want to introduce
> "special" handling that would bring back modes or the equivalent,
> except as syntactic sugar like the quotation system, to keep the
> fundamentals simple and consistent. So I'll give some thought to
> syntactic sugar for naming, i.e. something that could be handled by a
> preprocessor even though actual implementation would use immediate
> keywords to integrate it with the compiler - suggestions welcome.
Some examples are above :-). My preference is the visible character
attached to the definition -- perhaps an equals sign at the beginning
of the word, since your words appear after the thing they define.
And by the way, your solution is extremely modal, according to
Raskin's definition: "An human-machine interface is modal with respect
to a given gesture when (1) the current state of the interface is not
the user's locus of attention and (2) the interface will execute one
among several different responses to the gesture, depending on the
system's current state." (Raskin, "The Humane Interface", Page 42,
cited on Wikipedia). The "gesture" is typing a word, and the system's
current state is what words are currently defined. Because of the size
of the state, it's impossible to have the state ever be the locus of
the user's attention; thus, there will be a lot of modal errors.
-Wm
John Nowak — 2009-01-15 17:17:48
On Jan 13, 2009, at 7:29 AM, pml060912 wrote:
> Well, where does Furphy fit in this breakdown?
> (http://users.beagle.com.au/peterl/furphy.html)
>
> Although it does have quotation, as I mentioned elsewhere that's just
> syntactic sugar. The fundamental constructs are Reverse Polish naming
> and concatenation, which can use the complementary keywords FREEZE and
> THAW to defer and invoke evaluation/execution - and those can be built
> from the return stack manipulation keywords R> and >R already found in
> Forth. That looks fairly associative/flat to me.
Interesting!
Here are the semantics I'd use (in a more Joy-like, single-stack
context):
freeze F -> [F] F
F [G] thaw -> G
This is the first time I've had a rewrite rule with a "row" on the
*right* side of the function.
What 'freeze' would basically do is take the rest of the program and
return a new program that is prefixed with a quoted version of itself.
What 'thaw' would do is take a program 'F' with a quotation '[G]' on
top and return the new program 'G'. This seems like something that
could be added to a Joy-like language very simply (excepting that
pesky "implementation" part).
This sounds a lot like XY:
http://www.nsl.com/k/xy/xy.htm
- John