lifetime of variables in Forth language

96 views
Skip to first unread message

Timur

unread,
Aug 6, 2020, 2:50:25 PM8/6/20
to 4tH-compiler
Good day!

 I don't know much about the lifetime of variables in Forth language.

If I define a new variable inside a word (function), will this variable be available from everywhere or within only one function? In other words, are variables global or local?

Does the variable lose its value after the completion of the execution of the word (function)?

In C, I can force a variable remember  its value between calling execution of function where it is defined using the word "static".

What's going on here at Forth ?

Thank You.

Timur


Lloyd R. prentice

unread,
Aug 6, 2020, 5:48:07 PM8/6/20
to 4th-co...@googlegroups.com
Chuck Moore, creator of Forth, strongly advised against variables. His recommendation was to pass all parameters on the stack, use stack diagrams, keep every word just a line or two of code, limit stack depth, and solve just the immediate problem at hand. One could say that it's a very prescient version of functional programming. As you probably know, global variables are generally discouraged in most languages. 

I haven't checked to see if they're still on-line, but Google Jeff Fox + Forth.  Jeff wrote many excellent tutorials/commentaries. Also, check out Dr. CH Ting's work:


Ah, here's a link to Jeff's work:


Best,

Lloyd
--
You received this message because you are subscribed to the Google Groups "4tH-compiler" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 4th-compiler...@googlegroups.com.

Lloyd R. Prentice

unread,
Aug 6, 2020, 6:00:49 PM8/6/20
to 4th-co...@googlegroups.com
Check this out:


Best,

L.

Sent from my iPad

On Aug 6, 2020, at 5:48 PM, Lloyd R. prentice <ll...@writersglen.com> wrote:



John Peters

unread,
Aug 6, 2020, 10:48:45 PM8/6/20
to 4th-co...@googlegroups.com
I believe the variables are usually defined outside of the word that they’re going to be used within oh I think it is possible to do the above using curly braces {   and  }

Thought it might be fun to try and answer this although I might be wrong.

John Alan Peters owner 
Brookline Electric
415-239-5393 TEXT/cell

On Aug 6, 2020, at 6:00 PM, Lloyd R. Prentice <ll...@writersglen.com> wrote:

Check this out:

The Beez

unread,
Aug 7, 2020, 5:25:29 AM8/7/20
to 4tH-compiler


On Thursday, August 6, 2020 at 11:48:07 PM UTC+2, LRP wrote:
Chuck Moore, creator of Forth, strongly advised against variables. His recommendation was to pass all parameters on the stack, use stack diagrams, keep every word just a line or two of code, limit stack depth, and solve just the immediate problem at hand. One could say that it's a very prescient version of functional programming. As you probably know, global variables are generally discouraged in most languages. 

As you know, 4tH has two stages: compilation and execution. _ANY_ variable declaration _WHEREVER_ it's made is picked up by the compiler and results _ALWAYS_ in a _GLOBAL_ variable. In some cases, (like VALUE) initialization is done during execution. You can _LIMIT_ the scope of any symbol in 4tH by using the keyword 'HIDE', but that doesn't mean the variable isn't there anymore. It's just that when you define it again, another global variable now carries its name.

And yes, one should limit the number of variables - "STAMP OUT THE VARIABLES" is one of Forth's dogma's. v3.64's R@, R'@ and R"@ words help you to achieve that easier as you can see in e.g. the GCIRCLE.4TH library member - which uses _NO_ variables at all. As does GBEZIER, DDA. On the other hand if you have routines which lots of variables, like GELLIPSE, sometimes it's better to use a few extra globals - for speed, clarity, etc. But it should be your last resort. 

E.g. GBURST already manages FIVE variables on the stack. The DEFER is IMHO therefore "defensible".  GELLIPSE has a "full house" with FOUR values on  the datastack and THREE on the return stack. Of course, lots of predefined variables may result in a clogged namespace. By enclosing those internal variables with parenthesis and discarding their symbols by HIDE, 4tH tries to prevent this.

I know , it's a bit hard to swallow, but hey: that's Forth. It's not like any other programming language. To really dive into this weird concept, I recommend my https://sourceforge.net/p/forth-4th/wiki/This%20is%20Forth/ 

---8<---
Bonus material

Of course, there have been so many other people saying that concepts like dynamic memory, associative arrays, local variables, regexps, OOP, etc. "make Forth so much easier to use" that these concepts have been incorporated. However, NONE OF IT IS STANDARD (exaggerated - you catch my drift). 

Of course, you can use it. 4tH has something of every single thing mentioned above. IMHO you just burden your language with a lot of stuff that doesn't really improve neither your program nor your programming. I never use associative arrays, locals, regexps or OOP. For regexps I'd rather use CHMATCH - which discards the use of compiling and executing your regexp. I think locals are just a horror - I'd rather use an extra stack (which is faster). OOP just results in bloatware and lasagna code IMHO. Thank you: it was hard enough to get away from spaghetti code forthy years ago ;-)

In short - yes, you can bolt all those "modern" things to 4tH (or Forth), but why don't you just program in C(++) where all this stuff is standard? Or do you want to show off a program in Forth that can be converted to C in a heartbeat - because it's using all the strengths of C and none of Forth?

Why do you think the preprocessor was written in 4tH? I shudder at the thought of converting it to C, because it uses all the strengths of 4tH.

The bottomline of Forth - which you have to internalize immediately: IT DOES NOTHING FOR YOU. Everything is exposed - and you've got to handle it yourself. The is no magic nanny that cleans up after you or checks things for you. You allocated it, now you're stuck with it. You have to make it work for you and you have to clean it up.

4tH is a bit nicer (therefore - the "friendly" Forth compiler), because not everything is exposed, most things are checked (in a very basic way) and some things are handled for you in the background. But there's enough left to give you loads of freedom to mess things up.

Also see: 

Hans Bezemer

Reply all
Reply to author
Forward
0 new messages