Re: package frenzy

Joris Bleys wrote: 
Hi Pascal,

Don't I know you from somewhere? ;) 

That must be a coincidence. ;)

Maybe you want (intern string :exporting-package) instead of read-line?

This might indeed be the function I'm looking for. It seems more elegant than setting *package* by hand. Oops, just read your reply :p, so I might look very stupid now :). 

Maybe we both do. ;)

However, doing so requires the programmer to be realy careful when employing packages. I'd like to think that calling internal functions should automagically change the *package* to the package it was internal in, but I guess there are good reasons, which I don't yet fully (and might never :)) understand, for not doing so. 

It's not that hard to understand. You have to get two things straight:

- When the Lisp reader reads in your source code (the original source code, not what you want to do at runtime), it uses *package* to determine the package of the symbols that are part of your source code. That's the sole purpose of *package*. You can reuse that functionality for your own stuff at runtime, but you have to imitate that behavior (so bind *package* correctly, or use INTERN with a second parameter appropriately). Read time and runtime are just two different times for a Lisp program, and you just have to keep them separated in your head.

- It might have been possible to automagically rebind *package*, whenever a function is called, to the home package of the symbol whose symbol-function is that function at runtime. This would incur a serious overhead though, and you would have to care about obvious and not so obvious corner cases. For example, what happens when you call an anonymous function? What if you change the fdefinition of a function at runtime? etc.


Pascal

--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
.

Relevant Pages

  • Re: use-package & name conflict: why they are not deferred?
    ... if current package is a home package for one of conflicting ... of some Lisp program. ... I don't think there is that much 'modern' to C++ and Java (the language). ... (append (required-args d-a) ...
    (comp.lang.lisp)
  • modules vs. packages
    ... > module system of the underlying lisp. ... Common Lisp does have a trivial feature called modules. ... is that it has a unique name (with respect to its home package). ... the system version control and release and patching features. ...
    (comp.lang.lisp)
  • Re: why cl packages are hard to use ?
    ... Yeah, if Lisp used dumb strings for naming things, that would stack ... the deck in the favor of related dumb hacks like modules, ... Why is it so important that the reader do the work? ... because *package* is a global resource ...
    (comp.lang.lisp)
  • Re: Symbols - when are they garbage collected?
    ... home package is often considered to be interning it (certainly it is ... I agree that the CL function INTERN does not do this. ... string as its primary input, ... among Lisp practitioners. ...
    (comp.lang.lisp)
  • Re: Predicate for lexical bindings
    ... I assume you mean that you have started up an interactive Lisp ... lower level of parse, sees the word "let" which sees there already ... but there's no symbol by that name (in the current package) so ... so it puts NIL into the CDR of that same CONS cell to ...
    (comp.lang.lisp)