What exactly is a package? 
Author Message
 What exactly is a package?

Well, I have a rough idea from comments in this group, and from
my meager understanding of Common Lisp (which I try to avoid).

        A package is, or can be, a separate compilation unit
        with a well defined, exported interface.  Other
        packages may import names from the package (using the
        syntax "(import pkg:name)" in CL), to simplify
        references, but the name "pkg:name" can be used as well.

Jaffer's slib uses the convention that all symbols defined by a
library file have the "package" name as a prefix, but this has
no real weight, since all the names end up in the top-level
environment anyway.

So why don't we just use closures in scheme with a dispatch
function:

        (load "bar-pkg")
        (define foo-pkg
          (let ((helper (bar-pkg 'barfunc))
                (func1 (lambda (n) (helper n 1)))
                (func2 (lambda (a b) (* a b))))
            (lambda (func)
              (case func
                ((func1) func1)
                ((func2) func2)
                (else (error "Bad call to foo-pkg:" func))))))

        (define func1 (foo-pkg 'func1))
        ;;;
        ;;; func2 isn't used very often, so we won't provide it
        ;;; by default
        ;;;

Using a closure like this restricts what the user of a
"package" can do, which is both good and bad.  If the author of
a package didn't provide good enough hooks into the closure,
then the user will be forced to modify the source to get what
she needs.



Sun, 20 Oct 1996 09:40:20 GMT  
 What exactly is a package?

   Well, I have a rough idea from comments in this group, and from
   my meager understanding of Common Lisp (which I try to avoid).

           A package is, or can be, a separate compilation unit
           with a well defined, exported interface.  Other
           packages may import names from the package (using the
           syntax "(import pkg:name)" in CL), to simplify
           references, but the name "pkg:name" can be used as well.

   Jaffer's slib uses the convention that all symbols defined by a
   library file have the "package" name as a prefix, but this has
   no real weight, since all the names end up in the top-level
   environment anyway.

You are right.  It is lightweight.  It doesn't require dispatching to
find functions and even works for top-level variables a package uses
and might wish to export.  As for "all the names end up in the
top-level environment" this is of no importance since the names are
distinguished from each other (by the prefix) and will not conflict.

   So why don't we just use closures in scheme with a dispatch
   function:

           (load "bar-pkg")
           (define foo-pkg
             (let ((helper (bar-pkg 'barfunc))
                   (func1 (lambda (n) (helper n 1)))
                   (func2 (lambda (a b) (* a b))))
               (lambda (func)
                 (case func
                   ((func1) func1)
                   ((func2) func2)
                   (else (error "Bad call to foo-pkg:" func))))))

           (define func1 (foo-pkg 'func1))
           ;;;
           ;;; func2 isn't used very often, so we won't provide it
           ;;; by default
           ;;;

   Using a closure like this restricts what the user of a
   "package" can do, which is both good and bad.  If the author of
   a package didn't provide good enough hooks into the closure,
   then the user will be forced to modify the source to get what
   she needs.

You just gave one reason why I don't do it that way in SLIB.  Common
lisp provides a method to get at internal symbols (with the
prefix::name syntax); in SLIB it is just prefix:name.  A library is
not very useful if people have to go in and change code to use it.
Having interal functions available allows those packages to be
extended without modifying the original package code.

Another practical reason is it makes it difficult to trace internal
functions or internal calls of external functions.  I get sent a lot
of buggy code and I don't want to have to jump through hoops to test
and fix it.

This is the second post I have seen worried about "polluting" the
top-level namespace.  Perhaps we are seeing the beginnings of "Green
Scheme Programming".  We could rate programs for ecological value by
how few symbols they define.  :^)



Wed, 23 Oct 1996 01:00:10 GMT  
 What exactly is a package?
   [...]

   You just gave one reason why I don't do it that way in SLIB.  Common
   lisp provides a method to get at internal symbols (with the
   prefix::name syntax); in SLIB it is just prefix:name.  A library is
   not very useful if people have to go in and change code to use it.
   Having interal functions available allows those packages to be
   extended without modifying the original package code.

   [...]

   This is the second post I have seen worried about "polluting" the
   top-level namespace.  Perhaps we are seeing the beginnings of "Green
   Scheme Programming".  We could rate programs for ecological value by
   how few symbols they define.  :^)

I agree that slib's mechanism is effective and inexpensive.  My only
reservation towards it is, as a package writer, I'm constantly forced
to type that annoying prefix.

What might help is a "packager" tool that you could run your code
through to prepare it for inclusion in slib.  You could provide it the
list of definitions to be exported, and it could then generate
the prefix on all defined symbols plus a final set of defines for the
"exported" names.

As an added bonus, it could allow the "meta-source" to include CL-style
doc strings in the definitions, then generate a texinfo doc file at
the same time.

--
// Kaelin Colclasure ---------------------------------------------------------

// Voice: (314)567-8463                      717 Office Parkway
//   Fax: (314)432-5391                      St. Louis, MO 63141



Wed, 23 Oct 1996 14:11:49 GMT  
 What exactly is a package?

Quote:
Aubrey Jaffer writes:

        This is the second post I have seen worried about "polluting" the
        top-level namespace.  Perhaps we are seeing the beginnings of "Green
        Scheme Programming".  We could rate programs for ecological value by
        how few symbols they define.  :^)

I suppose that the concerns about polluting the top-level namespace
are from programmers experienced with large collaborative programming
projects occuring over relatively long periods of time and that these
are also the programmers who see the need for a real module system for
Scheme.

I tend to code modules (and everything else) systolically; that is,
the size of my code grows for awhile and then gets redesigned and
becomes small again.  I usually start out with prototype implementations.
I can only follow these practices in a collaborative environment if I
have some way of isolating module interfaces, which I must not
incompatibly change, from the module implementations which I may
change at will.

I wish that Scheme was a better team player.

_Greg

J. Greg Davidson        Institute for Software Research and Development
+1 (619) 452-8059       6231 Branting Street  San Diego, CA  92122  USA



        *****************************************************
        *   Member of the League for Programming Freedom.   *

        *****************************************************



Fri, 25 Oct 1996 17:13:48 GMT  
 What exactly is a package?


      [...]

      You just gave one reason why I don't do it that way in SLIB.  Common
      lisp provides a method to get at internal symbols (with the
      prefix::name syntax); in SLIB it is just prefix:name.  A library is
      not very useful if people have to go in and change code to use it.
      Having interal functions available allows those packages to be
      extended without modifying the original package code.

   I agree that slib's mechanism is effective and inexpensive.  My only
   reservation towards it is, as a package writer, I'm constantly forced
   to type that annoying prefix.

   What might help is a "packager" tool that you could run your code
   through to prepare it for inclusion in slib.  You could provide it the
   list of definitions to be exported, and it could then generate
   the prefix on all defined symbols plus a final set of defines for the
   "exported" names.

   As an added bonus, it could allow the "meta-source" to include CL-style
   doc strings in the definitions, then generate a texinfo doc file at
   the same time.

Those are excellent suggestions.  Anyone willing to write this?
pprint-filter-file (require 'pprint-file) should make this fairly
easy.



Fri, 25 Oct 1996 20:34:43 GMT  
 What exactly is a package?

   Date: Mon, 09 May 94 01:58:25 -0700

   Aubrey Jaffer writes:

           This is the second post I have seen worried about "polluting" the
           top-level namespace.  Perhaps we are seeing the beginnings of "Green
           Scheme Programming".  We could rate programs for ecological value by
           how few symbols they define.  :^)

   I suppose that the concerns about polluting the top-level namespace
   are from programmers experienced with large collaborative programming
   projects occuring over relatively long periods of time and that these
   are also the programmers who see the need for a real module system for
   Scheme.

One might suppose that but I don't think it is justified.  I have been
in long-term collaborative programming efforts in scheme and the
prefix:name convention has averted collisions.  As for the "need for a
real module system", the actual system posted last month could have
been implemented using the prefix:name convention (and defmacro).
However, the author of that system felt that doing so was somehow
lacking because of the top level namespace use.  So we are back to the
ineffable namespace pollution.

There are a countably infinite number of scheme symbols available.  I
am not worried about running out any time soon.  If someone can tell
me what tangible benefits a "real module system" offers that I can't
do with the prefix:name convention I would like to hear it.

   I wish that Scheme was a better team player.

I think SLIB shows that Scheme can be a team player.



Sat, 26 Oct 1996 02:24:27 GMT  
 What exactly is a package?

Quote:
>   You just gave one reason why I don't do it that way in SLIB.  Common
>   lisp provides a method to get at internal symbols (with the
>   prefix::name syntax); in SLIB it is just prefix:name.  A library is
>   not very useful if people have to go in and change code to use it.
>   Having interal functions available allows those packages to be
>   extended without modifying the original package code.

But the flat namespace of SLIB can lead to lazyness on the part
of package implementors.  If anybody can get at any parameter,
then there is no need to "worry" about what should be tunable
in the library and what is just a private state variable.  By
writing a package as an enclosure with a dispatch routine, the
author _knows_ what is going on, and doesn't have to worry
about the user mucking things up (it also makes it easier for
the compiler to optimize local variable accesses, and internal
function calls).  Closure-based package do, on the other hand,
require more thought on the part of the implementor:  she has
to make sure that the dispatch routine covers all the possible
bases.

The only real problem with using closures is that there is no
way to get to internal variables the way we can with internal
functions.  While

        (define foo (bar-pkg 'foo))

will define foo to be a procedure that my programs can just
call, with no loss of efficiency,

        (define baz (bar-pkg 'baz))

will only set baz to be the current value of the variable
bar-pkg:baz.  If the internal value changes, it's not reflected
in my externalized instance.

- David



Sat, 26 Oct 1996 09:31:22 GMT  
 What exactly is a package?

   >   You just gave one reason why I don't do it that way in SLIB.  Common
   >   lisp provides a method to get at internal symbols (with the
   >   prefix::name syntax); in SLIB it is just prefix:name.  A library is
   >   not very useful if people have to go in and change code to use it.
   >   Having interal functions available allows those packages to be
   >   extended without modifying the original package code.

   But the flat namespace of SLIB can lead to lazyness on the part
   of package implementors.

But does it lead to problems?  SLIB has been around for a couple of
years; I think this assertion can be put the test.  

   If anybody can get at any parameter,
   then there is no need to "worry" about what should be tunable
   in the library and what is just a private state variable.  By
   writing a package as an enclosure with a dispatch routine, the
   author _knows_ what is going on, and doesn't have to worry
   about the user mucking things up.

By DOCUMENTING a package not only the author, but also the user knows
what is going on.  The packages in SLIB are documented.

   (it also makes it easier for
   the compiler to optimize local variable accesses, and internal
   function calls)

It takes a pretty sophisticated compiler to do the analysis and
transform a bunch of internal defines whose values are returnable into
statically linked routines.  Hobbit can't do it; I don't know about
other compilers.



Mon, 28 Oct 1996 05:31:01 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Packaging a Namespace--what am I doing wrong?

2. I am not deaf, but am I mute?

3. what exactly means asm370?

4. How does BlockClosures exactly work ...

5. How Does Super Work Exactly?

6. What EXACTLY is Design Patterns -- HELP --

7. BindList: What does it exactly?

8. When Exactly is Form Inserted?

9. I want a loop to run for EXACTLY 16 hours

10. not exactly a 3-key keyboard ...

11. NI_SPY: How exactly does NI spy work?

12. how does exactly data socket work?

 

 
Powered by phpBB® Forum Software