Re: ilisp-fallback-package is in the wrong format for lisp-buffer-package

Bob Rogers wrote:
>    I see three problems here:
> 
>    1.  The first problem is that the package default doesn't work.  The
> immediate culprit seems to be that ilisp-check-package-advanced returns
> ":common-lisp-user" here, but if "(in-package :common-lisp-user)" were
> present in the buffer instead, it would return "COMMON-LISP-USER", since
> that's what PACKAGE-NAME in the Lisp returns, and that's the form the
> rest of ILISP expects from lisp-buffer-package.
Mea culpa. I changed this in line with some stuff to do with modern 
mode ACL issues.

>    The initialization of ilisp-fallback-package to ":common-lisp-user"
> in defdialect common-lisp would seem to be at fault.  However, the
> obvious change to the source at this point would break case-sensitive
> Lisps.
Yes. The original system had :common-lisp-user set to 
"\"COMMON-LISP-USER\"" which, as you point out, was not working with 
case-senisitive lisps. However, it seem the fix -- changing "CL" -> 
:cl -- make the situation worse rather than better.

> The most robust thing might be to have the default be the string
> "(in-package :common-lisp-user)" and then run THAT through the
> ilisp-check-package-advanced magic; this amounts to a change in the
> semantics of ilisp-fallback-package.
I broke it so I'll try and fix it.

>    2.  A second, related problem is this incongruous defvar at the top
> of the ilisp-snd.el file:
> 
>     (defvar *ILISP-default-package* :common-lisp-user)
> ...
>    As an aside, this immediate problem could be fixed by changing
> ilisp-in-package-command to "(in-package %S)", since that allows both
> emacs string and symbol values to be parsed as such in the Lisp.  But
> this fix is harder to generalize for ilisp-fallback-package, since the
> result is used in more places.  And it doesn't address the code
> duplication issue.
I think fixing the default package system is the right thing to do.

>    3.  Finally, we get to the fact that ilisp-arglist-message-lisp-space
> is not very robust when lisp-buffer-package returns a bad package.  But,
> on reflection, this is not surprising.  lisp-buffer-package tries very
> hard to return something valid, despite the fact that the function
> documentation states, "If there is none, return NIL."  So, presumably
> the return convention has been changed, and
> ilisp-arglist-message-lisp-space has come to rely on that.  Better to
> fix the underlying problem (and the documentation), then.
Sure.

>    Anyone else want to have a go at this?
Thanks for this. I will try. Any help you can give me would be 
appreciated.

:)w




**********************************************************************
This email and its attachments are intended for the above 
named only and may be confidential.  If they have come to 
you in error, you must take no action based on them, nor 
must you copy or show them to anyone; please reply to this 
email and highlight the error.
Security Warning: Please note that this email has been 
created in the knowledge that the internet email is not a 
100% secure communications medium.  We advise that you 
understand and observe this lack of security when emailing us.
Viruses:  Although we have taken steps to ensure that this 
email and attachments are free from any virus, we advise 
that in keeping with good computing practice the recipient 
should ensure they are actually virus free.
If you have received this email in error please notify:
[email protected]
**********************************************************************



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf