Re: packages revisited

Hi Tim!

I'm pretty sure that things like parsing
dates and times are *not* the sort of thing
you want to add to the general CL reader.

I see no reason for not doing that. Tokens
like 2009.04.04:23:59:59 are senseless in CL,
why don't give them a sense? Of course, parsing
any hairy date representation like Monday,14,205 BC
is out of the scope of general reader, but having
a simple default seem to be reasonable. I'm short
in a resources now, but I really need to input and
output dates to/from SQL for my current work.
Frankly, I see no difference between integer
and a date. Both are primitive and practically
important data types and I see no reason why
there is a syntax for integers and there is no
syntax for date/time in a high-level language.

Meanwhile, I've finally came to conclusion that
it is impossible for me to understand True Lispers
and vice versa. I even have admitted that and this
does not hurt me anymore. So let me avoid further
debate :)

My answer to that is that, if there are clashes,
I always want to end up in the debugger (or somewhere
equivalent), because it always indicates a problem
with the code which I will need to think about.

In SQL, you have error only when you trying to use
clashing symbols, but not at the time when the conflict
becomes possible. When you join two tables with the same
fields, you may have no clash report. E.g.

create table foo (id int, name char(1));
create table bar (id int, short_name char(5));

select name from foo,bar;

In a last statement, between "select" and "from"
we have a temporarily merged namespace with all
fields from foo and bar.

You can refer to 'name' as it does not clash.
But you can't refer to id w/o qualifier:

select id from foo,bar /* error */

You can do

select foo.id from foo.bar /* no error */

This behavior is practical, I'm using it for
14 years in SQL and I see no contradiction with any
aspect of CL standard which would prevent using it
in CL.

The only thing we need is to allow multiple arguments
for in-package form:

(in-package :a-package :cl :other-library-package)

When reader meets unqualified symbol name, it looks for
it in every package we are "in". If there is an internal
symbol with that name in :a-package, or external symbol
with that name in &rest, and there is only one symbol
of that kind, it is used.
If there is no such symbol, it is interned to :a-package
Otherwise (more than one), error occurs.

So, for all clashing symbols, error would occur at the
time symbol name is about to be interned, not at the
time when in-package form is evaluated.

Advantages:
- if you don't use symbol a-package::foo clashing
with cl:foo, you need not care if it clashes.
Just use non-clashing a-package::bar and cl:quux
- if you use foo, you get to debugger as you wish
- a-package need not import symbols from cl-user.
So, a-package can be kept very small.

For a practical use, IDEs need to be changed a bit
too. Otherwise symbol completion won't work. So, while
I am able to redefine in-package form as I need, I
won't do that as I use some closed-source
IDE I'm unable to modify.

merge-packages-and-reexport suffice, it
requires no change to CL and it doesn't
harm completion.

Pascal uses similar clash resolution policy, but
clashing symbols do not report a error. First of
clashing symbols is used instead. This policy is
sometimes reasonable too. In fact, I'm using it
most frequently in merge-packages-and-reexport but
it is even harder to admit for True Lispers.

Also I've developed a tool which intercepts
attempts to intern one of listed symbol names to
a wrong package (other than package listed for that
symbol name). This tool is implementation-depended,
but it helped me a lot to refactor my code and
reorganize my packages layout.

I have already written about all that before and
noone understood me. I have no resources for proving
that this is more convinient than CL standard package
behaviour. I just use my merge-packages-and-reexport
in my code rather massively and I found that this is
really convinient and useful. Much more convinient
than other package handling techniques I've tried
before or that I read about. I'm not going to appeal
to anyone to follow me, but I will use this approach
until I stop using CL at all.

.

Relevant Pages

  • Re: Shipping in eBay
    ... >>> a good reason to not do so. ... >>> away from my job, kids, wife, etc. to mail this package to another ... No access to USPS? ... transaction online and the postman will pick up your package at your ...
    (rec.models.scale)
  • Re: CRIT: Proposed opening of WIP
    ... some people might get that upon reading about the window. ... lady in the nursing home battling the dragon who set the fire!. ... OP for the reader to not be sure which old woman is which -- whether the ... who gave her the package or the one she's taking the package to? ...
    (rec.arts.sf.composition)
  • Re: packages, load paths and environment variables
    ... There is one reason. ... you only need the package definition of the first (you only ... Therefore when you have CL sources with crossed dependencies, ... and add a in the sources (implementation module) of A. ...
    (comp.lang.lisp)
  • Re: OCD programmers and backwards compatibility :-).
    ... upgrading rpms forever with individual packages being released, ... I can tell the only reason was a bunch of OCD programmers who broke ... stop checking in non-backward compatible changes without fantastically ... the foobar package play nice with the rest of the release. ...
    (Fedora)
  • Re: Finding installed package files
    ... >>Well I really dislike that the Fedora guys renamed the package. ... the rename is done for a very good reason - changes that make it ... the reason I wanted to replace it was ... the Linux side of my box after using OOo for over a year with XP. ...
    (alt.os.linux.redhat)