In article <·····················@anihccam.cs.nyu.edu> ·······@anihccam.cs.nyu.edu (Marco Antoniotti) writes:
>Which brings to my mind the following extension to 'defpackage' (after
>all I write from an ADA stronghold :) ).
[suggestion that DEFPACKAGE's :EXPORT option allow variable/function types
to be associated with symbols being exported.]
It seems out of place to put this information in DEFPACKAGE, as the type
information is completely orthogonal to what package the symbol is in or
whether it's exported. A function would retain its type signature even if
you decided not to export it, so the declaration shouldn't be placed in the
export declaration.
Remember, packages are only repositories of symbols, not variables,
functions, or anything else that happens to be named using symbols. And
symbols's properties are independent of their registry in packages.
In article <··················@telecaster.think.com> ······@think.com (Barry Margolin) writes:
Path: slinky.cs.nyu.edu!cmcl2!yale.edu!think.com!think.com!barmar
From: ······@think.com (Barry Margolin)
[suggestion that DEFPACKAGE's :EXPORT option allow variable/function types
to be associated with symbols being exported.]
It seems out of place to put this information in DEFPACKAGE, as the type
information is completely orthogonal to what package the symbol is in or
whether it's exported. A function would retain its type signature even if
you decided not to export it, so the declaration shouldn't be placed in the
export declaration.
Remember, packages are only repositories of symbols, not variables,
functions, or anything else that happens to be named using symbols. And
symbols's properties are independent of their registry in packages.
This is the same point that Brad Miller made in private to me. I also
answered in private and lost my message :(
I know that the status of packages in CL is just that of "symbol
repository"; yet the argument that each of them retains the "type"
and/or "function signature", assumes the so called "imperialistic lisp
world mentality" (ILW) :)
Suppose you want to compile a file which contains only references to
symbols in two (n) packages. Suppose also that, following CLtL2, you
have your nice 'defpackages' sitting pretty all alone. Suppose also
that the "package bodies" where the signatures are actually
declared/declaimed/defined (once again, I come from an ADA stronghold)
are "pretty big". Given the ILW, you imply that the only way to let
the compiler know about the type information is to load the "pretty
big" package bodies in your lisp image.
My proposal would simply give you a way to avoid this and at the same
time would buy you two things plus a third (always assuming that such
"extra documentation" in the :export clause, could be ignored by an
implementation).
1 - better documentation of a package interface (just pure and simple
documentation in Lisp readable format).
2 - ability to feed a compiler some type information without having to
load huge amounts of code.
3 - CL is *extendable*: hey, let's just extend it! Let's show off all
its power! (Try to do the same with C++ or ADA) :)
A little extended form of my proposal could be:
{export-slot} ::= (:export {symbol-spec}*)
{symbol-spec} ::= {symbol-name} |
({symbol-name} {symbol-type-spec}*)
{symbol-type-spec} ::= type-specifier | ; The symbol names a type
(type {type-spec}) |
(function {arglist-spec} &rest {type-specs}) |
...
I am obviously waving my hands over a lot of nasty issues, but I think
that the two (three) reasons are worth trying to incorporate the
feature.
Happy Lisping
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht