Re: Standard Forth versus Python: a case study
[EMAIL PROTECTED] wrote: > John you nailed it. I was a big forth fan in the mid-80s but it was > very clear that you either had to spend a lot of money on proprietary > systems or do it ALL yourself. Not having any money I was pleased to be > able to do it all but today, in the age of instant communication and > collaboration, its not a competitive option in any language. Had forth > kicked off the open source community about a decade earlier than the > UNIX folk (in useful terms) I think we'd be living in a much different > world from a computing perspective. Forth is still cool - but only when > its for something I wanna do all by myself... :) Fortunately, modern Forths have quite a lot more functionality than mid-80's Forths, in terms of application-relevant features, programming aids, more intelligent compilers, OS (e.g. Windows, Unix) compatibility and access, etc. You should really have another look! Cheers, Elizabeth -- ========== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310-491-3356 5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454 Hawthorne, CA 90250 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." == -- http://mail.python.org/mailman/listinfo/python-list
Re: Is Forth for real?
"Cameron Laird" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In article <[EMAIL PROTECTED]>, > Steven D'Aprano <[EMAIL PROTECTED]> wrote: > . > . > . >>on the web for each language. By comparison, even Forth gives 13 million >>plus hits, and who uses Forth? > . > . > . > The programmers of, among other things, the FedEx bar-code reader, > the Sun boot loader, and parts of the Space Shuttle. We have several thousand customers, although we don't hear from them enough to know how active they are. Most of them are doing embedded systems (such as the FedEx package tracker), although there are also quite a few doing Windows apps. A lot of our embedded work is for aerospace and government customers, plus a number in the private sector. All the DirecTV uplink antennas are controlled by one of our systems made by VertexRSI, http://www.tripointglobal.com/vertexrsi.html. Another really neat customer is Sunrise Systems, http://www.sunrisesystems.com/index.htm. They make moving displays, and are working on one for one of the rebuilt World Trade Center bldgs, one to be installed in Switzerland next month, and something for Disney World. Open Firmware has already been mentioned, and I should add that IBM's high-end servers also use it. I teach Forth courses there once or twice a year, and have trained a couple hundred engineers in IBM alone. You can get more info on our web site www.forth.com, including a link to a paper presenting a history of Forth. Cheers, Elizabeth -- == Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310-491-3356 5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454 Hawthorne, CA 90250 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." == -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
On 8/15/10 10:33 PM, Standish P wrote:
...
I don't understand a lot of your post (and it's clear that I'm not
alone). I don't know whether it's a (human) language problem or simply
an issue of your having read too many books and not having enough
practical experience, but at least I can try to address the Forth questions.
If Forth is a general processing language based on stack, is it
possible to convert any and all algorithms to stack based ones and
thus avoid memory leaks since a pop automatically releases memory when
free is an intrinsic part of it.
Forth uses two stacks. The "data stack" is used for passing parameters
between subroutines ("words") and is completely under the control of the
programmer. Words expect parameters on this stack; they remove them,
and leave only explicit results. The "return stack" is used primarily
for return addresses when words are called, although it is also
available for auxiliary uses under guidelines which respect the primary
use for return addresses.
Although implementations vary, in most Forths stacks grow from a fixed
point (one for each stack) into otherwise-unused memory. The space
involved is allocated when the program is launched, and is not managed
as a heap and allocated or deallocated by any complicated mechanism. On
multitasking Forth systems, each task has its own stacks. Where
floating point is implemented (Forth's native arithmetic is
integer-based), there is usually a separate stack for floats, to take
advantage of hardware FP stacks.
- is forth a general purpose language? Yes
- are all algorithms stack based? No
Does Forth uses stack for all algorithms ? Does it use pointers , ie
indirect addressing ? If it can/must use stack then every algorithm
could be made stack based.
Forth uses its data stack for parameter passing and storage of temporary
values. It is also possible to define variables, strings, and arrays in
memory, in which case their addresses may be passed on the data stack.
Forth is architecturally very simple. Memory allocations for variables,
etc., are normally static, although some implementations include
facilities for heaps as needed by applications.
Hope this helps. If you are interested in learning more about Forth,
there are several books available (try Amazon). Get one of the more
recent ones, some of which I wrote.
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."
==
--
http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
On 8/17/10 10:19 AM, Standish P wrote: On Aug 17, 12:32 pm, John Passaniti wrote: ... It is true that the other languages such as F/PS also have borrowed lists from lisp in the name of nested-dictionaries and mathematica calls them nested-tables as its fundamental data structure. No. you are contradicting an earlier poster from forth who admitted the part on dicts. Not at all. A Forth dictionary is a simple linked list, not the complicated kind of nested structures you're referring to. You really seem addicted to very complex structures. They really aren't necessary for general programming. 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." == -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
On 8/18/10 12:09 AM, spinoza wrote: On Aug 18, 1:21 am, Standish P wrote: Garbage collection doesn't use a stack. It uses a "heap", which is in the abstract a collection of memory blocks of different lengths, divided into two lists, generally represented as linked lists: 1. A list of blocks that are free and may be used to store new data 2. A list of blocks that are in use, or haven't been freed (yet) Is this all that a heap is or is there more to it ? I have been looking for simple but complete explanation of heap for a while and not gotten to it. I think I am looking for a stack allocation on the same pattern. In a disk, a file is fragmented in many contiguous blocks and is accessed automatically. Stacks (at least as far as Forth uses them) and heaps are fundamentally different things. ... However, data structures of variable size, or data structures that merely take up a lot of space, don't play nice with others on the stack, so, we place their address on the stack and store them in another place, which was named the heap, probably, as a sort of witticism. In Forth, they go in "data space", which might or might not be in the dictionary, and is almost never in a dynamically managed heap; certainly not on a stack. ... No, they're not. Stack based languages have seen better days and Forth (and the SL/1 language I supported with compilers at Bell-Northern Research) were last in fashion in the 1970s. Processors seldom could multitask, so it wasn't recognized that the stack could be a performance bottleneck, where stack operations cannot be pipelined or executed in parallel. Lol. Forth supported multitasking on every processor it was implemented on in the 70's, with blazing speed compared to competitive techniques. I have never seen stack operations to be a bottleneck. ... Forth had a snowball's chance because it forces ordinary programmers to think in Reverse Polish notation and is for the above reasons hard to pipeline, although of course it can be pipelined. Mostly it had a "snowball's chance" because it was never picked up by the CS gurus who, AFAIK, never really took a serious look at it. 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." == -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
On 8/18/10 2:23 PM, Standish P wrote: On Aug 17, 6:38 pm, John Passaniti wrote: 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. Would you show me a picture, ascii art or whatever for Forth ? I know what lisp lists look like so I dont need that for comparison. Forth must have a convention and a standard or preferred practice for its dicts. However, let me tell you that in postscript the dictionaries can be nested inside other dictionaries and any such hiearchical structure is a nested associative list, which is what linked list, nested dictionaries, nested tables are. You indicated that you have a copy of Forth Application Techniques. Sections 8.1 and 8.2 cover this topic, with some drawings. 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." == -- http://mail.python.org/mailman/listinfo/python-list
Re: How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?
On 8/20/10 7:42 PM, Standish P wrote: ... Admittedly, I am asking a question that would be thought provoking to those who claim to be "experts" but these experts are actually very stingy and mean business people, most certainly worse than Bill Gates, only it did not occur to them his ideas and at the right time. The problem as I see it is that you're asking complex questions in a forum that, at best, supports simple answers. The information you're looking for exists, on the net, free. There are free pdfs of manuals on Forth available with program downloads from FORTH, Inc., MPE, Gforth, and other sources, as well as some inexpensive books. But you have to be willing to make the investment to download and read them, because the answers to your questions are not simple one-liners that you can get from newsgroups, and the folks in newsgroups are not prepared to host computer science seminars -- many of us are working programmers, engineers, and project managers who have limited time to spend here. If you're willing to invest your time enough to investigate some of these sources, and still have questions, we'll be happy to try to help. 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." == -- http://mail.python.org/mailman/listinfo/python-list
