Re: Local variables controversial?


John Passaniti wrote:
> bobjaffray@xxxxxxxx wrote:
> >>"Normal Forth" is to have direct and explicit control over the stack.
> >
> > Yes, you understand me right that normal Forth
> > has direct and explicit control over the stack.
> > That is what I am saying NSI should be as close
> > to as possible.
>
> This doesn't make sense. NSI is neither direct or explicit control over
> the stack-- it is in fact the direct 180-degree opposite. The
> programmer using NSI does not explicitly manipulate the stack and does
> not have direct control. That role is taken over by the logic of NSI.

With locals there is no control explicitly, directly, or
indirectly. With NSI there is indirect control, because
the stack operations are immediately visible, and if
unsatisfactory the stack order can be changed immediately
in the declaration, etc. It is as close to normal Forth
as can take place with naming the stack items.

> Explain how NSI can ever be "as close to possible" as direct and
> explicit control on the stack when the function of NSI is to take that
> responsibility over from the programmer.

The function is _not_ to take over responsibility from
the programmer but provide self-documentation, and at
the same time a tool.

> > And since NSI produces code with direct control
> > over the stack, it is as close to it as possible.

> This is complete and total nonsense. By this logic, a C compiler gives
> "direct control" over the stack because it also juggles items between
> the stack and registers.

There is absolutely no comparison. The C compiler does
not create normal Forth stack operations.

But then, I suppose, an optimizing Forth native
code compiler also does not create normal Forth
stack operations.

You simply do not want self-documenting names
in the Forth source. To you the beauty of Forth is
that the source is not self-documenting and has
unnamed parameters.

> It's also nonsense because you as the programmer don't have control over
> how NSI chooses to juggle items on the stack. That's part of some
> algorithm hidden away in the compiler. And just like the C compiler,
> the only way you're going to know how it chooses to juggle data is:
>
> 1. Study the output of the compiler.
> 2. Study the compiler itself.
>
> Wow, that's productivity.

I think this is a silly objection, because I see
a close correspondence between the named stack items
in the code and the stack operations, and if not it
becomes immediately clear.

> You're completely missing the important part here which is the role of
> the programmer. I wrote that "normal Forth" is the *programmer* having
> *both* direct and explicit control over the stack. NSI removes the role
> of the programmer in efficiently designing argument order for words and
> for the human insights that occur when factoring.

I deny it does, especially in the way that the implementation
of locals does.

>Seeing how the pieces
> fit together best is a fundamental activity in Forth.

I agree.

> NSI prevents that kind of factoring insight,

I disagree.

> unless you expect the
> programmer to tediously decompile every word (which is even more
> challenging on native code Forths) and study what NSI did.

I completely and totally disagree that it would
be tedious, but rather practically automatic.
And I believe that the use of NSI would enhance
productivity, rather than the opposite.
And it would especially enhance maintenance of
old programming.

>And even if
> you do expect the programmer to waste their time studying NSI-generated
> stack code, the best NSI can do is optimize on the word level. NSI
> provides the programmer no help in coming up with insights on how to factor.

I think that is untrue in view of the fact that the
stack operations become immediately visible, in contrast
to use of traditional locals.

> NSI is a solution to a non-problem that creates new problems. And
> probably the worst part about it is your intent. I assume your ultimate
> attempt here is to reduce the "cost of entry" to Forth and make it
> easier for new Forth programmers to take up the language.

I have stated that it is to make source more self-documenting.

> But fear of
> stack juggling isn't why programmers aren't using Forth.

The use of NSI makes the stack quite visible, rather
than the opposite, and in contrast to the traditional
use of locals.

> They aren't
> using Forth because Forth lacks both the rich libraries and idiomatic
> patterns that typically develop from a vibrant user community.

That is probably true.

> I've shown Forth to dozens of programmers of varying capabilities over
> the years. None of them had a problem with stack juggling once they
> learned some kind of stack diagram notation to keep track of things.
> They might not always produce the most efficient code, but getting to
> items on the stack was never a problem.

It isn't with NSI either, except you are right that NSI
is a tool that creates stack operations and makes the
effect of the stack order apparent more easilty and
quickly than the trial and error method.

> What turns many off from Forth was that whenever they wanted to do some
> common thing (save data in a hash, match against a regular expression,
> write data to a socket, calculate the number of days between two dates,
> etc.), they either had to write it from scratch (which is more effort
> than most care about when initially learning a language), or they had to
> tediously search for Forth code, examine it to make sure it would work
> with their version of Forth and that the various dependencies were met,
> and then test it.

That is partly a standards problem, and partly the
problem that the Forth community consists mainly of
individualists, so there is no large defacto body of common
Forth words.

> When you compare against other programming language communities, you see
> something quite different. Not only do most have rich libraries that
> capture past experience, but they also have standards and tools to
> support those libraries. They have documentation standards. They have
> tools to download libraries and automatically figure out what
> dependencies are needed. They have automated testing frameworks that
> give the programmer confidence that the library works as advertised.

Yes. Forth is _very_ backward in that respect! Here we have
a superior language, but a big lack in progress with the
things that you mention.

> Forth has none of this, which it should but too many people are
> endlessly worrying about reimplementing yet another Forth and others
> (like you) are trying to improve Forth with questionable training wheels
> and other assists that don't address the real reasons why Forth is a
> minority language.

Good translation of all those other libraries into relatively good
Forth
would go a long way to helping provide the body of libraries, etc.

> Forth has the potential to be the premiere meta-language for
> programmers-- a tool where someone who wants direct and explicit control
> over everything is free to code as close to the metal they want-- and a
> tool where if they just want to crank out code to solve a problem that
> rich libraries (and the communities to support them) exist if they
> choose to use them.

If they existed. PagCal claims to be working off the Forth
data stack, and working toward being able to take C source
and put it into Forth. By working on the data stack
rather than elsewhere as locals, this has the potential
to conversion into good Forth.

My timing studies indicated to me that sometimes
working off a stack frame on the data stack gives
a superior result to use of the return stack when
the stack depth is very deep.

> Or put another way, I can guarantee that the number of people who would
> come to Forth if it had rich library support would be far greater than
> the number who would come to Forth if NSI was a reality and not just
> arm-waving statements from you.

I agree entirely on that.

> I started in these threads by saying that having actual working NSI code
> wasn't important to me. That I could evaluate the idea by having
> discussions on how it would work, what it would look like, what the
> costs were, and so on. Well, we've done that. We're done with that.
> Now it's a matter of actually doing and not just saying.

Probably so.

Bob Jaffray

.

Relevant Pages

  • Re: Local variables controversial?
    ... The programmer using NSI does not explicitly manipulate the stack and does not have direct control. ... Explain how NSI can ever be "as close to possible" as direct and explicit control on the stack when the function of NSI is to take that responsibility over from the programmer. ...
    (comp.lang.forth)
  • Re: Local variables controversial?
    ... With NSI there is indirect control, because the stack operations are immediately visible, and if unsatisfactory the stack order can be changed immediately in the declaration, etc. ... So with NSI on a native code Forth, the programmer not only has to decode machine language, but they have to work backwards to what Forth code would have created that machine language. ...
    (comp.lang.forth)
  • Re: Named stack items
    ... >> Thanks for anticipating and getting some timing. ... The point of NSI appears to be to free the ... >programmer of stack manipulation code. ... as a tool for programmers, ...
    (comp.lang.forth)
  • Re: Local variables controversial?
    ... Identify NSI in the source within ) or the like. ... > They will look like a stack diagram. ... Surely creating the pointer and offset would add overhead to the ...
    (comp.lang.forth)
  • Re: [OT] PostLisp, a language experiment
    ... >>latter method in Lisp, and C and many other languages so that the code ... >>the complexity and number of stack items for each definition. ... I do the same thing with my assembly language code, my Java code, my C++ ... >>useless to any experienced Lisp programmer. ...
    (comp.lang.lisp)