Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.lisp
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Package documentation strings.
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Pascal J. Bourguignon  
View profile  
 More options Jan 16 2011, 4:07 pm
Newsgroups: comp.lang.lisp
From: "Pascal J. Bourguignon" <p...@informatimago.com>
Date: Sun, 16 Jan 2011 22:07:03 +0100
Local: Sun, Jan 16 2011 4:07 pm
Subject: Re: Package documentation strings.
Print | View thread | Show original | Report this message | Find messages by this author

RG <rNOSPA...@flownet.com> writes:
> In article <m2lj2ky56e....@host-10-5-17-33.vaih.selfnet.de>,
>  Edmunds Cers <edmu...@laivas.lv> wrote:

>> RG <rNOSPA...@flownet.com> writes:

>> > In article <87aaj07o4s....@kuiper.lan.informatimago.com>,
>> >  "Pascal J. Bourguignon" <p...@informatimago.com> wrote:

>> >> What problem does "org.tfeb.xml.parser" offer?

>> > Verbosity.

>> You are free to add a nickname of your liking:

>> (rename-package
>>  'org.tfeb.xml.parser
>>  'org.tfeb.xml.parser
>>  (cons 'parser (package-nicknames 'org.tfeb.xml.parser)))

> If you're willing to do that then you don't need uniqueness at all.

> (load-something-in-package-foo)
> (rename-package 'foo 'my-foo1)
> (load-something-else-into-package-foo)
> (rename-package 'foo 'my-foo2)

> That's even simpler.

Actually, this is too verbose.  It also has the problem that you can do
that only in the ultimate integration.  If you publish your code, you
cannot be sure that nobody won't want to integrate it with another body
of code that already use those nicknames.

There should be no nickname pre-defined on published packages.

Long package names are not a problem in practice, because either you
mention them once in the defpackage :use clause, or you use them to
qualify symbols only a very small number of occurences in a source file.

If you observe the opposite, then you have another problem: your cross
package dependencies are too wide.  Solve this problem instead.

>> > Also, it doesn't even guarantee uniqueness because domains can change
>> > ownership.

This is nto a problem either, because:
1- this doesn't occur often,
2- you can easily distribute a different library with other package
   names.

Point 2 is even what you should do if you plan to distribute discrete
versions of your libraries, like ALEXANDRIA.0.DEV.

>> It also doesn't exclude malice. Guess we have to choose between strong
>> cryptography and nothing, right?

> That's a little extreme.  GUIDs are probably sufficient.

    (21EC2020-3AEA-1069-A2DD-08002B30309D:WITH-GENSYMS
       (wall door window roof) ...)

    (COM.INFORMATIMAGO.COMMON-LISP.CESARUM.UTILITY:WITH-GENSYMS
       (wall door window roof) ...)

Granted, GUIDs may be shorter, but I still prefer the reversed domain
name.

> But what one really ought to do IMHO is to pop up a level and ask
> whether a mechanism intended to provide read-print consistency for
> symbols is really the right tool for the job of modularizing code.

It won't be bad to think about it, but IMO packages solve 90% of the
modularization needs, and if you want to solve the modularization
problem, in the scope of Internet and open software, you will find that
you have to solve this same problem.  

There's already the notion of relative packages (which requires reader
extensions).  I think packages + relative packages cover 100% of what
solution hypothetical modules could solve.

We could introduce modules, and optionally qualify packages with a
module name.  This would only change the last dot by a colon:

    (COM.INFORMATIMAGO.COMMON-LISP.CESARUM:UTILITY:WITH-GENSYMS
       (wall door window roof) ...)

It's simplier to use relative package names, when the facility is/will
be available.

    (COM.INFORMATIMAGO.COMMON-LISP.CESARUM.UTILITY:WITH-GENSYMS
       (wall door window roof) ...)

is future-compatible with them.

--
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google