Re: Standard Forth versus Python: a case study

2006-10-16 Thread Elizabeth D Rather
[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?

2006-02-12 Thread Elizabeth D Rather
"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 ?

2010-08-16 Thread Elizabeth D Rather

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 ?

2010-08-17 Thread Elizabeth D Rather

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 ?

2010-08-18 Thread Elizabeth D Rather

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 ?

2010-08-18 Thread Elizabeth D Rather

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 ?

2010-08-21 Thread Elizabeth D Rather

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