Forth - How many know about and use it?

[SiliconWizard]

I was also replying to the original question. Namely, why I personally do not (in my case) use Forth or wouldn't consider using it. I was not trying to discourage anyone from doing so. Now if some of my points are not exact, I'm absolutely willing to reconsider them. Let's see:

no data structures?!?!?! The bloody FORTH dictionary in the compiler is a linked list?!?!?! Also ALLOCATE/FREE implementations are usually heap based

You're conflating internal use of data structures with making them easily available to people USING the language.
I can write an assembler in Java, but that doesn't make the assembler "object oriented."   And then I can write object-oriented code in the assembly language, but it wasn't HELPFUL to me doing so.

Try implementing one of the "Programming 101" examples of structs/records/whatever using forth.  Here's one:   https://www.pascal-programming.info/lesson11.php

My point exactly. Internal data structures were a bizarre point for showing Forth has data structures. Those are not directly available to the programmer for structuring your data. Dictionaries allow you to define "words" (which are an idiomatic way of calling subroutines/functions/procedures). What else can you do with them?

I've read a few things on implementing data structures in Forth, and as far as I've seen, it's all dynamic. One may argue that the same approach holds for a handful of other non-statically-typed languages. The drawbacks and benefits can be debated to no end, but to me, it looks like a good way of making code less readable, almost unverifiable statically, and easy to shoot yourself in the foot with. Of course it's partly opinion here, although this has been discussed and studied for quite a long time, and I'm sure you can find proponents of purely dynamic typing even for safety-critical applications. And this thread is probably not the right place for debating about static vs. dynamic typing in general, I'm just exposing points why *I* personally wouldn't consider Forth (other than out of historical interest.)

As to my other point - saying that all your code lives in a "flat" world - there may be partly a lack of deep knowledge of Forth from my side. You can have several dictionaries, as I've been told here, but can you use several dictionaries simultaneously in a given program? Can you call "words" from another dictionary within words from a given dictionary? If so, please give a short example of how to do this, I'm curious (really!) If not, then that was my point. You could argue that the same holds for other non-modular languages such as C, which only has one namespace (if you omit oddities such as separate namespaces for structs and unions). But even in such languages, you have the ability to make some functions(/procedures/....) 'static' or 'private', meaning you can isolate them relatively. Is there a similar feature in Forth? This is not meant as a contest at all, or a language flame war. Just questions.

Now for both points above, if anyone knowledgeable in Forth can provide short examples that would show that things are much "better" than I make them look, I'll be genuinely happy to have a look.

[brucehoult]

Not FORTH, but use of multiple dictionaries is common in PostScript.

There is a stack of current dictionaries which names are automatically looked up in. "load" and "store" operators search the dictionary stack for the name. "def" creates a new name in the topmost dictionary. You can also use "put" and "get" to load and store things in explicitly named dictionaries i.e. a reference to them is taken from the (normal, not dictionary) stack.

Dictionaries are used for local variables in functions, or even in a loop. Many functions start with something like "10 dict begin", where the 10 is the initial size of the dictionary hash table. Dictionaries are used for Object-Oriented programming. For example a font is a dictionary. The name "a" in the font dictionary is a function that draws the letter "a".

[gnuarm]

I was also replying to the original question. Namely, why I personally do not (in my case) use Forth or wouldn't consider using it. I was not trying to discourage anyone from doing so. Now if some of my points are not exact, I'm absolutely willing to reconsider them. Let's see:

no data structures?!?!?! The bloody FORTH dictionary in the compiler is a linked list?!?!?! Also ALLOCATE/FREE implementations are usually heap based

You're conflating internal use of data structures with making them easily available to people USING the language.
I can write an assembler in Java, but that doesn't make the assembler "object oriented."   And then I can write object-oriented code in the assembly language, but it wasn't HELPFUL to me doing so.

Try implementing one of the "Programming 101" examples of structs/records/whatever using forth.  Here's one:   https://www.pascal-programming.info/lesson11.php

My point exactly. Internal data structures were a bizarre point for showing Forth has data structures. Those are not directly available to the programmer for structuring your data. Dictionaries allow you to define "words" (which are an idiomatic way of calling subroutines/functions/procedures). What else can you do with them?

Wow!  I'm no expert, but I'm familiar with Forth enough to know there is no limit to what you can do with data structures in Forth.  I think the issue is you are accustomed to limiting yourself to whatever the language directly provides.  Forth provides the base for creating structures like other languages.  The big difference is this is all extensible in Forth.   +FIELD is used to create arbitrary sized fields.

From the language standard document.

Code: [Select]

10.6.2.0135
+FIELD
“plus-field”
FACILITY EXT
( n1 n2 “⟨spaces⟩name” – – n3 )
Skip leading space delimiters. Parse name delimited by a space. Create a definition for
name with the execution semantics defined below. Return n3 = n1 + n2 where n1 is the
offset in the data structure before +FIELD executes, and n2 is the size of the data to be
added to the data structure. n1 and n2 are in address units.
name Execution: ( addr1 – – addr2 )
Add n1 to addr1 giving addr2.
See: 10.6.2.0763 BEGIN-STRUCTURE, 10.6.2.1336 END-STRUCTURE,
10.6.2.0893 CFIELD:, 10.6.2.1518 FIELD:, 12.6.2.1517 FFIELD:,
12.6.2.2206.40 SFFIELD:, 12.6.2.1207.40 DFFIELD:, A.10.6.2.0135 +FIELD.
Here is info on some field words.

Code: [Select]

A.10.6.2.1518
FIELD:
Create an aligned single-cell field in a data structure.
The various xFIELD: words provide for different alignment and size allocation.
The xFIELD: words could be defined as:
: FIELD: ( n1 "name" -- n2 ; addr1 -- addr2 ) ALIGNED 1 CELLS +FIELD ;
: CFIELD: ( n1 "name" -- n2 ; addr1 -- addr2 ) 1 CHARS +FIELD ;
: FFIELD: ( n1 "name" -- n2 ; addr1 -- addr2 ) FALIGNED 1 FLOATS +FIELD ;
: SFFIELD: ( n1 "name" -- n2 ; addr1 -- addr2 ) SFALIGNED 1 SFLOATS +FIELD ;
: DFFIELD: ( n1 "name" -- n2 ; addr1 -- addr2 ) DFALIGNED 1 DFLOATS +FIELD ;
I'm not going to go into the discussion of static vs. dynamic variables.  I have no use for splitting such hairs. 

The standard committee does try to keep Forth as a one size fits all language while some users prefer a split approach, one language for embedded work and another language for desktop type applications.  What I use Forth for does not require optimal efficiency or memory usage or anything else other than convenience to the programmer, me.  So it is fine as is.  I am very happy with the capabilities it has and the tremendous effectiveness I have in using it.