example modular code (experimental)

I've posted an example of the type of modular code I had in mind,
including the modules interface (v. 0.3.1), at

ftp://ccreweb.org/software/kforth/ex...ental/modules/

The main application is

term.4th

It relies on the following modules,

serial.4th
serial-comm.4th
dummy-comm.4th
terminal.4th

The terminal module allows for different communications interfaces to
be used. Here, in the application loader, term.4th, either the serial
comm interface can be used or the dummy comm interface can be used.

The serial port code is specific to kForth because of a requirement
for non-blocking I/O. The main purpose of the example is to show how
different modules can implement words with the same names in their
public interfaces, and this does not create a problem in writing code
that is reusable, and also loadable at the same time. Examples of
public words which are reused are OPEN CLOSE WRITE GET PUT , etc.

The terminal module needs a little better factoring. But one can see
that it is independent of the communications interface, and can be
reused in any setting in which the particular asynchronous comm model
is valid.

Krishna

On Oct 28, 6:40*pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> I've posted an example of the type of modular code I had in mind,
> including the modules interface (v. 0.3.1), at
>
> ftp://ccreweb.org/software/kforth/ex...ental/modules/

Does End-Module actually work?

I see several files with the pattern:

get-order

Module: foo
ALSO foo-depends-on

Begin-Module
...
End-Module

set-order

If End-Module works correctly, shouldn't this be:

Module: foo

Begin-Module
ALSO foo-depends-on

...
End-Module

Also, if foo-depends-on is in the search order, why use:
:: foo-depends-on bar

I also must be betraying my age in seeing

something-else :: foo-depends-on bar

as:
something-else :: foo-depends-on
bar

.... rather than as:
something-else
:: foo-depends-on bar

On Oct 28, 6:21*pm, BruceMcF <agil...@netscape.net> wrote:
> On Oct 28, 6:40*pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
>
> > I've posted an example of the type of modular code I had in mind,
> > including the modules interface (v. 0.3.1), at
>
> >ftp://ccreweb.org/software/kforth/ex...ental/modules/
>
> Does End-Module actually work?
>
> I see several files with the pattern:
>
> * get-order
>
> * Module: foo
> * ALSO foo-depends-on
>
> * Begin-Module
> * ...
> * End-Module
>
> * set-order
>
> If End-Module works correctly, shouldn't this be:
>
> * Module: foo
>
> * Begin-Module
> * ALSO foo-depends-on
>
> * ...
> * End-Module
>

Your example is the way it was originally in David N. Williams' root-
module.fs. However, I had to change it for the following reason: Begin-
Module pushes the public and private wordlists into the search order,
in that order. If additional wordlists are pushed onto the search
order after the public and private wordlists, this breaks the ability
to have any arbitrary selection of names in the module, because those
names may appear in the search order from the later added wordlists.

The module code should always find its own definitions *first*, not
the ones from wordlists added after Begin-Module. This is why I moved
the dependencies declaration to before Begin-Module. Now, End-Module
can automatically remove the module's private and public wordlists,
but it can no longer automatically remove the module dependencies from
the search order. This is an acceptable compromise to me, since we can
use GET-ORDER and SET-ORDER to accomplish that separately.

> Also, if foo-depends-on is in the search order, why use:
> * :: foo-depends-on bar
>

There are some cases where an explicit module reference is important,
in case that module's wordlist is deeper in the search order than
other wordlists in the search order having the same name. In some
cases, it may have been paranoia on my part to ensure that I am using
a particular word from a particular wordlist.

> I also must be betraying my age in seeing
>
> * *something-else :: foo-depends-on bar
>
> as:
> * *something-else :: foo-depends-on
> * *bar
>
> ... rather than as:
> * *something-else
> * *:: foo-depends-on bar

C++ uses "::" in the following manner <class_name>::<member> . So, my
notation with using "::" preceding the module name, followed by the
word name is different, by necessity. Adequate code formatting should
help with this.


Incidentally, the term.4th example code loads and runs successfully
with either the dummy comm interface or the serial comm interface. I
haven't yet tested if the serial port communications work correctly.

For reference, this modular version is based on earlier code. For
comparison, these files are,

ftp://ccreweb.org/software/kforth/examples/serial.4th
ftp://ccreweb.org/software/kforth/examples/terminal.4th

The old version of terminal.4th is really very poorly factored, and
it's hardwired for the serial port interface only. So the advantages
of recoding terminal.4th as a module, with the ability to use
arbitrary Comm interfaces, are readily apparent. Even the terminal.4th
module needs additional work. For example, the ansi output words
should be in a module. Also, the extended key mappings, e.g. for the
Fxx keys depends on the system (X11 under Linux, Windows, etc.), so
there is probably an advantage to modularizing the key mappings.

Krishna

On Oct 28, 9:33*pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
....
> The module code should always find its own definitions *first*, ...

I'll qualify the above statement by saying that module code should
find its own definitions first, except when it shouldn't. For those
cases, the explicit module reference operator should be invoked, e.g.

Module: foo
get-order
ALSO bar \ dependency on module bar , which has public word, OPEN

Begin-Module

Public:

: open ( ... ) ;

\ setup needs to invoke OPEN from bar
: setup ( ... ) :: bar open ( ... ) ;

End-Module

set-order

--

Maybe the get-order and set-order can be tidied up by folding them
into MODULE: and End-Module, respectively. However, that wouldn't work
for unnamed modules.

Krishna

On Oct 28, 10:33*pm, Krishna Myneni <krishna.myn...@ccreweb.org>
wrote:
> Your example is the way it was originally in David N. Williams' root-
> module.fs. However, I had to change it for the following reason: Begin-
> Module pushes the public and private wordlists into the search order,
> in that order. If additional wordlists are pushed onto the search
> order after the public and private wordlists, this breaks the ability
> to have any arbitrary selection of names in the module, because those
> names may appear in the search order from the later added wordlists.

> The module code should always find its own definitions *first*, not
> the ones from wordlists added after Begin-Module. This is why I moved
> the dependencies declaration to before Begin-Module. Now, End-Module
> can automatically remove the module's private and public wordlists,
> but it can no longer automatically remove the module dependencies from
> the search order.

Ah yes, you remind me that this is why I record the depth in
``Module-Name:'' = your ``Module:''

Most of what you do in ``Begin-Module'', I do in ``Module-Name:'', and
what ``Begin-Module'' mostly does is put private, and possibly public,
on top of the search order.

> > Also, if foo-depends-on is in the search order, why use:
> > * :: foo-depends-on bar

> There are some cases where an explicit module reference is important,
> in case that module's wordlist is deeper in the search order than
> other wordlists in the search order having the same name. In some
> cases, it may have been paranoia on my part to ensure that I am using
> a particular word from a particular wordlist.

I'm thinking that the ``:: vocab word'' means that there can be a lack
of dependency indication.


>> I also must be betraying my age in seeing
>> * *something-else :: foo-depends-on bar

>> as:
>> * *something-else :: foo-depends-on
>> * *bar

>> ... rather than as:
>> * *something-else
>> * *:: foo-depends-on bar

> C++ uses "::" in the following manner <class_name>::<member> .

It must have come from the aura and penumbra that C++ was born in,
since I never used C++ but I did a brute force maximum entropy
estimate of a Leontiev Input-Output models in C for my dissertation in
the mid 90's.

> So, my notation with using "::" preceding the module name, followed
> by the word name is different, by necessity. Adequate code
> formatting should help with this.

With self-pushing wordlists, ``vocab :: word'' is possible, but _ce la
vie_.

On Oct 28, 10:33*pm, BruceMcF <agil...@netscape.net> wrote:
> On Oct 28, 10:33*pm, Krishna Myneni <krishna.myn...@ccreweb.org>
> wrote:
>
> > Your example is the way it was originally in David N. Williams' root-
> > module.fs. However, I had to change it for the following reason: Begin-
> > Module pushes the public and private wordlists into the search order,
> > in that order. If additional wordlists are pushed onto the search
> > order after the public and private wordlists, this breaks the ability
> > to have any arbitrary selection of names in the module, because those
> > names may appear in the search order from the later added wordlists.
> > The module code should always find its own definitions *first*, not
> > the ones from wordlists added after Begin-Module. This is why I moved
> > the dependencies declaration to before Begin-Module. Now, End-Module
> > can automatically remove the module's private and public wordlists,
> > but it can no longer automatically remove the module dependencies from
> > the search order.
>
> Ah yes, you remind me that this is why I record the depth in
> * ``Module-Name:'' = your ``Module:''
>
> Most of what you do in ``Begin-Module'', I do in ``Module-Name:'', and
> what ``Begin-Module'' mostly does is put private, and possibly public,
> on top of the search order.
>

The reason for making MODULE: do so little was to allow the module to
be named externally, by the module loader, if desired.

> > > Also, if foo-depends-on is in the search order, why use:
> > > * :: foo-depends-on bar
> > There are some cases where an explicit module reference is important,
> > in case that module's wordlist is deeper in the search order than
> > other wordlists in the search order having the same name. In some
> > cases, it may have been paranoia on my part to ensure that I am using
> > a particular word from a particular wordlist.
>
> I'm thinking that the ``:: vocab word'' means that there can be a lack
> of dependency indication.
>

Yes, that's correct. No dependencies need to be declared if you refer
to words using the module reference operator. This method will never
break, unless the module name itself has been redefined as some other
word.

> >> I also must be betraying my age in seeing
> >> * *something-else :: foo-depends-on bar
> >> as:
> >> * *something-else :: foo-depends-on
> >> * *bar
> >> ... rather than as:
> >> * *something-else
> >> * *:: foo-depends-on bar
> > C++ uses "::" in the following manner <class_name>::<member> .
>
> It must have come from the aura and penumbra that C++ was born in,
> since I never used C++ but I did a brute force maximum entropy
> estimate of a Leontiev Input-Output models in C for my dissertation in
> the mid 90's.
>
> > So, my notation with using "::" preceding the module name, followed
> > by the word name is different, by necessity. Adequate code
> > formatting should help with this.
>
> With self-pushing wordlists, ``vocab :: word'' is possible, but _ce la
> vie_.

Self-pushing wordlists should not be used, within my modules
implementation, for the very simple reason that we would not be able
to do either " :: <module_name> <word> " or " <module_name> :: <word>
" when module_name is "Forth". That would be a very severe
restriction.

Krishna

On Oct 28, 11:12*pm, Krishna Myneni <krishna.myn...@ccreweb.org>
wrote:
> On Oct 28, 9:33*pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> ...
>
> > The module code should always find its own definitions *first*, ...

> I'll qualify the above statement by saying that module code should
> find its own definitions first, except when it shouldn't.

Module: foo \ record prior-depth here
ALSO bar1

Begin-Module \ record prior-depth here if its presently zero
ALSO bar2
....
End-Module \ reset order with prior-depth, then reset prior-depth

: Module:
... order-depth prior-depth ! ... ;

: Begin-Module
...
prior-depth @ 0= IF order-depth prior-depth ! THEN
... ;

: End-Module
...
order-depth prior-depth @ - drop-order 0 prior-depth !
... ;

On Oct 28, 5:40*pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> I've posted an example of the type of modular code I had in mind,
> including the modules interface (v. 0.3.1), at
>
> ftp://ccreweb.org/software/kforth/ex...ental/modules/
> ...

A fully-compatible ANS Forth version of the modules implementation is
given in,

ftp://ccreweb.org/software/gforth/experimental/modules/

There is also a file with examples of usage, called modules-usage.fs.

Krishna

On Oct 29, 12:08*am, BruceMcF <agil...@netscape.net> wrote:
> On Oct 28, 11:12*pm, Krishna Myneni <krishna.myn...@ccreweb.org>
> wrote:
>
> > On Oct 28, 9:33*pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> > ...
>
> > > The module code should always find its own definitions *first*, ...
> > I'll qualify the above statement by saying that module code should
> > find its own definitions first, except when it shouldn't.
>
> Module: foo \ record prior-depth here
> ALSO bar1
>
> Begin-Module \ record prior-depth here if its presently zero
> ALSO bar2
> ...
> End-Module \ reset order with prior-depth, then reset prior-depth
>
> : Module:
> * *... order-depth prior-depth ! ... ;
>
> : Begin-Module
> * *...
> * *prior-depth @ 0= IF order-depth prior-depth ! THEN
> * *... ;
>
> : End-Module
> * *...
> * *order-depth prior-depth @ - drop-order *0 prior-depth !
> * *... ;

I'm having trouble seeing how the above solution addresses the problem
of module code finding the module's own definitions in the search
order first. Are you addressing the problem of having to use GET-ORDER
and SET-ORDER explicitly for dependencies declared before BEGIN-
MODULE ?

Krishna

On Oct 29, 10:22*am, Krishna Myneni <krishna.myn...@ccreweb.org>
wrote:
> On Oct 29, 12:08*am, BruceMcF <agil...@netscape.net> wrote:
>
>
>
> > On Oct 28, 11:12*pm, Krishna Myneni <krishna.myn...@ccreweb.org>
> > wrote:
>
> > > On Oct 28, 9:33*pm, Krishna Myneni <krishna.myn...@ccreweb.org> wrote:
> > > ...
>
> > > > The module code should always find its own definitions *first*, ...
> > > I'll qualify the above statement by saying that module code should
> > > find its own definitions first, except when it shouldn't.
>
> > Module: foo \ record prior-depth here
> > ALSO bar1
>
> > Begin-Module \ record prior-depth here if its presently zero
> > ALSO bar2
> > ...
> > End-Module \ reset order with prior-depth, then reset prior-depth
>
> > : Module:
> > * *... order-depth prior-depth ! ... ;
>
> > : Begin-Module
> > * *...
> > * *prior-depth @ 0= IF order-depth prior-depth ! THEN
> > * *... ;
>
> > : End-Module
> > * *...
> > * *order-depth prior-depth @ - drop-order *0 prior-depth !
> > * *... ;
>
> I'm having trouble seeing how the above solution addresses the problem
> of module code finding the module's own definitions in the search
> order first. Are you addressing the problem of having to use GET-ORDER
> and SET-ORDER explicitly for dependencies declared before BEGIN-
> MODULE ?

Yes. Search order changes between ``Module:'' and ``Begin-Module'' are
cleaned up by ``End-Module'', but since its Begin-Module that puts the
public and private wordlists in the search order, rest behind the
public and private wordlists.

On Oct 29, 12:26*am, Krishna Myneni <krishna.myn...@ccreweb.org>
wrote:
> The reason for making MODULE: do so little was to
> allow the module to be named externally, by the
> module loader, if desired.

But it goes well beyond what is needed for that. For that, a simpler
BEGIN-MODULE and a MODULE: that goes ahead and creates the public-wid
and private-wid and loads those variables works perfectly fine.

If END-MODULE resets the relevant values, then BEGIN-MODULE can simply
perform default actions when the variables are zeroed out (nb. the
variable named are from my implementation, I believe the
correspondence is clear):

\ This is useful on its own
: Module-Default? ( -- flag ) order-depth @ 0= ;

: BEGIN-MODULE ( -- )
Module-Default? IF
order-depth prior-depth !
WORDLIST private-wid !
GET-CURRENT public-wid !
THEN ALSO Module-System
public-wid @ >order
private-wid @ >order ;

: END-MODULE ( -- )
order-depth prior-depth @ - order-drops
prior-current @ SET-CURRENT
0 prior-depth ! ;

This not only enables your anonymous modules if nothing is done, but
also enables a default module which is ignored if the search order
state has already been performed, so that the named module model is
also available as a default, but can be overridden by the loadscript:

Default-Module? [IF]
MODULE: MyFoo2
ALSO MyFoo1
[THEN] BEGIN-MODULE
...
END-MODULE

Oops. caught napping switching between models:

\ This is useful on its own
: Module-Default? ( -- flag ) order-depth @ 0= ;

: BEGIN-MODULE ( -- )
* *Module-Default? IF
* * * order-depth prior-depth !
* * WORDLIST private-wid !
* * * GET-CURRENT DUP public-wid ! prior-current !
\ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* *THEN ALSO Module-System
* *public-wid @ >order
*private-wid @ >order ;

: END-MODULE ( -- )
* *order-depth prior-depth @ - order-drops
* *prior-current @ SET-CURRENT
* *0 prior-depth ! ;

I think if I were revising it, it'd be something like the following
(the extra gymnaastics to use VOCABULARY for NAMEDLIST: if VOCABULARY
is in the F83 style omitted):

.... untested, I have to go out and get trick or treat candy for
"beggers afternoon" from 3-5 (they don't have trick or treat at night
in this town). Change [] for ~~ or || or >< or {} or whatever digraphs
is picked for that function.

\ modules031-revA.4th
( Title: Modular programming in Forth
File: modules.4th
Version: 0.3.1 - Revision A
Revised: October 28, 2011
Revision: A, October 29 2011 BRM


Description:
-----------

This library provides a facility for modular programming in
Forth. It supports both named and unnamed modules, and allows
for private definitions in a module to be made accessible.
The library uses design features from several sources:
David N. Williams' root-module.fs [v 0.8.2], Bruce McFarling's
suggested module facility for the Forth Scientific Library [FSL],
the original module facility in the FSL's fsl-util auxiliary files,
and Neal Bridges' anonymous modules code.


Design elements:
---------------

1. The layout of a module is determined by the following words:

MODULE: BEGIN-MODULE PUBLIC: PRIVATE: END-MODULE

Here, BEGIN-MODULE is where the module begins, and END-MODULE
is where it ends. The code area between the two is "inside" the
module. The words PUBLIC: and PRIVATE: control the visibility
of the module code to external code and to the user. Assigning
a name to the module with MODULE: is optional, but highly
encouraged to avoid name clash problems.

1A. An alternate layout is:

PRIVATE-MODULE: BEGIN-MODULE PUBLIC: PRIVATE: END-MODULE

Here, PRIVATE-MODULE names a private module but compiles PUBLIC
words into the present compilation target

2. A module contains two types of words: "public" and "private".
The word PUBLIC: declares that subsequent definitions are
public words, while the word PRIVATE: declares subsequent
definitions to be private words. The public words of a
module constitute the API or application programming
interface to the module. Private words are not intended
to be used by the module user.

3. A module may or may not be named:

a] For an unnamed module, the public definitions are compiled
into the current compilation wordlist.

b] For a named module, the public definitions are compiled
into a new wordlist, the module's public wordlist. Invoking
the module name replaces the top wordlist id on the search
order with the public wordlist of the module. To add the
public wordlist to the search order, use

ALSO <module_name>

c] For both a named and an unnamed module, a new private
wordlist is created. For named modules, the private
wordlist id can be retrieved using >PRIVATE on the
module xt. The private wordlist of an unnamed module
is not accessible outside the module.

4. PRIVATE: and PUBLIC: should occur only inside a module, and may
be invoked any number of times there, in any order. Definitions
inside a module usually go into its public or private
wordlist.

5. The module layout is not nestable.

6. The search order depth and compilation wordlist just before either
MODULE: or PRIVATE-MODULE: or, if the module is anonymous,
BEGIN-MODULE are restored by END-MODULE. The part of the search
order present before this point may not be changed inside the
module.

[This could be made safer by actually saving and restoring
the initial search order. This implementation does not do
that.]

7. The module name reference operator, [] , allows direct
referencing of a word inside of a named module, using the
syntax,

[] <module_name> <word>

The reference operator [] may be used in either compilation
or interpretation state.

8. To add the private words to the search order, use:

ALSO-PRIVATE: name

)


\ *** GENERAL USE

[UNDEFINED] drops [IF] \ BMcF
: drops ( +n -- ) 0 ?DO drop LOOP ; [THEN]

[UNDEFINED] order-drops [IF]
: order-drops ( +n -- ) ( o: wid_n ... wid_1 -- )
0 ?DO previous LOOP ; [THEN]

[UNDEFINED] order-depth [IF]
: order-depth ( -- n ) get-order dup >r drops r> ; [THEN]

[UNDEFINED] >order [IF] \ same as BMcF's ADD-WORDLIST
: >order ( wid -- order: wid )
>r get-order r> swap 1+ set-order ; [THEN]

[UNDEFINED] order> [IF] \ not used in this module
: order> ( o: wid -- ) ( -- wid )
get-order swap >r 1- set-order r> ; [THEN]

[UNDEFINED] order@ [IF] \ not used in this module
: order@ ( o: wid -- ) ( -- wid )
get-order over >r drops r> ; [THEN]


[UNDEFINED] MODULE: [IF]

: NAMEDLIST: ( "name" -- ) \ F83 style vocabulary
WORDLIST CREATE , DOES> order> drop @ >order ;

GET-CURRENT
NAMEDLIST: Module-System
ALSO Module-System DEFINITIONS

\ *** PRIVATE DEFINITIONS

VARIABLE prior-defs DUP prior-defs !
VARIABLE public-defs public-defs !
VARIABLE prior-depth order-depth 1- prior-depth !
VARIABLE private-defs order@ private-defs !

: PRIVATE: ( -- ) private-defs @ SET-CURRENT ;
: PUBLIC: ( -- ) public-defs @ SET-CURRENT ;

: END-MODULE ( o: <extras> -- )
(
Restore the initial search order depth and compilation wordlist. An
ambiguous condition exists if the initial search order has been
clobbered. Reset the named-module flag.
)
initial-defs @ SET-CURRENT
order-depth prior-depth @ - order-drops
0 prior-depth ! ;

: NAMEDLIST&ID: ( "name" -- wid ) \ create namedlist & return wid
>IN @ NAMEDLIST >IN ! ALSO ' EXECUTE order> ;

\ *** PUBLIC DEFINITIONS

PUBLIC

\ Conditional compilation test for whether module
\ definition is already in progress

: Default-Module? ( -- flag ) prior-depth @ 0= ;

\ Create a named private module and store information
\ for BEGIN-MODULE

: PRIVATE-MODULE: ( "name" -- )
order-depth prior-depth !
GET-CURRENT DUP prior-defs ! DUP public-defs !
ALSO Module-System DEFINITIONS NAMEDLIST&ID: private-defs !
>IN ! SET-CURRENT PREVIOUS ;

\ Create named public module and store information
\ for BEGIN-MODULE

: MODULE: ( "name" -- )
>IN @ PRIVATE-MODULE:
>IN ! NAMEDLIST&ID: public-defs ! ;

\ Add private wordlist to search order
: ALSO-PRIVATE: ( "module" -- wid )
PARSE-NAME ALSO Module-System order> SEARCH-WORDLIST ABORT" Module
not found."
ALSO EXECUTE ;

\ BEGIN-MODULE and END-MODULE are not to be nested.

: BEGIN-MODULE ( -- ) ( o: -- public private )
(
Save information that allows END-MODULE to restore the initial
search order and compilation wordlist, assuming the initial
order has remained unchanged. If a module definitions is not
already in process, set up the private and public wordlist.
Push the public and private wordlists onto the search order,
and set the private wordlist to be the current compilation
wordlist.
)
prior-depth @ 0= IF
order-depth prior-depth !
WORDLIST private-defs !
GET-CURRENT public-defs !
THEN ALSO Module-System
public-defs @ >order
private-defs @ >order
DEFINITIONS ;

\ Module targeted word reference operator
: []
state @ if bl word find 0= ABORT" Unknown Module!"
else ' then also execute
state @ if postpone ['] postpone execute else ' execute then
previous
; immediate

END-MODULE

[THEN]
\ --------------------------------------------

On 28/10/2011 23:40, Krishna Myneni wrote:
> I've posted an example of the type of modular code I had in mind,
> including the modules interface (v. 0.3.1), at
>
> ftp://ccreweb.org/software/kforth/ex...ental/modules/
>
> The main application is
>
> term.4th
>
> It relies on the following modules,
>
> serial.4th
> serial-comm.4th
> dummy-comm.4th
> terminal.4th
>
> The terminal module allows for different communications interfaces to
> be used. Here, in the application loader, term.4th, either the serial
> comm interface can be used or the dummy comm interface can be used.
>
> The serial port code is specific to kForth because of a requirement
> for non-blocking I/O. The main purpose of the example is to show how
> different modules can implement words with the same names in their
> public interfaces, and this does not create a problem in writing code
> that is reusable, and also loadable at the same time. Examples of
> public words which are reused are OPEN CLOSE WRITE GET PUT , etc.
>
[..]

ISTM that applications like this are begging to be implemented in OO
Forth. e.g in rough outline using Mini-oof syntax and the hierarchy is
probably wrong:

object class
method open
method close
method write
method get
method put
end-class DummyComm

:noname ( code for dummy open ) ; DummyComm defines open
:noname ( code for dummy close ) ; DummyComm defines close
etc

DummyComm class
\ any additional methods
end-class Serial

:noname ( ... ) ; Serial defines open
:noname ( ... ) ; Serial defines close
etc

Serial class
( ... )
end-class SerialComm

:noname ( ... ) ; SerialComm defines open
:noname ( ... ) ; SerialComm defines close
etc
etc

\ Code for methods can call that for the parent class where appropriate

\ Define objects which will then be used to call the methods.
Serial new constant serial
SerialComm new constant serial-comm

\ Use these objects to call the methods

Sorry this isn't a helpful discussion of your modules code but I thought
it worth pointing out an alternative. Whether one technique is better
than the other is, I suppose, just a matter of taste.

Classes are a sort of module anyway and, in addition, you could
modularise an OOF version if so desired. Having classes inside a module
is one reason I would like to see modules nestable.

Of course the same sort of thing can be done using deferred words
instead of an OOF.

--
Gerry

On Oct 29, 1:15*pm, BruceMcF <agil...@netscape.net> wrote:
> I think if I were revising it, it'd be something like the following
> (the extra gymnaastics to use VOCABULARY for NAMEDLIST: if VOCABULARY
> is in the F83 style omitted):
>
> ... untested, I have to go out and get trick or treat candy for
> "beggers afternoon" from 3-5 (they don't have trick or treat at night
> in this town).

I still have to find a costume ...

> Change [] for ~~ or || or >< or {} or whatever digraphs
> is picked for that function.
>

Ok. At this point, it's not clear to me how object-oriented code
should be mixed with my proposed module scheme. Need to try to use
mini-oof within a module, to see what makes sense.

Thanks for the rev. I will try it.

Krishna