initial stab at a wikipedia entry

[John Nowak]

http://en.wikipedia.org/wiki/User:John_Nowak/Sandbox/Concatenative

I'm sure it needs more work. Any input would be appreciated (or just  
go ahead and edit it).

- John

[William Tanksley, Jr]

That's a very nice entry; it gives a good survey.

I'm not sure how useful the link to "applicative" is, mainly because
the article linked to is sadly non-descriptive. But that's not our
fault.

"Concatenative languages are necessarily point-free as allowing terms
to denote variables would violate the rule that all terms denote
functions."

Not true -- a variable can be modeled (loosely) as an implicit
function of time. Forth provides local and global variables; locals
seem to make a language less concatenative, while globals don't hinder
it so much. (Naturally, globals have other problems.)

This should probably be written as saying that concatenative
languages, like other data-flow languages (whoops! we should mention
near the top that concatenative languages ARE dataflow languages),
encourage a point-free style.

I'm also thinking about expanding the point about monoids a bit. We
have a little to be said on that issue that can't be said on the page
about monoids.

-Wm


On 1/2/09, John Nowak <john@...> wrote:

> http://en.wikipedia.org/wiki/User:John_Nowak/Sandbox/Concatenative
>
> I'm sure it needs more work. Any input would be appreciated (or just
> go ahead and edit it).
>
> - John
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[John Nowak]

On Jan 2, 2009, at 9:50 AM, William Tanksley, Jr wrote:

> Not true -- a variable can be modeled (loosely) as an implicit
> function of time. Forth provides local and global variables; locals
> seem to make a language less concatenative, while globals don't hinder
> it so much. (Naturally, globals have other problems.)

Global variables can be treated as functions that read/write some  
state that gets passed through the program thanks to the monoidal  
nature of things. Local variables cannot; their scopes are local and  
hence you can't factor out code that references a local variable. The  
only way of explaining locals is in terms of substitution.

I'm not sure if you think my explanation above rules out locals. If  
not, perhaps it would be beneficial to include "factorability" as part  
of the definition of concatenative languages, e.g. 'f g h == f i where  
i == g h'. I was hoping to get away without having to explicitly  
mention this (and hence doubling the length of the definition).

> I'm also thinking about expanding the point about monoids a bit. We
> have a little to be said on that issue that can't be said on the page
> about monoids.

You're right. My only problem is trying to find something to cite in  
the logs. I'll come up with something most likely...

- John

[pml060912]

--- In concatenative@..., John Nowak <john@...> wrote:

>
>
> On Jan 2, 2009, at 9:50 AM, William Tanksley, Jr wrote:
>
> > Not true -- a variable can be modeled (loosely) as an implicit
> > function of time. Forth provides local and global variables; locals
> > seem to make a language less concatenative, while globals don't hinder
> > it so much. (Naturally, globals have other problems.)
>
> Global variables can be treated as functions that read/write some  
> state that gets passed through the program thanks to the monoidal  
> nature of things. Local variables cannot; their scopes are local and  
> hence you can't factor out code that references a local variable. The  
> only way of explaining locals is in terms of substitution.
>
> I'm not sure if you think my explanation above rules out locals.

Well... In a Forth without local variables, you can easily "roll your
own" with globals A and B by putting code like this into a wrapper
secondary:-

A @ >R B @ >R

some work

R> B ! R> A !

A and B are globals that have been given a local scope. I don't known
if this would meet your criteria (and yes, I know why it's poor style
- this only goes to whether it can be done).

[William Tanksley, Jr]

John Nowak <john@...> wrote:
> I'm not sure if you think my explanation above rules out locals.

No, you're right.

> If
> not, perhaps it would be beneficial to include "factorability" as part
> of the definition of concatenative languages, e.g. 'f g h == f i where
> i == g h'. I was hoping to get away without having to explicitly
> mention this (and hence doubling the length of the definition).

No, it should be one of the consequences of the definition, not part
of it. Factorability is a consequence of having the syntax and
semantics both being associative in the same way.

>> I'm also thinking about expanding the point about monoids a bit. We
>> have a little to be said on that issue that can't be said on the page
>> about monoids.

> You're right. My only problem is trying to find something to cite in
> the logs. I'll come up with something most likely...

Good luck. Manfred's writings on "The Mathematics of Joy" seems like
the only choice, at this point.

Oh, you might want to cite Kerby's paper somewhere in there. Want me to do that?

> - John

-Wm

[John Nowak]

On Jan 5, 2009, at 12:56 AM, William Tanksley, Jr wrote:

> Oh, you might want to cite Kerby's paper somewhere in there. Want me  
> to do that?

That would be great. Go right ahead!

- John