Re: Words on the heap

Michael Ben-Yosef wrote:
On Dec 6, 3:35 pm, m...@xxxxxx (Marcel Hendrix) wrote:
How does one standardize features that nobody uses? The standard is
not for experimental proposals. (We had FORML for that in the golden
days.) Nowadays you'll have to write a really impressive application
first, and port that to a number of Forth systems. When people start
using your stuff (because it is useful), and when you strategically
excluded a few important systems on the ports list (if you succeeded
in porting it to all, it clearly needs no standardizing :-), everything
will proceed quickly, say within a few decades. And then we'll all be
using your ideas, using a watered down syntax and with ugly naming
pallatable to nobody :-)

-marcel

Point well taken. In the context of what you've said, let me just
emphasise that this is not my idea at all. The ability to delete a
function from an image in order to reuse the space is something that
is available in many modern and not so modern languages, Lisp being
the example most familiar to me. Now, I obviously don't want to come
in here as another whiny fool saying, "Why does Forth not have X?".
(In fact, I probably did come across that way, and I apologize.) I
just wanted to gauge whether any significant number of people in the
Forth community have perceived this as a problem, and, if so, what
they or their implementations have done to remedy it.

Forth programs tend to be significantly smaller than equivalent functionality coded in other languages. The major reason is that it is optimized to encourage great modularity (many words only a few commands long), so there is much higher code density. As a result, even on very memory-constrained platforms there is far less incentive to re-use dictionary space. There's a general feeling that the added complexity required to support a dictionary "heap" would not justify the benefit. In fact, dynamic allocation even for data space is a relatively recent (Forth94) addition. Although is is very useful in some situations, it is not widely used even now in many programs.

In the early days (70's and 80's) the word FORGET was used to discard the most recent words in the dictionary. On multitasking systems, each task could have a private dictionary linked to the main, shared kernel, and could optionally empty that and recompile new definitions. By the time of the development of Forth94, it was recognized that this model was too simple: for example, FORGETting an interrupt handler could be disastrous. So MARKER was introduced, to make it possible to save and restore features when part of the dictionary was replaced. Even so, the model in which the dictionary is maintained as a linear structure was retained.

On today's PC-type platforms, there is typically such a vast amount of memory available that, with Forth's natural memory conservation, it simply isn't sufficiently attractive to be able to discard portions of the dictionary. And in embedded systems, which do tend to be more memory-constrained, there is rarely the need (and often not the ability) to compile lots of code, so it's not an issue.

Overall, the economics of Forth (as well as programming styles) are sufficiently different from other languages that the thought model of, "I'm used to doing this, how do you do it in Forth" is often inappropriate. Lisp, which you mention, has very significantly different tradeoffs from Forth.

I would counsel you as a Forth newbie to concentrate on learning good Forth style and writing several simple applications in order to become familiar with doing things the "Forth way", which will yield you much better results than trying to make Forth emulate a language with quite different needs and strategies.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================
.

Relevant Pages

  • Re: NAS alternative to my junky Airport Extreme
    ... most European languages, won't it? ... memory moving their contents at once -- of 9 and other sizes. ... Hungarian and German both use umlauts. ... What accents do other languages put on the letter A? ...
    (uk.comp.sys.mac)
  • Re: memory allocation questions (newbie)
    ... I think this means something like "a pointer that is ... prepared to point to a memory location big enough to hold an int." ... I think having multiple exit points is not a good idea. ... experience writing programs in high-level languages. ...
    (comp.lang.c)
  • Re: Which computer language program is best for undergrads?
    ... % with equality constraints ... that relies upon basic features found in many modern languages. ... management which, as I understand it, Matlab does not. ... I'm not sure what you mean by memory management. ...
    (comp.programming)
  • Re: Newbie question about "cons"?
    ... I think this is relevant to the history of Lisp. ... mega-large databases of facts that can't all be "in memory" at once. ... ultimately know that there are locality issues no matter what you do. ... In fact, the choice of lists vs arrays in languages, something near ...
    (comp.lang.lisp)
  • Re: Python from Wise Guys Viewpoint
    ... >>writes a program ought to have a proof that the program is correct in ... It ought to be possible to formalize ... while in languages that don't use arrays as a standard data ... total memory consumption is limited. ...
    (comp.lang.lisp)