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

--- In [email protected], "William Tanksley, Jr" <wtanksleyjr@...> wrote:
>
> pml060912 <pml540114@...> wrote:
> > "William Tanksley, Jr" <wtanksleyjr@> wrote:
> >> Laziness is one of the things that can't easily be imported to a
> >> concatenative language.
> 
> > Well, that depends on what you call lazy.
> 
> Actually, I don't think there's ambiguity in this context. A lazy
> language is one in which the semantics for the parameters to a
> function are performed only if the parameter is actually USED. This
> means that you can have a function with a parameter that cannot be
> evaluated completely, and the program will run if the parameter is not
> actually used in the function.

The indirection mechanism achieves that effect very simply, so it depends whether you are willing to call it lazy even though it is only delivering lazy semantics and isn't using lazy syntax to get there. But, since the mechanism is simple, it wouldn't be hard to set up a concatenative language that had syntactic sugar for that as well - making it both syntactically and semantically lazy. That's why I thought it was relevant.

> 
> > For Furphy,
> 
> http://users.beagle.com.au/peterl/furphy.html (I think -- is that your
> latest work?).

Well, the latest that's firmed up. I have been thinking about an operator that would "glue" two frozen words together to get a new (frozen) word, and which sorts of garbage collection would be the best choices.

> 
> > I worked out an indirection mechanism that allows you
> > to produce the effect of laziness even when everything
> > actually encountered is handled eagerly: the pair
> > FREEZE and THAW,
> 
> That's not a lazy language, I think. Unfortunately, I'm unqualified to
> judge, since I'm unable to read your examples; I have no idea where
> the words TRUE_OPTION and FALSE_OPTION are defined; they just appear
> there. (I vaguely recall having figured out how to read Furphy, but
> I've forgotten since.)

That "appearing" IS the definition, the first time they appear. With that kind of reverse polish naming, an unrecognised token closes the current definition and is assigned as its name. Here are the definitions from the example code again:-

FREEZE TRUE_STUFF TRUE_OPTION

FREEZE FALSE_STUFF FALSE_OPTION

(I didn't define TRUE_STUFF and FALSE_STUFF.)

> 
> The distinction is that in this language you have to explicitly mark
> the non-evaluated parts; a truly lazy language needs no such marker.

Since there is already some laziness, with nothing being done apart from immediate words until the source has been compiled, it would be easy enough to invert that so that everything is frozen unless deliberately invoked. You would just drop the "and go" feature from the compile and go compiler and also change new word definitions to default to frozen, leaving invocation up to suitable immediate words. On the whole I prefer this way around since it is a closer and more readable match to what is usually needed, but it does show that there isn't really a big problem implementing full laziness. P.M.Lawrence.