Re: [stack] Re: Barebone implementation of concatenative language in c or c++

"William Tanksley, Jr" <[email protected]> Fri, 16 Jul 2010 09:21:20 -0800
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
Don Groves <[email protected]> wrote:
>>>> "William Tanksley, Jr" <wtanksleyjr@> wrote:
>>>>> Laziness is one of the things that can't easily be imported to a
>>>>> concatenative language.
> It seems to me that laziness can be implemented simply by
> encapsulating all data in functions. If a particular function
> is not called, that data is not evaluated. What am I missing?

Data isn't supposed to be evaluated, of course; I think you meant
encapsulating all functions in data rather than the other way around.
And indeed, that does allow you to control when your parameters are
evaluated (thus making them lazy); but it also makes tracking
parameters part of writing and reading your program -- and a lot of
that winds up being done at runtime.

I guess my basic point is that there's a type of laziness, let's call
it automatic laziness, that just can't be done in a concatenative
language. Syntax sugar won't save you from that problem, I think,
since there's too many operations that need to be done.

This doesn't mean I don't like concatenative languages; I just think
there's some research to be done in this area.

You know, it occurs to me that one place to look for a starting point
in that research might be colorforth. Take a look:
http://rainbowforth.sourceforge.net/blocks.html (see block 36,
'factorial', for a programlike block, most of the earlier stuff is the
source code for the language, including a lot of machine code).
Colorforth allows you to write code that's simply neutrally stored, or
markers that help you access that stored code, or immediately executed
code, or code that generates results that go into a definition...
There's a lot of different things to do. The different operations are
distinguished by color codes.

> don

-Wm