Re: 'C' Expression Parsing in Forth?

Jeff Fox wrote: 
John might find it funny to be accused of not making
rational decisions about Forth because of an emotional
attachment to it.  I think it's funny because for years
John has said that I can't make rational decisions about
Forth because I love it and have an emotional attachment
to it and I have saidthat he can't make rational decisions
about Forth because he has a different kind of emotional
attachement to Forth. ;-)

I can't remember ever making that argument about you, Jeff. My statements about your irrationality have nothing to do with your love for Forth. Your irrationality comes more from an assortment of character flaws, a deep persecution complex, and your constant need to divide the world into a them-verses-us conflict.

But in this case John and I seem to agree that we
both understand Forth well enough to understand that
the logic behind Forth starts with the idea that
Forth is factoring facilitated by a parameter stack
for unnamed items.  Everyone says, throw that and
you are throwing out Forth and doing something
totally different.

Not exactly. I don't agree that "Forth is factoring." Statements like that are good if you want to express an idea in vague and useless koans, but as an engineer, they don't do much for me. And I bet they certainly won't do much for Bob Jaffrey or PagCal. I've worked with enough different languages and methodologies over the years to know that *all* worthwhile programming is factoring, and that is completely independent of language.

What I do see in Forth is a set of facilities that allow and encourage factoring to occur at a lower level than most other languages. But I don't believe that makes Forth superior in terms of factoring. Sometimes the higher-level factoring that can be done in other languages leads to solutions that are intensely satisfying and elegant.

A good example of this comes from the interest, research, and tools used to "refactor" code. While the Forth community talks a lot about factoring, it is usually not much more than general and often vague statements that apply specifically to Forth. The refactoring community on the other hand has studied higher-level factoring to the point where the transformations have been cataloged, have specific names, can often be applied independent of language, and are discussed pragmatically not only in terms of benefit, but also cost.

In other words, there is a much larger and more sophisticated world out there concerned with factoring. I see Forth filling one end of the factoring spectrum, and the work and research from the refactoring community filling the other. Any modern programmer who wants to remain relevant needs to understand the complete spectrum of factoring, not just low-level factoring in Forth, and not just the higher-level factorings the refactoring community has come up with.

But back to Forth, I do agree that the kind of factoring that happens in Forth is greatly facilitated by unnamed items on a stack. And there is no great mystery there-- a fundamental and distinguishing feature that defines Forth is a programmer-visible stack. If you don't have that, you don't have Forth.

Named stack items and automatically generated code from C-style expressions serve to do the exact opposite; they insulate the programmer from the stack. And worse, in both Bob's and PagCal's descriptions they don't even do that completely enough. There is still a jarring transition between the programmer having to be aware of and responsible for the stack, and abstraction to insulate the programmer from the stack.

He was saying that he thinks that you haven't given the
idea of a stack, of Forth, a fair evaluation and that you
can't give it a fair evaluation until you understand it.
He was saying that you are premature in throwing out
the Forth from Forth to make it more like C.

Mostly. Whenever these discussions come up, you tediously lump everything that isn't Forth as being "like C." Maybe it's because I work with some many languages, but I can think of a variety of abstractions that programming languages use to hide parameter passing that aren't anything like the semantics of C.

In other words, Bob's idea to add named stack items doesn't make Forth "like C" unless your threshold for "like C" is absurdly low. I don't consider named stack items to be "like C" at all, especially considering that syntactically, he doesn't try to use infix expressions.

It's PagCal's ideas that are more "like C," but ironically he seems to have come up with a hybrid that ignores the unique benefits of both languages and blends them into a mess that I can't imagine would be compelling to any programmer. He cites the ability to incorporate the wealth of C code in the world-- after tediously wrapping it in c-expressions, c-statements, and apparently other constructs. Not answered is what benefit the programmer gains by taking perfectly good C code, wrapping and decorating it with some Forth syntax, and then having to deal with the impedance mismatch between the mental models the languages provide. It would be far simpler to recognize the strengths of both languages and provide a sensible call interface between the two.

And it is well worth the admission price when you
tell John that he doesn't understand your idea
because he is a Forth purist. (It's an old joke
don't worry about it.)  John is very open to
the idea of experimentation with new ideas in
programming and to mixing ideas to get something
new.  I don't think he is too locked in to Forth
purism.  I might be.  But so far I am with John
on this one.

I understand both Bob's and PagCal's idea. I reject them not because I'm a Forth purist, but because when I objectively evaluate them, I can't see the benefit in either. I might warm to Bob's named stack items if he could actually define the semantics clearly and fully, but he doesn't do that. And that's why I reject the idea. I've brought up real problems and concerns with the idea that Bob tosses away with vague statements about how the compiler automagically figures out how to address items on the stack. Sorry, not good enough.

PagCal's idea I reject because C and Forth are perfectly good languages by themselves, but make little sense blended together in the way he proposes. And I reject it on philosophical grounds: He hasn't yet figured out how language shapes thought; how the idioms and abstractions provided by languages don't all reduce down to the same thing at the conceptual level. And that I gather is because he either hasn't yet been exposed to radically different models for computation, or he has but is considering them only superficially.
.

Relevant Pages

  • Re: C-programmer needs Forth advice
    ... >> invent when you want to use the result more than once. ... > manage a copy on the stack. ... > effort for both the C programmer and the Forth programmer in this case. ... > lets you have a finer-grained factoring. ...
    (comp.lang.forth)
  • Re: C Expression Parsing in Forth?
    ... > factoring to occur at a lower level than most other languages. ... > Forth is greatly facilitated by unnamed items on a stack. ... its visibility to the programmer during development. ... > Named stack items and automatically generated code from C-style ...
    (comp.lang.forth)
  • Re: Local variables controversial?
    ... > amounts to pushing some items on a stack and offsetting a stack ... > As for your other comments about factoring in other languages, ... While Forth allows finer-grained factoring, ... inline int add ...
    (comp.lang.forth)
  • Re: Language X, not Forth ?
    ... What do other languages have, ... programmer must keep track of data on stack ... who claim FORTH is easily readable are fanatical FORTH programmers who ... compile to have performance. ...
    (comp.lang.forth)
  • Re: The Promise of Forth
    ... All non-trivial programming is thinking. ... But there are lots of other interactive languages now. ... Factoring is good for people who think. ... There's a time-honored tradition that part of managers' compensation ...
    (comp.lang.forth)
Loading