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

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

Code management with wordlists

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

Contents

  Code management with wordlists Julian Fondren <julian.fondren@gmail.com> - 2016-08-02 04:00 -0700
    Re: Code management with wordlists peter.m.falth@gmail.com - 2016-08-02 05:03 -0700
      Re: Code management with wordlists hughaguilar96@gmail.com - 2016-08-02 14:40 -0700
    Re: Code management with wordlists Mark Wills <markwills1970@gmail.com> - 2016-08-02 07:15 -0700
    Re: Code management with wordlists Mark Wills <markwills1970@gmail.com> - 2016-08-02 07:16 -0700
    Re: Code management with wordlists Paul Rubin <no.email@nospam.invalid> - 2016-08-02 10:40 -0700
    Re: Code management with wordlists hheinrich.hohl@gmail.com - 2016-08-03 01:18 -0700
      Re: Code management with wordlists JennyB <jennybrien@googlemail.com> - 2016-08-03 03:17 -0700
        Re: Code management with wordlists hughaguilar96@gmail.com - 2016-08-03 10:47 -0700
          Re: Code management with wordlists Julian Fondren <julian.fondren@gmail.com> - 2016-08-03 10:59 -0700
            Re: Code management with wordlists peter.m.falth@gmail.com - 2016-08-04 00:45 -0700
              Re: Code management with wordlists "HAA" <someone@microsoft.com> - 2016-08-04 23:14 +1000
                Re: Code management with wordlists peter.m.falth@gmail.com - 2016-08-04 06:44 -0700
                  Re: Code management with wordlists "HAA" <someone@microsoft.com> - 2016-08-05 10:26 +1000
            Re: Code management with wordlists JennyB <jennybrien@googlemail.com> - 2016-08-04 02:35 -0700
    Re: Code management with wordlists JennyB <jennybrien@googlemail.com> - 2016-08-05 02:54 -0700
    Re: Code management with wordlists krishna.myneni@ccreweb.org - 2016-08-06 08:25 -0700

#49725 — Code management with wordlists

1. Bare bones ANS

  wordlist constant net
  get-order net swap 1+ set-order
  get-current net set-current ( wl )
  
  ... private definitions here ...
  
  ( wl ) set-current
  
  ... public definitions here ...
  
  get-order nip 1- set-order


2. VOCABULARY

  vocabulary net
  also net definitions
  
  ... private definitions here ...
  
  \ using convention that previous vocab receives definitions
  previous definitions also net
  
  ... public definitions here ...
  
  previous


3. Beheading

  | : private-definition1 ... ;
  
  | -1 CONSTANT private
  
  | : private-definition2 ... ;
  
  : public-definition
    private-definition1 private-definition2 ;
  
  | : private-definition3 ... ;
  
  0 CONSTANT public
  
  || 
  
  ( at this point the above private words can no longer be found)


4. Packages

  package net
  
  ... private definitions here ...
  
  public
  
  ... public definitions here ...
  
  private
  
  ... more private definitions maybe ...
  
  end-package



In the above, private definitions are placed in the NET wordlist.
Public definitions are placed in whatever wordlist was current
before PACKAGE NET .  If a package NET already exists prior to the
above, then it is reused, rather than redefined.


Problem: I don't really want to slice my code up into wordlists, I
just want a clear way to designate some words as 'internal' to
some other words.

Solution: put a package around these words and make the internal
ones PRIVATE .  If you have some need to dig these words back up,
later, you can just open the package and get them.

Problem: I have a big well-organized library that I'd like to use --
but the library is slightly incompatible with my environment.  It
assumes that PLACE for example appends a NUL , and accounts for
that, but my PLACEs don't append a NUL .  Can I just load this
library with its modified environment, without editing it or having
to use these weird word variants myself?

Solution: does the well-organized libray use PACKAGE ?  Then create
its packages before you load it and put those variant words in them
for the library to find.

  package BIGLIB
  : PLACE ( a u a -- )  2dup + 0 swap c!  PLACE ;
  end-package
  
  include biglib.fs

Problem: I want to manage my code with wordlists.

Solution: use packages for that.

Problem: I tried using vocabularies extensively to manage my code,
and in the end it was far too unnatural and far much trouble.  These
days I just keep everything in FORTH

Solution: try using packages.  In practice most words are still
dumped into a default wordlist, but related internal words remain in
easily-opened boxes, out of your way by default.  Packages look nice
and do their job without causing problems.


If your system doesn't have PACKAGE , you can pick up some
implementations for some Forth systems here:

http://forth.minimaltype.com/packages.html

That code goes to a little bit of trouble to use VOCABULARY , since
that word does a little more than WORDLIST CONSTANT blah does in
many systems.  For example, ORDER will tend to show a name for a
vocabulary.


-- Julian

[toc] | [next] | [standalone]

#49728

On Tuesday, 2 August 2016 13:00:40 UTC+2, Julian Fondren  wrote:
> 1. Bare bones ANS
> 
>   wordlist constant net
>   get-order net swap 1+ set-order
>   get-current net set-current ( wl )
>   
>   ... private definitions here ...
>   
>   ( wl ) set-current
>   
>   ... public definitions here ...
>   
>   get-order nip 1- set-order
> 
> 
> 2. VOCABULARY
> 
>   vocabulary net
>   also net definitions
>   
>   ... private definitions here ...
>   
>   \ using convention that previous vocab receives definitions
>   previous definitions also net
>   
>   ... public definitions here ...
>   
>   previous
> 
> 
> 3. Beheading
> 
>   | : private-definition1 ... ;
>   
>   | -1 CONSTANT private
>   
>   | : private-definition2 ... ;
>   
>   : public-definition
>     private-definition1 private-definition2 ;
>   
>   | : private-definition3 ... ;
>   
>   0 CONSTANT public
>   
>   || 
>   
>   ( at this point the above private words can no longer be found)
> 
> 
> 4. Packages
> 
>   package net
>   
>   ... private definitions here ...
>   
>   public
>   
>   ... public definitions here ...
>   
>   private
>   
>   ... more private definitions maybe ...
>   
>   end-package
> 
> 
> 
> In the above, private definitions are placed in the NET wordlist.
> Public definitions are placed in whatever wordlist was current
> before PACKAGE NET .  If a package NET already exists prior to the
> above, then it is reused, rather than redefined.
> 
> 
> Problem: I don't really want to slice my code up into wordlists, I
> just want a clear way to designate some words as 'internal' to
> some other words.
> 
> Solution: put a package around these words and make the internal
> ones PRIVATE .  If you have some need to dig these words back up,
> later, you can just open the package and get them.
> 
> Problem: I have a big well-organized library that I'd like to use --
> but the library is slightly incompatible with my environment.  It
> assumes that PLACE for example appends a NUL , and accounts for
> that, but my PLACEs don't append a NUL .  Can I just load this
> library with its modified environment, without editing it or having
> to use these weird word variants myself?
> 
> Solution: does the well-organized libray use PACKAGE ?  Then create
> its packages before you load it and put those variant words in them
> for the library to find.
> 
>   package BIGLIB
>   : PLACE ( a u a -- )  2dup + 0 swap c!  PLACE ;
>   end-package
>   
>   include biglib.fs
> 
> Problem: I want to manage my code with wordlists.
> 
> Solution: use packages for that.
> 
> Problem: I tried using vocabularies extensively to manage my code,
> and in the end it was far too unnatural and far much trouble.  These
> days I just keep everything in FORTH
> 
> Solution: try using packages.  In practice most words are still
> dumped into a default wordlist, but related internal words remain in
> easily-opened boxes, out of your way by default.  Packages look nice
> and do their job without causing problems.
> 
> 
> If your system doesn't have PACKAGE , you can pick up some
> implementations for some Forth systems here:
> 
> http://forth.minimaltype.com/packages.html
> 
> That code goes to a little bit of trouble to use VOCABULARY , since
> that word does a little more than WORDLIST CONSTANT blah does in
> many systems.  For example, ORDER will tend to show a name for a
> vocabulary.
> 
> 
> -- Julian

For this I have 

module

private

public

end-module

It is independent of wordlists, otherwise it works as your package

BR

Peter Fälth

[toc] | [prev] | [next] | [standalone]

#49751

On Tuesday, August 2, 2016 at 5:03:54 AM UTC-7, peter....@gmail.com wrote:
> For this I have 
> 
> module
> 
> private
> 
> public
> 
> end-module
> 
> It is independent of wordlists, otherwise it works as your package
> 
> BR
> 
> Peter Fälth

This looks similar to what I implemented in UR/Forth. I had LOCAL that was used after a definition and marked that definition as smudge-ready. I also had END-MODULE that was used at the end of a module (typically a file) and traversed the entire dictionary --- every word that had its smudge-ready flag set got the smudge-ready flag unset and the smudge flag set.

Implementing this required some carnal knowledge of UR/Forth. I found the flags byte in the header and discovered that there were several bits unused, so I made one of them be my smudge-ready bit. I was already familiar with the inner workings of UR/Forth, so this was pretty easy to implement. I may do this later for VFX, but I'm not at all familiar with the inner workings of VFX so I'll have to disassemble it.

[toc] | [prev] | [next] | [standalone]

#49731

On Tuesday, 2 August 2016 12:00:40 UTC+1, Julian Fondren  wrote:
> 1. Bare bones ANS
> 
>   wordlist constant net
>   get-order net swap 1+ set-order
>   get-current net set-current ( wl )
>   
>   ... private definitions here ...
>   
>   ( wl ) set-current
>   
>   ... public definitions here ...
>   
>   get-order nip 1- set-order
> 
> 
> 2. VOCABULARY
> 
>   vocabulary net
>   also net definitions
>   
>   ... private definitions here ...
>   
>   \ using convention that previous vocab receives definitions
>   previous definitions also net
>   
>   ... public definitions here ...
>   
>   previous
> 
> 
> 3. Beheading
> 
>   | : private-definition1 ... ;
>   
>   | -1 CONSTANT private
>   
>   | : private-definition2 ... ;
>   
>   : public-definition
>     private-definition1 private-definition2 ;
>   
>   | : private-definition3 ... ;
>   
>   0 CONSTANT public
>   
>   || 
>   
>   ( at this point the above private words can no longer be found)
> 
> 
> 4. Packages
> 
>   package net
>   
>   ... private definitions here ...
>   
>   public
>   
>   ... public definitions here ...
>   
>   private
>   
>   ... more private definitions maybe ...
>   
>   end-package
> 
> 
> 
> In the above, private definitions are placed in the NET wordlist.
> Public definitions are placed in whatever wordlist was current
> before PACKAGE NET .  If a package NET already exists prior to the
> above, then it is reused, rather than redefined.
> 
> 
> Problem: I don't really want to slice my code up into wordlists, I
> just want a clear way to designate some words as 'internal' to
> some other words.
> 
> Solution: put a package around these words and make the internal
> ones PRIVATE .  If you have some need to dig these words back up,
> later, you can just open the package and get them.
> 
> Problem: I have a big well-organized library that I'd like to use --
> but the library is slightly incompatible with my environment.  It
> assumes that PLACE for example appends a NUL , and accounts for
> that, but my PLACEs don't append a NUL .  Can I just load this
> library with its modified environment, without editing it or having
> to use these weird word variants myself?
> 
> Solution: does the well-organized libray use PACKAGE ?  Then create
> its packages before you load it and put those variant words in them
> for the library to find.
> 
>   package BIGLIB
>   : PLACE ( a u a -- )  2dup + 0 swap c!  PLACE ;
>   end-package
>   
>   include biglib.fs
> 
> Problem: I want to manage my code with wordlists.
> 
> Solution: use packages for that.
> 
> Problem: I tried using vocabularies extensively to manage my code,
> and in the end it was far too unnatural and far much trouble.  These
> days I just keep everything in FORTH
> 
> Solution: try using packages.  In practice most words are still
> dumped into a default wordlist, but related internal words remain in
> easily-opened boxes, out of your way by default.  Packages look nice
> and do their job without causing problems.
> 
> 
> If your system doesn't have PACKAGE , you can pick up some
> implementations for some Forth systems here:
> 
> http://forth.minimaltype.com/packages.html
> 
> That code goes to a little bit of trouble to use VOCABULARY , since
> that word does a little more than WORDLIST CONSTANT blah does in
> many systems.  For example, ORDER will tend to show a name for a
> vocabulary.
> 
> 
> -- Julian

Julian,

This might provide some inspiration. It is my own system, home-grown for my
hobby Forth system. It's much more modern feeling than the somewhat arcane
Forth vocabulary system. New-comers to Forth have had no problems whatsoever
using it, and I've been using it for two years.

Hope you find this interesting/useful/inspiring.

Mark

[toc] | [prev] | [next] | [standalone]

#49732

On Tuesday, 2 August 2016 12:00:40 UTC+1, Julian Fondren  wrote:
> 1. Bare bones ANS
> 
>   wordlist constant net
>   get-order net swap 1+ set-order
>   get-current net set-current ( wl )
>   
>   ... private definitions here ...
>   
>   ( wl ) set-current
>   
>   ... public definitions here ...
>   
>   get-order nip 1- set-order
> 
> 
> 2. VOCABULARY
> 
>   vocabulary net
>   also net definitions
>   
>   ... private definitions here ...
>   
>   \ using convention that previous vocab receives definitions
>   previous definitions also net
>   
>   ... public definitions here ...
>   
>   previous
> 
> 
> 3. Beheading
> 
>   | : private-definition1 ... ;
>   
>   | -1 CONSTANT private
>   
>   | : private-definition2 ... ;
>   
>   : public-definition
>     private-definition1 private-definition2 ;
>   
>   | : private-definition3 ... ;
>   
>   0 CONSTANT public
>   
>   || 
>   
>   ( at this point the above private words can no longer be found)
> 
> 
> 4. Packages
> 
>   package net
>   
>   ... private definitions here ...
>   
>   public
>   
>   ... public definitions here ...
>   
>   private
>   
>   ... more private definitions maybe ...
>   
>   end-package
> 
> 
> 
> In the above, private definitions are placed in the NET wordlist.
> Public definitions are placed in whatever wordlist was current
> before PACKAGE NET .  If a package NET already exists prior to the
> above, then it is reused, rather than redefined.
> 
> 
> Problem: I don't really want to slice my code up into wordlists, I
> just want a clear way to designate some words as 'internal' to
> some other words.
> 
> Solution: put a package around these words and make the internal
> ones PRIVATE .  If you have some need to dig these words back up,
> later, you can just open the package and get them.
> 
> Problem: I have a big well-organized library that I'd like to use --
> but the library is slightly incompatible with my environment.  It
> assumes that PLACE for example appends a NUL , and accounts for
> that, but my PLACEs don't append a NUL .  Can I just load this
> library with its modified environment, without editing it or having
> to use these weird word variants myself?
> 
> Solution: does the well-organized libray use PACKAGE ?  Then create
> its packages before you load it and put those variant words in them
> for the library to find.
> 
>   package BIGLIB
>   : PLACE ( a u a -- )  2dup + 0 swap c!  PLACE ;
>   end-package
>   
>   include biglib.fs
> 
> Problem: I want to manage my code with wordlists.
> 
> Solution: use packages for that.
> 
> Problem: I tried using vocabularies extensively to manage my code,
> and in the end it was far too unnatural and far much trouble.  These
> days I just keep everything in FORTH
> 
> Solution: try using packages.  In practice most words are still
> dumped into a default wordlist, but related internal words remain in
> easily-opened boxes, out of your way by default.  Packages look nice
> and do their job without causing problems.
> 
> 
> If your system doesn't have PACKAGE , you can pick up some
> implementations for some Forth systems here:
> 
> http://forth.minimaltype.com/packages.html
> 
> That code goes to a little bit of trouble to use VOCABULARY , since
> that word does a little more than WORDLIST CONSTANT blah does in
> many systems.  For example, ORDER will tend to show a name for a
> vocabulary.
> 
> 
> -- Julian

It would help if I included the link! <facepalm!>

http://turboforth.net/resources/applications.htm

[toc] | [prev] | [next] | [standalone]

#49739

Julian Fondren <julian.fondren@gmail.com> writes:
> 3. Beheading
>   | : private-definition1 ... ;
>   | -1 CONSTANT private
>   | : private-definition2 ... ;

Is this implemented somewhere?

[toc] | [prev] | [next] | [standalone]

#49761

On Tuesday, August 2, 2016 at 1:00:40 PM UTC+2, Julian Fondren wrote:
> 1. Bare bones ANS
> 2. VOCABULARY
> 3. Beheading
> 4. Packages

We should add the following two methods to the list:

-----------------------------------------------------------------------

5. Modules

Modules are implemented in VFX Forth and used as follows:

MODULE <name>

: word1 ... ;
: word2 ... ;
: word3 ... ;

EXPORT word3

END-MODULE

All words defined inside the module are hidden except for
the ones that are exported before the end of the module.

Ulrich Hoffmann describes this method in detail.
See http://theforth.net/package/modules

Article in German language:
Forth Magazin "Vierte Dimension" VD 2016-02, Seite 15
Download currently: http://85.214.243.249/filemgmt_data/files/4d2016-02.pdf

Modules are rather similar to packages.
In packages, you decide between private and public on a word-by-word basis.
In modules, every word is private from the beginning. At the end, you export
some words to make them public.

Both methods have their advantages.

-----------------------------------------------------------------------

6. Excising

This method was used in LMI PC/FORTH and UR/FORTH.

EXCISE <word1> <word5>

This command hides the headers of <word1> through <word5> 
by excising their headers from the linked list in the dictionary.

Together with the ability to create binary overlays, the LMI FORTH compilers
enabled the user to create modules that showed only words that are relevant
for the end user.

[toc] | [prev] | [next] | [standalone]

#49762

On Wednesday, 3 August 2016 09:18:20 UTC+1, hheinri...@gmail.com  wrote:
> On Tuesday, August 2, 2016 at 1:00:40 PM UTC+2, Julian Fondren wrote:
> > 1. Bare bones ANS
> > 2. VOCABULARY
> > 3. Beheading
> > 4. Packages
> 
> We should add the following two methods to the list:
> 
> -----------------------------------------------------------------------
> 
> 5. Modules
> 

> All words defined inside the module are hidden except for
> the ones that are exported before the end of the module.
> 

> 6. Excising
> 
> This method was used in LMI PC/FORTH and UR/FORTH.
> 
> EXCISE <word1> <word5>
> 
> This command hides the headers of <word1> through <word5> 
> by excising their headers from the linked list in the dictionary.
> 


It makes more sense to me to name the words you want to keep rather than the ones you want to remove.

REQUIRES  <word1> <word5> 
   create same-name aliases for the following which are in the search order  
   but not on the CURRENT wordlist

NEED <wordlist>
   If the wordlist is loaded, add it to the search order
   otherwise: 
      create a wordlist of that name
      add it to the search wordorder
      set it as CURRENT
      load source file of the same name
      restore CURRENT

So if you only want a few words and don't want to keep the rest of it in the search order you do:

    NEED foo
    REQUIRES fee fo fum
    PREVIOUS

The application, not the library file, defines which words are imported.

 

[toc] | [prev] | [next] | [standalone]

#49767

On Wednesday, August 3, 2016 at 3:17:36 AM UTC-7, JennyB wrote:
> On Wednesday, 3 August 2016 09:18:20 UTC+1, hheinri...@gmail.com  wrote:
> > 6. Excising
> > 
> > This method was used in LMI PC/FORTH and UR/FORTH.
> > 
> > EXCISE <word1> <word5>
> > 
> > This command hides the headers of <word1> through <word5> 
> > by excising their headers from the linked list in the dictionary.
> > 
> 
> 
> It makes more sense to me to name the words you want to keep rather than the ones you want to remove.

I got the idea from UR/Forth and its EXCISE --- I changed it to be more easy to use in that the words to be excised could be marked with LOCAL --- it was not necessary to type out all of their names manually.

As for Jenny's idea, that would be problematic because you can't search the entire dictionary looking for words to keep and excising all the other words --- you would likely smudge a lot of words that you meant to keep --- an accident waiting to happen!

[toc] | [prev] | [next] | [standalone]

#49769

On Tuesday, August 2, 2016 at 7:03:54 AM UTC-5, peter....@gmail.com wrote:
> 
> For this I have 
> 
> module
> 
> private
> 
> public
> 
> end-module
> 
> It is independent of wordlists, otherwise it works as your package

Does that include being able to open the module later and add
definitions to it, or pull out an otherwise private definition?


On Wednesday, August 3, 2016 at 3:18:20 AM UTC-5, hheinri...@gmail.com wrote:
> Article in German language:
> Forth Magazin "Vierte Dimension" VD 2016-02, Seite 15
> Download currently: http://85.214.243.249/filemgmt_data/files/4d2016-02.pdf
> 
> Modules are rather similar to packages.
> In packages, you decide between private and public on a word-by-word basis.
> In modules, every word is private from the beginning. At the end, you export
> some words to make them public.
> 
> Both methods have their advantages.

I don't really see the advantages of the module version.  With
Forth-200x it's at least easier to implement properly, with SYNONYM

With packages the public definitions are defined only once, in the
parent wordlist.  They aren't duplicated.   You also don't have to
maintain a list of words to export -- rather than describe packages
as "deciding word-word-by-word", I would say that the layout of your
library makes it clear which words are public vs. private.

  PUBLIC

  ( all of this is public )

  PRIVATE

  ( all of these are private )

I guess it could be annoying if these words alternated frequently,

> 
> 6. Excising
> 
> This method was used in LMI PC/FORTH and UR/FORTH.
> 
> EXCISE <word1> <word5>
> 
> This command hides the headers of <word1> through <word5> 
> by excising their headers from the linked list in the dictionary.

OK, named beheading instead of prepared beheading.


On Wednesday, August 3, 2016 at 5:17:36 AM UTC-5, JennyB wrote:
> 
> It makes more sense to me to name the words you want to keep rather than the ones you want to remove.
> 
> REQUIRES  <word1> <word5> 
>    create same-name aliases for the following which are in the search order  
>    but not on the CURRENT wordlist
> 
> NEED <wordlist>
>    If the wordlist is loaded, add it to the search order
>    otherwise: 
>       create a wordlist of that name
>       add it to the search wordorder
>       set it as CURRENT
>       load source file of the same name
>       restore CURRENT
> 
> So if you only want a few words and don't want to keep the rest of it in the search order you do:
> 
>     NEED foo
>     REQUIRES fee fo fum
>     PREVIOUS
> 
> The application, not the library file, defines which words are imported.

This lacks the idea of 'public' vs. 'private' words.  You could add
that back with a conventional "import all the public words" command
that libraries might have.  This is similar to how Perl does things:
when you 'use' a module, you also call a subroutine from it, and
convention handles the rest.

  NEED foo REQUIRE-PUBLIC ( implicit PREVIOUS )

And then selection of the actual words imported, it could be done by
any of the above schemes I suppose.


Seems like this construct

  SPECIAL-WORDS: WORD1 WORD2 WORD3 ...

where you've already defined WORD1 et al. elsewhere, maybe at some
distance, and might not want to maintain this separate list, is only
avoided by the package and | beheading and the 'bare bones' schemes.

And I don't have any fondness for that construct.  Imagine that
IMMEDIATE worked like that.  You'd write all of your definitions, and
then to identify your immediate words you'd have to list them again:

  IMMEDIATE this that the-other


On Wednesday, August 3, 2016 at 12:47:48 PM UTC-5, hughag...@gmail.com wrote:
> As for Jenny's idea, that would be problematic because you can't search the entire dictionary looking for words to keep and excising all the other words --- you would likely smudge a lot of words that you meant to keep --- an accident waiting to happen!

There's no smudging in this case.  PREVIOUS removes the uncopied
words from the search order.


-- Julian

[toc] | [prev] | [next] | [standalone]

#49781

On Wednesday, 3 August 2016 19:59:27 UTC+2, Julian Fondren  wrote:
> On Tuesday, August 2, 2016 at 7:03:54 AM UTC-5, peter....@gmail.com wrote:
> > 
> > For this I have 
> > 
> > module
> > 
> > private
> > 
> > public
> > 
> > end-module
> > 
> > It is independent of wordlists, otherwise it works as your package
> 
> Does that include being able to open the module later and add
> definitions to it, or pull out an otherwise private definition?
> 

No it does not.
One of my drivers for implementing it was to also recover the space 
used by the headers. In my system they are separate and it was easy
to drop them.
If I need visibility of a private word I make it public and reload
or recompile the whole system. It takes less then 100 ms so not
a problem

Peter


> 
> On Wednesday, August 3, 2016 at 3:18:20 AM UTC-5, hheinri...@gmail.com wrote:
> > Article in German language:
> > Forth Magazin "Vierte Dimension" VD 2016-02, Seite 15
> > Download currently: http://85.214.243.249/filemgmt_data/files/4d2016-02.pdf
> > 
> > Modules are rather similar to packages.
> > In packages, you decide between private and public on a word-by-word basis.
> > In modules, every word is private from the beginning. At the end, you export
> > some words to make them public.
> > 
> > Both methods have their advantages.
> 
> I don't really see the advantages of the module version.  With
> Forth-200x it's at least easier to implement properly, with SYNONYM
> 
> With packages the public definitions are defined only once, in the
> parent wordlist.  They aren't duplicated.   You also don't have to
> maintain a list of words to export -- rather than describe packages
> as "deciding word-word-by-word", I would say that the layout of your
> library makes it clear which words are public vs. private.
> 
>   PUBLIC
> 
>   ( all of this is public )
> 
>   PRIVATE
> 
>   ( all of these are private )
> 
> I guess it could be annoying if these words alternated frequently,
> 
> > 
> > 6. Excising
> > 
> > This method was used in LMI PC/FORTH and UR/FORTH.
> > 
> > EXCISE <word1> <word5>
> > 
> > This command hides the headers of <word1> through <word5> 
> > by excising their headers from the linked list in the dictionary.
> 
> OK, named beheading instead of prepared beheading.
> 
> 
> On Wednesday, August 3, 2016 at 5:17:36 AM UTC-5, JennyB wrote:
> > 
> > It makes more sense to me to name the words you want to keep rather than the ones you want to remove.
> > 
> > REQUIRES  <word1> <word5> 
> >    create same-name aliases for the following which are in the search order  
> >    but not on the CURRENT wordlist
> > 
> > NEED <wordlist>
> >    If the wordlist is loaded, add it to the search order
> >    otherwise: 
> >       create a wordlist of that name
> >       add it to the search wordorder
> >       set it as CURRENT
> >       load source file of the same name
> >       restore CURRENT
> > 
> > So if you only want a few words and don't want to keep the rest of it in the search order you do:
> > 
> >     NEED foo
> >     REQUIRES fee fo fum
> >     PREVIOUS
> > 
> > The application, not the library file, defines which words are imported.
> 
> This lacks the idea of 'public' vs. 'private' words.  You could add
> that back with a conventional "import all the public words" command
> that libraries might have.  This is similar to how Perl does things:
> when you 'use' a module, you also call a subroutine from it, and
> convention handles the rest.
> 
>   NEED foo REQUIRE-PUBLIC ( implicit PREVIOUS )
> 
> And then selection of the actual words imported, it could be done by
> any of the above schemes I suppose.
> 
> 
> Seems like this construct
> 
>   SPECIAL-WORDS: WORD1 WORD2 WORD3 ...
> 
> where you've already defined WORD1 et al. elsewhere, maybe at some
> distance, and might not want to maintain this separate list, is only
> avoided by the package and | beheading and the 'bare bones' schemes.
> 
> And I don't have any fondness for that construct.  Imagine that
> IMMEDIATE worked like that.  You'd write all of your definitions, and
> then to identify your immediate words you'd have to list them again:
> 
>   IMMEDIATE this that the-other
> 
> 
> On Wednesday, August 3, 2016 at 12:47:48 PM UTC-5, hughag...@gmail.com wrote:
> > As for Jenny's idea, that would be problematic because you can't search the entire dictionary looking for words to keep and excising all the other words --- you would likely smudge a lot of words that you meant to keep --- an accident waiting to happen!
> 
> There's no smudging in this case.  PREVIOUS removes the uncopied
> words from the search order.
> 
> 
> -- Julian

[toc] | [prev] | [next] | [standalone]

#49784

peter.m.falth@gmail.com wrote:
> On Wednesday, 3 August 2016 19:59:27 UTC+2, Julian Fondren  wrote:
> > ...
> > Does that include being able to open the module later and add
> > definitions to it, or pull out an otherwise private definition?
> >
>
> No it does not.
> One of my drivers for implementing it was to also recover the space
> used by the headers. In my system they are separate and it was easy
> to drop them.

Interesting.  I considered doing the same but concluded the effort would
be excessive as all threads around the removed header would need fixing.

[toc] | [prev] | [next] | [standalone]

#49787

On Thursday, 4 August 2016 15:10:53 UTC+2, HAA  wrote:
> peter.m.falth@gmail.com wrote:
> > On Wednesday, 3 August 2016 19:59:27 UTC+2, Julian Fondren  wrote:
> > > ...
> > > Does that include being able to open the module later and add
> > > definitions to it, or pull out an otherwise private definition?
> > >
> >
> > No it does not.
> > One of my drivers for implementing it was to also recover the space
> > used by the headers. In my system they are separate and it was easy
> > to drop them.
> 
> Interesting.  I considered doing the same but concluded the effort would
> be excessive as all threads around the removed header would need fixing.

Yes it required some work, but a traverse-wordlist and a 
traverse-all-wordlists function solved that. For the private words I
allocate space in high memory. Then scanning all words and removing 
the links for those in high memory solved it.

I think I remove more then 500 words in this way

Peter

[toc] | [prev] | [next] | [standalone]

#49793

peter.m.falth@gmail.com wrote:
> On Thursday, 4 August 2016 15:10:53 UTC+2, HAA  wrote:
> > peter.m.falth@gmail.com wrote:
> > > On Wednesday, 3 August 2016 19:59:27 UTC+2, Julian Fondren  wrote:
> > > > ...
> > > > Does that include being able to open the module later and add
> > > > definitions to it, or pull out an otherwise private definition?
> > > >
> > >
> > > No it does not.
> > > One of my drivers for implementing it was to also recover the space
> > > used by the headers. In my system they are separate and it was easy
> > > to drop them.
> >
> > Interesting.  I considered doing the same but concluded the effort would
> > be excessive as all threads around the removed header would need fixing.
>
> Yes it required some work, but a traverse-wordlist and a
> traverse-all-wordlists function solved that. For the private words I
> allocate space in high memory. Then scanning all words and removing
> the links for those in high memory solved it.
>
> I think I remove more then 500 words in this way
>
> Peter

My system is only about 500 words :)  Programs are similarly modest
so I wouldn't have saved much by reclaiming the odd header.  EXCISE
and VOCABULARY tend to suffice for me.  Savings occur when apps
are turnkeyed as all headers and compiler can be discarded.

I agree that once certain word names are deemed unnecessary it can be
made permanent.  If I change my mind later, I just edit the source code.

[toc] | [prev] | [next] | [standalone]

#49783

On Wednesday, 3 August 2016 18:59:27 UTC+1, Julian Fondren  wrote:

> On Wednesday, August 3, 2016 at 5:17:36 AM UTC-5, JennyB wrote:
> > 
> > It makes more sense to me to name the words you want to keep rather than the ones you want to remove.
> > 
> > REQUIRES  <word1> <word5> 
> >    create same-name aliases for the following which are in the search order  
> >    but not on the CURRENT wordlist
> > 
> > NEED <wordlist>
> >    If the wordlist is loaded, add it to the search order
> >    otherwise: 
> >       create a wordlist of that name
> >       add it to the search wordorder
> >       set it as CURRENT
> >       load source file of the same name
> >       restore CURRENT
> > 
> > So if you only want a few words and don't want to keep the rest of it in the search order you do:
> > 
> >     NEED foo
> >     REQUIRES fee fo fum
> >     PREVIOUS
> > 
> > The application, not the library file, defines which words are imported.
> 
> This lacks the idea of 'public' vs. 'private' words.  You could add
> that back with a conventional "import all the public words" command
> that libraries might have.  This is similar to how Perl does things:
> when you 'use' a module, you also call a subroutine from it, and
> convention handles the rest.

>   NEED foo REQUIRE-PUBLIC ( implicit PREVIOUS )
> 
> And then selection of the actual words imported, it could be done by
> any of the above schemes I suppose.
> 
NEED makes the entire wordset available, loading it from source if need me. 
If there are sufficient words that should never be exposed, then they could go in as separate file.

  NEED private-words
  
     ( define public words here )
     ( note: if private words are redefined here, the new versions 
        remain hidden until after PREVIOUS)
  PREVIOUS


Which would work either directly in the application source, or as an interface file - a two-file module system. 


    
> 
> 
> Seems like this construct
> 
>   SPECIAL-WORDS: WORD1 WORD2 WORD3 ...
> 
> where you've already defined WORD1 et al. elsewhere, maybe at some
> distance, and might not want to maintain this separate list, is only
> avoided by the package and | beheading and the 'bare bones' schemes.
> 

My idea was based on the documentation "Requires /word(s)/ from /wordset/ 
That's useful information, so why not do that in code?

> And I don't have any fondness for that construct.  Imagine that
> IMMEDIATE worked like that.  You'd write all of your definitions, and
> then to identify your immediate words you'd have to list them again:
> 
>   IMMEDIATE this that the-other
> 

That is a matter of taste. I actually find IMMEDIATE quite 'noisy,' and prefer Pigmy's Interpreter ... Compiler syntax, but that's just me. 

[toc] | [prev] | [next] | [standalone]

#49800

On Tuesday, 2 August 2016 12:00:40 UTC+1, Julian Fondren  wrote:
> 1. Bare bones ANS
> 
>   wordlist constant net
>   get-order net swap 1+ set-order
>   get-current net set-current ( wl )
>   
>   ... private definitions here ...
>   
>   ( wl ) set-current
>   
>   ... public definitions here ...
>   
>   get-order nip 1- set-order
> 
> 
> 2. VOCABULARY
> 
>   vocabulary net
>   also net definitions
>   
>   ... private definitions here ...
>   
>   \ using convention that previous vocab receives definitions
>   previous definitions also net
>   
>   ... public definitions here ...
>   
>   previous
> 
> 
> 3. Beheading
> 
>   | : private-definition1 ... ;
>   
>   | -1 CONSTANT private
>   
>   | : private-definition2 ... ;
>   
>   : public-definition
>     private-definition1 private-definition2 ;
>   
>   | : private-definition3 ... ;
>   
>   0 CONSTANT public
>   
>   || 
>   
>   ( at this point the above private words can no longer be found)
> 
> 
> 4. Packages
> 
>   package net
>   
>   ... private definitions here ...
>   
>   public
>   
>   ... public definitions here ...
>   
>   private
>   
>   ... more private definitions maybe ...
>   
>   end-package
> 
> 
> 
> In the above, private definitions are placed in the NET wordlist.
> Public definitions are placed in whatever wordlist was current
> before PACKAGE NET .  If a package NET already exists prior to the
> above, then it is reused, rather than redefined.
> 
> 
> Problem: I don't really want to slice my code up into wordlists, I
> just want a clear way to designate some words as 'internal' to
> some other words.
> 
> Solution: put a package around these words and make the internal
> ones PRIVATE .  If you have some need to dig these words back up,
> later, you can just open the package and get them.
> 
> Problem: I have a big well-organized library that I'd like to use --
> but the library is slightly incompatible with my environment.  It
> assumes that PLACE for example appends a NUL , and accounts for
> that, but my PLACEs don't append a NUL .  Can I just load this
> library with its modified environment, without editing it or having
> to use these weird word variants myself?
> 
> Solution: does the well-organized libray use PACKAGE ?  Then create
> its packages before you load it and put those variant words in them
> for the library to find.
> 
>   package BIGLIB
>   : PLACE ( a u a -- )  2dup + 0 swap c!  PLACE ;
>   end-package
>   
>   include biglib.fs
> 
> Problem: I want to manage my code with wordlists.
> 
> Solution: use packages for that.
> 
> Problem: I tried using vocabularies extensively to manage my code,
> and in the end it was far too unnatural and far much trouble.  These
> days I just keep everything in FORTH
> 
> Solution: try using packages.  In practice most words are still
> dumped into a default wordlist, but related internal words remain in
> easily-opened boxes, out of your way by default.  Packages look nice
> and do their job without causing problems.
> 
> 
> If your system doesn't have PACKAGE , you can pick up some
> implementations for some Forth systems here:
> 
> http://forth.minimaltype.com/packages.html
> 
> That code goes to a little bit of trouble to use VOCABULARY , since
> that word does a little more than WORDLIST CONSTANT blah does in
> many systems.  For example, ORDER will tend to show a name for a
> vocabulary.
> 
Looking at this, and the increased use in Forth of anonymous xts, I wonder if there is a case for having a universal way of naming such things if needed.

I'm thinking   n NAMED /name/  where /name/ works as a Constant, but the value it returns, if passed to NAME>STRING , returns the string /name/


Thus  : CREATE   HERE NAMED ;
      : VOCABULARY   WORDLIST NAMED DOES> +order ;
      : ORDER   GET-ORDER 0 DO NAME>STRING TYPE SPACE LOOP ; 
 
> -- Julian

[toc] | [prev] | [next] | [standalone]

#49819

On Tuesday, August 2, 2016 at 6:00:40 AM UTC-5, Julian Fondren wrote:
> ...
> Problem: I want to manage my code with wordlists.
> 
> Solution: use packages for that.
> 
> Problem: I tried using vocabularies extensively to manage my code,
> and in the end it was far too unnatural and far much trouble.  These
> days I just keep everything in FORTH
> 
> Solution: try using packages.  In practice most words are still
> dumped into a default wordlist, but related internal words remain in
> easily-opened boxes, out of your way by default.  Packages look nice
> and do their job without causing problems.
> 
> 
> If your system doesn't have PACKAGE , you can pick up some
> implementations for some Forth systems here:
> 
> http://forth.minimaltype.com/packages.html
> ... 


There is also the fully-documented modules system developed by myself and David Williams, which has worked well for me over the last four years:

ftp://ccreweb.org/software/lyx/forth/modular-forth.pdf
ftp://ccreweb.org/software/lyx/forth/modular-forth.lyx
ftp://ccreweb.org/software/gforth/modules.fs

Krishna

[toc] | [prev] | [standalone]

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

csiph-web