Re: modules, wordlists and the FSL

On Sep 26, 4:29 pm, "Elizabeth D. Rather" <erat...@xxxxxxxxx> wrote:
On 9/26/11 9:26 AM, Krishna Myneni wrote:



On Sep 25, 7:41 pm, "Elizabeth D. Rather"<erat...@xxxxxxxxx>  wrote:
On 9/25/11 12:54 PM, Krishna Myneni wrote:
...
One thing missing so far is real-world experience with large
applications using a multitude of modules. Neither the MPE nor Forth
Inc. people have weighed in on their preferred approach. Stephen Pelc
had indicated previously that some of their applications involve
thousands of files. I'd be interested to hear what type of modular
programming mechanism they employ, to provide data and code isolation,
in such applications. Also interested to hear from Elizabeth on their
experience with modular programming in Forth.

SwiftForth uses "packages", described in detail in the SwiftForth manual
Section 5.5.3.  We have occasionally used them in applications, though
most of the applications I'm personally familiar with are embedded, and
we have very few scoping issues in those.  The most complex embedded
systems usually use multiple processors for major subsystems, so scoping
is much less of an issue.
...

Thanks, Elizabeth. Can you comment on how packages in SwiftForth
differ from the module schemes proposed here?

To be honest, I have never looked at the implementation in SwiftForth,
nor (in fact) used it. I'm happy to reproduce the discussion from the
manual that I referenced above:
--------

5.5.3 Packages

Encapsulation is the process of containing a set of entities such that
the members are only visible thru a user-defined window. Object-oriented
programming is one kind of encapsulation. Another is when a word or
routine requires supporting words for its definition, but which have no
interest to the outside world.

Packages are a technique for encapsulating groups of words. This is
useful when you are writing special-purpose code that includes a number
of support words plus a specific API. The words that constitute the API
need to be public (globally available), whereas the support words are
best hidden (private) in order to keep dictionary searches short and
avoid name collisions. Packages in SwiftForth are implemented using
wordlists.

The simplest way to show how packages work is with an example.

        PACKAGE MYAPPLICATION

PACKAGE defines a named wordlist, and places a set of marker values
(referred to as tag in the glossary below) on the data stack. These
marker values will be used by the words PRIVATE and PUBLIC to specify
the scope of access for groups of words in the package, and must remain
on the stack throughout compilation of the package.

Initially words defined in a package are PRIVATE. This means that the
system variable CURRENT, which indicates the wordlist into which to
place new definitions, is set to the newly created wordlist MYAPPLICATION..

Now we define a few private words. These words are the building blocks
for the application, but are considered not to be generally useful or
interesting. They are available for use while the package is being
compiled, and are available at any time by explicit wordlist manipulation..

        : WORD1 ( -- ) ... ;
        : WORD2 ( -- ) ... ;
        : WORD3 ( -- ) ... ;

PUBLIC words are the words that are available to the user as the API, or
to make the package accessible from other code. These words are placed
into whatever wordlist was CURRENT when the package was opened. PUBLIC
words may reference any words in the PRIVATE section, as well as any
words normally available in the current search order.

        PUBLIC
        : WORD4 ( -- )   WORD1 WORD2 DUP + ;
        : WOWORD5 ( -- )   WORD1 WORD3 OVER SWAP ;

We can switch back to PRIVATE words anytime.

        PRIVATE
        : WORD6 ( -- ) WORD1 WORD5 DUP + OVER ;
        : WORD7 ( -- ) WORD1 WORD4 WORD6 SWAP ROT DROP ;

We can switch between PUBLIC and PRIVATE as many times as we wish. When
we are finished, we close the package with the command:

        END-PACKAGE

With the package closed, only the PUBLIC words are still visible.
If you need to add words to a previously-constructed package, you may
re-open it by re-asserting its defining phrase:

        PACKAGE MYAPPLICATION

The word PACKAGE will create a new package only if it doesn t already
exist; so usingPACKAGE with an already-created package name re-opens it.
After re-opening, the normal PUBLIC, PRIVATE, and END-PACKAGE
definitions apply.

Glossary

PACKAGE <name> ( tag )
If the package name has been previously defined, open it and return its
tag. Otherwise, create it and return a tag.

PRIVATE ( tag tag )
Mark subsequent definitions invisible outside the package. This is the
default condition following the use of PACKAGE.

PUBLIC ( tag tag )
Mark subsequent definitions available outside the package.

END-PACKAGE ( tag )
Close the package.
-------------

Chuck once said that making a problem go away is way better than
devising code to solve it.  This is a pretty light-weight implementation
necessitated by some of the complexities of operating in the Windows
environment.  As Andrew observed, we avoid name collisions in team
programming by addressing them in integration.  I've never encountered a
need for 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 90045http://www.forth.com

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

Thanks very much for that detailed description. It shows me that we
are converging towards a very similar solution, and gives me
confidence we haven't overlooked a much simpler solution. And thanks
for Chuck's quote also. I'm in agreement with it, in general. However,
very much like you said about using packages to deal with the
complexities of operating in the Windows environment, my own need for
a modular programming interface arises from having to use Forth
interfaces to external library/driver code. In order to write
comprehensible code for such external interfaces, it is often
necessary to define a large set of support words which would otherwise
clog up the compilation wordlist. For example, there are numerous
constants which simply do not need to be in the Forth wordlist.

Krishna
.

Relevant Pages

  • Re: Stronghelp - can I change location set by Packman?
    ... piles of applications causes lots of random file reads, ... third party installers such as, say, a package manager, but it all got ... applications *do* install things into Choices. ... I have nothing against an app in Choices - it's ...
    (comp.sys.acorn.apps)
  • Re: modules, wordlists and the FSL
    ... applications using a multitude of modules. ... The words that constitute the API need to be public, whereas the support words are best hidden (private) in order to keep dictionary searches short and avoid name collisions. ... PACKAGE defines a named wordlist, and places a set of marker values (referred to as tag in the glossary below) on the data stack. ...
    (comp.lang.forth)
  • Re: up2date showing wrong updates
    ... Nonetheless I like some applications from the alternative repositories, ... Package: * ... Explanation: audacity ...
    (Fedora)
  • Re: Stronghelp - can I change location set by Packman?
    ... piles of applications causes lots of random file reads, ... I'd also like the package manager to give you a nice graphical way to see ... I'm a bit out of my depth here, because I don't know how PackMan ...
    (comp.sys.acorn.apps)
  • Re: Those clever people in Redmond.
    ... Drag the application out of "Applications", ... Right click on the application icon, choose "Show Package ... libraries and whatever needed for that application. ... Frameworks (folder) ...
    (uk.misc)