Re: [stack] Re: Barebone implementation of concatenative language in c or c++
- Don Groves <dgroves@...> wrote:
>>>> "William Tanksley, Jr" <wtanksleyjr@> wrote:Data isn't supposed to be evaluated, of course; I think you meant
>>>>> 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?
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.
- On 2010.07.25, at 10:45 AM, William Tanksley, Jr wrote:
> John Nowak <john@...> wrote:It's just parameterized modules a la Ada or ML. The values of the parameters can be resolved statically; module instantiation essentially happens before the program is run.
>> You'd still need some way to parameterize functions
>> by other functions even if functions aren't available as
>> data at runtime. OBJ is an excellent example of how
>> to do parameterized programming without first-class
> I'm curious... How is OBJ an excellent example of that? It sounds like
> a useful property!
This should help: