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