Re: modular programming in Forth

On Oct 9, 3:50 pm, Krishna Myneni <krishna.myn...@xxxxxxxxxxx> wrote:
Ah, so the only point of agreement I thought we had, really isn't.

I'm not sure where you got the idea I wanted to have to include a
module file, then define the public interface out into the actual
target namespace with a bunch of
: foo foo ;
: bar bar ;
...
.... definitions. The public words in that included file *ought* to
show up in the namespace that receives definitions when I include it.

Offhand I don't agree that the module name should provide the private
wordlist. What you describe is an anonymous module with a named
private wordlist.

A fairly misleading description ~ in the original anonymous module,
the private was necessarily anonymous, but as I noted, whether the
public is anonymous or not is left up to the includer.

More descriptive is inherited public, named private. Forth Inc. has
found that that suffices where public / private definitions are
required, and it avoids multiple complexities that might be fun to
solve, but impose unnecessary restrictions on the users.

If NAME-PRIVATE: is added to my existing module.fs,
it would provide the same functionality.

Except NAME-PRIVATE: does *not* provide the same functionality *in
practice*, since it only works without editing for those modules where
the *author* can envision some purpose for later access to the private
words: it doesn't work for any private namespace where the *user*
comes across a purpose at hand.

The library module author ensuring that the only word conflicts that
*have* to be accommodated is the public interface ~ that's a feature.
The library module author denying me the use of some unanticipated use
of his code ~ that's a bug.

And while having the public interface for each module sealed off in a
distinct named wordlist is inconvenient for most users, the flipside
is the ability to detect whether the module has been loaded at all ~
so inheriting the public namespace and naming the private namespace
kills three birds with one stone ~ maximum compatibility with the host
system approach to namespace management, being open to unanticipated
re-use of existing code, and a name at the module level which, if
distinct names are given to distinct versions of a module, can be used
to detect whether the required version of the module is available.
.

Relevant Pages

  • Re: modular programming in Forth
    ... private defns of a single module have different versions? ... may not be a change that a source using the public interface alone has ... All available in the same namespace? ... I see the dual wordlists of a named ...
    (comp.lang.forth)
  • Re: COM Interop - switching to STA Threading - how to?
    ... Public Interface IMyCOMType ... Public Property Get Tokenas String ... Private Property Get IMyCOMType_Tokenas String ... Dim l_MyCOMObject as MyCOMObject ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [RFC] FUSE permission modell (Was: fuse review bits)
    ... >> Shared subtrees and more support in userspace tools is needed before ... >> private namespaces can become really useful. ... I've been looking at the namespace code quite a bit and was ... > mount (and I guess that would impact any subsequent mounts from the ...
    (Linux-Kernel)
  • Re: Problem with namespace
    ... > this path is a Class called AddressView with namespace ... > // class applied to each label ... > ControlViewStyle(); ... > private DataSummaryStyle _CSSServiceCableDetailsSummaryStyle = new ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: How to use WebBrowser in .Net Compact Framework?
    ... The develope environment is VS2005, and the following is my code, ... namespace WebBrowserTest_CE50 ... private System.Windows.Forms.MainMenu mainMenu1; ... but following exception occurred during runtime (running on Windows XP ...
    (microsoft.public.dotnet.framework.compactframework)