you are contradicting an earlier poster from forth who admitted the
part on dicts.
Then they are wrong.
You asked if Forth "borrowed" lists from Lisp. It did not. In Lisp,
lists are constructed with pair of pointers called a "cons cell".
That is the most primitive component that makes up a list. Forth has
no such thing; in Forth, the dictionary (which is traditionally, but
not necessarily a list) is a data structure that links to the previous
word with a pointer. This is in fact one of the nice things about
Lisp; because all lists are created out of the same primitive cons
cell, you can consistently process any list in the system. In Forth,
any lists (such as the dictionary, if it is a list) are specific to
their purpose and have to be treated individually.
I don't know what you mean by "nested-dictionaries." There is no such
thing in Forth. Dictionaries don't nest. You can create wordlists,
but each wordlist is flat. When most people think of a nested
dictionary, they would think of a structure that would allow any
arbitrary level of nesting, not a string of flat wordlists.
and what can you add to enlighten the readers on the other view ?
How one views OOP depends on the language and implementation. Your
statement about having fewer than "ten or twenty fold" functions is
completely arbitrary and is more a matter of style and skill in
decomposition than an intrinsic quality about objects. The poetic
"clustering of thought" is vague but a I guess could be an informal
notion of the bundling of related state and methods. And referring to
it as "book-keeping" suggests some kind of static relationship between
state and methods, although that is not the case in architectures that
stress dynamic relationships. Many people only know OOP through
static, class-based models (such as in languages like C++). But there
are other models. Objects can also be represented not with classes
but by cloning existing objects and then mutating them as needed.
Objects can also be represented with a functional interface using a
closure around an environment. In such cases, objects may be far more
fluid than in static class-based models, and shift over time into
different roles. In such systems, "book-keeping" isn't static. Or
put another way, the language and implementation drive the flavor that
a particular object has.
The objective is to discuss those cases via specific examples (not
generalities), and talk ABOUT them, not AROUND them.
I'd be happy to discuss specific examples, but your understanding of
Forth is flawed, and until you learn more about Forth, I don't think
it would be helpful.
And actually, I did provide a specific example. You apparently didn't
understand it, so let me be more explicit. Here is a function in
Scheme:
(define (hello name)
(lambda ()
(begin
(display "Hello ")
(display name))))
This defines a function that returns another function. You can think
of this as a constructor for a light-weight object that has one value
("name") and one default method (to print "Hello <name>"). The
function that is returned can be stored, passed around, and otherwise
out-live the invocation of this function. For example:
(define example (hello "John"))
In your stack mindset, the value "John" would disappear after the call
to "hello". But in Scheme, the value lives on, as it is part of the
closure captured at the time the function was created.
A stack mindset would not allow this. And this would eliminate the
vast majority of functional programming from your language's
abilities. Maybe you don't care, or maybe you still don't see the
value in this. In that case, I suggest you learn the language and
then think about what your stack mindset prevents.
Its a very fine wild goose chase project statement.
No, it is a vivid example of what you don't know-- and what you don't
know is what will limit you later.
