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

Don Groves <[email protected]> Tue, 20 Jul 2010 20:18:00 -0700
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
On 16 Jul 2010, at 10:21, William Tanksley, Jr wrote:

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

OK, guess I may need some hand-holding here:

Isn't call-by-reference essentially equivalent to lazy evaluation?
If the called function doesn't need a certain parameter during a
particular call, that parameter will not be evaluated. So, parameters
(data) are only evaluated when needed, i.e., they are lazy.

In a call-by-value environment, It seems to me that incapsulating
all data in functions yields the same effect as call-by-reference. If
a parameter is not needed, its evaluating function will not be called.

If I'm on the wrong track with this, please enlighten me!

don


> 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
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>