Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #24173 > unrolled thread

Namespaces

Back to article view | Back to comp.lang.forth

Contents

  Namespaces albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-05 15:28 +0000
    Re: Namespaces Ian van Breda <igvb@btopenworld.com> - 2013-08-06 14:25 +0100

#24173 — Namespaces

I've abondaned VOCABULARY and embraced NAMESPACE (since ciforth 5 beta,
that is already 5 years ago.) :
    Compile time: create a wid and remember it.
    Execute: add the wid to the search order.
This indeed implements what are called namespaces in main stream
computer science.

Traditional implementations of VOCABULARY have replace the topmost
word of the search order, such that each invocation of a VOCABULARY
is preceeded by ALSO . Not only does this makes no sense, but it also
serves to confuse an orderly use of namespaces.

This is a quote from the GNU C++ manual about namespaces:

"
Using Namespace Composition

Best practice in programming suggests sequestering new data or
functionality in a sanely-named, unique namespace whenever possible.
This is considered an advantage over dumping everything in the global
namespace, as then name look-up can be explicitly enabled or disabled
as above, symbols are consistently mangled without repetitive naming
prefixes or macros, etc.

For instance, consider a project that defines most of its classes in
namespace gtk. It is possible to adapt namespace gtk to namespace std
by using a C++-feature called namespace composition. This is what
happens if a using-declaration is put into a namespace-definition: the
imported symbol(s) gets imported into the currently active
namespace(s). For example:

namespace gtk
{
  using std::string;
  using std::tr1::array;

  class Window { ... };
}

In this example, std::string gets imported into namespace gtk. The
result is that use of std::string inside namespace gtk can just use
string, without the explicit qualification. As an added bonus,
std::string does not get imported into the global namespace.
"

This is trivially accomplished in a Forth with a NAMESPACE STRING
and a namespace TR1::ARRAY :

"
REQUIRE class

NAMESPACE gtk
gtk DEFINITIONS
   STRING TR1::ARRAY

       class Windows
        ...
        ...

   PREVIOUS PREVIOUS     2]
PREVIOUS
"

The discipline in Forth would be:

1.  Never ever define a new word, except between
   <some-namespace> DEFINITIONS  ... PREVIOUS
   (CURRENT @  ... CURRENT ! is not needed.)
2. Never ever add a namespace to the current search order,
   except temporarily between
   <some-namespace> DEFINITIONS  ... PREVIOUS

Library items can be added where consistance is guaranteed by the
implementor:
   `` WANT class '' or `` REQUIRE class '' 1]
There is no harm these being in the FORTH wordlist.

The technique has been used for ages in CODE words. CODE makes the
assembler wordlist available, but only during the definition of the
code word.

This is almost trivial, so I expect people to come up with examples
of large projects that are organized in this way?


1] This is a plead for an opaque REQUIRE instead of an ill
   defined REQUIRE based on supposedly platform independant
   file manipulations. The WANT in ciforth is opaquely defined:
   WANT x : make the word x available.

2] A NAMESPACE-MARKER that remembers and restores CONTEXT and CURRENT
would be a logical extension of this, replacing the error-prone
calls to PREVIOUS.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [next] | [standalone]

#25029

Albert van der Horst at wrote on 05/07/2013 16:28:

> 
> I've abondaned VOCABULARY and embraced NAMESPACE (since ciforth 5 beta,
> that is already 5 years ago.) :
>     Compile time: create a wid and remember it.
>     Execute: add the wid to the search order.
> This indeed implements what are called namespaces in main stream
> computer science.
> 
> Traditional implementations of VOCABULARY have replace the topmost
> word of the search order, such that each invocation of a VOCABULARY
> is preceeded by ALSO . Not only does this makes no sense, but it also
> serves to confuse an orderly use of namespaces.
> 
There is a problem with the ANS Standard in that the wordlist definitions
have side-effects on the search order.  The Technical Committee indeed
accepted that the implementation of ALSO and ONLY, with their hidden and not
very intuitive effects, was controversial.

My solution has been to put a 'pre-processor' in of font for my own code, if
I want to use a different Forth system.  The basic idea is to separate the
definitions of vocabularies with the words that directly affect the search
order.  

For a VOCULARY (not defined in the Standard),

VOCABULARY ( ³name² -- )
Define a new named wordlist that returns its wid on the stack.

Then
FORTH ( -- wid)
Return the Forth word list.  This is a synonym for FORTH-WORDLIST, which
becomes redundant.

ASSEMBLER ( -- wid)
Returns the assembler word list.  Not used in high-level Forth applications.

These are simple word list definitions.  Definitions that affect the search
order or compilation word list are:

DEFINITIONS ( wid -- )
Set the compilation wordlist to wid.  Add wid to the search order if not
already on the top.

ALSO ( wid -- )
Add the wid argument to the top of the search order.

There are four definitions addition to the above:

VIA (--)
Starts a VIA Š ENDVIA sequence.  Clears the search order.  Expects a list of
vocabulary names in the sequence to be placed on the search stack in the
same order as SET-ORDER and GET-ORDER, i.e. last named first to be searched.

ENDVIA (--)
Terminates a list of VIA names.

There are also a couple useful words used in assembler:

TRANSIENT ( wid -- )
Pushes a transient vocabulary/word-list on top of the search-order.  The
transient is discarded whenever a new definition is added to the dictionary
and only one can be used at a time.

NO-TRANSIENT ( -- )
Removes any transient from on top of the search order.

The is convenient in mixed CODE and colon environments.  If a CODE
definition includes ASSEMBLER TRANSIENT, adds assembler to the top of the
search-order to whatever else is needed for the search (assembler search
first) but removes the assembler when a new definition is added to the
dictionary (which may be a colon definition).  In mixed colon and assembler
code, the assembler search can be discarded in a colon segment with
NO-TRANSIENT.

ONLY is no longer needed and is a pretty obscure definition any way.

As an example, my Pascal parser uses 12 vocabularies - they are best held in
the Forth vocabulary.

In line in execute mode

SCAN-CONTROLS DEFINITIONS
    VIA  SCAN-CONTROLS FORTH  ENDVIA       \ Need FORTH for building defns.
        -- FORTH searched first so that ( : and ; are seen as FORTH versions

This searches Forth first as the SCAN-CONTROLS need to use Forth versions or
( : and ;
    On the other hand, when we actually want the list of token definitions
we search FORTH last.  Note that VIA...ENDVIA in this case is held inside a
colon definition.

    \ Starting macros and compound tokens in token definition-list
: TokenDefinitions
    SCAN-CONTROLS DEFINITIONS              \ Compile to SCAN-CONTROLS vocab
    VIA  FORTH CHARACTER-CLASSES SCAN-CONTROLS  ENDVIA ;
        \ Search scan controls, character classes & FORTH last

Usually, all the vocabularies are held in Forth it self, so any named
vocabulary can be included in a VIA...ENDVIA sequence.  Hidden vocabularies
can still be used if the relevant vocabularies are all made visible.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web