Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.lang.lisp Subject: Re: Common Lisp Package System Considered Harmful Message-ID: Date: 24 Oct 90 09:10:43 GMT References: <271E0D40.451E@wilbur.coyote.trw.com> <388@shrike.AUSTIN.LOCKHEED.COM> <3620@skye.ed.ac Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 131 In-Reply-To: jeff@aiai.ed.ac.uk's message of 23 Oct 90 18:17:55 GMT Nntp-Posting-Host: cdollin.hpl.hp.com In response to my: >(c) packageing seems to be done in the wrong place - as part of the lexical >and syntactic analysis, not in the compiler [*2]. >[*2] Or interpreter. For these purposes the difference is irrelevant. Jeff posts quite a lot, from which I extract below. Packages are handled by the reader. Thus they apply to data as well as code. This approach has some disadvantages (see one of my earlier articles for an example), but it also has advantages. I have found it inconvenient that the pacakging system applies to data. I have resorted to using keywords rather than quoted "plain" symbols in several places just to ensure that packaging doesn't confuse me! [I've not seen Jeff's earlier article. Jeff, could you mail it to me?] There are several ways in which data structures can end up being interpreted as code: I must declare my colours. In general I don't like to treat data as code. This bias will show up below. 1. A symbol that has a global function definition can be used as a function. I would claim that the symbol "should" have been converted to its functional value at the point it was passed. That conversion must, of course, respect packaging. 2. A list, symbol, or other object can be given to EVAL. This would require that sufficient information be given to EVAL for it to resolve packaging in the same way that the compiler (or interpreter) would. That seems reasonable to me. 3. A list, symbol, or other object can result from macro expansion. I don't think that matters; if packaging is a property of the compiler, then macros would have to respect it; they might have to embed additional package *syntax* in their result, but I don't think this is a big deal. Let's look at the first example. If the package information were not part of the symbol, and the symbol were given as a function to MAPCAR, MAPCAR would have no way to determine which package held the function definition. I've hand-waved over that one above. I think if one were to take compiler packaging seriously, then the symbol would have been converted at an earlier appropriate moment. A more serious problem is that the symbol gives you a layer of indirection; between passing the symbol in, and applying it with MAPCAR (strictly, I suppose, FUNCALL or APPLY), the global binding might change. If the "old" value has been captured, but the new one intended, then I'm stuffed. A solution is to allow *variables* as function-objects, and to pass the variable corresponding to the symbol as argument; the package information would be resolved at this point. [In this model, I distinguish between a *symbol*, which is just an interesting data-object with no value, package, or function cells, and a *variable*, which has one value [*1] and possibly name and package cells]. Similar problems occur if a list containing function names is given to EVAL or returned as the result of macro expansion. Not if EVAL has the information that allows packages to be resolved passed in as an additional argument. There are several solutions that might be applied to these problems: S-1. Eliminate the offending parts of the language. S-2. Adopt a convention such as: always use the current package. S-3. Have the user explicitly specify the package. S-4. Invent a zowie new mechanism that makes (almost) everything work as we (ought to) expect. I suspect Jeff would say I've picked S-4. Chopping context ... ... That is, I should be able to write a macro like this one: (defmacro mac (x) `(some-package:some-function ,x)) or one like this: (defmacro mac (x) `(some-function ,x)) Well, I'd write them the same way! But the reader item "package:id" would be translated as (eg) "(inpackage package id)", where "inpackage" is a special form which resolves to the variable called "id" in the package "package". S-3 is often used for EVAL: give EVAL an extra "environment" argument. It would be a pain to use it for (1), giving an extra argument to MAPCAR and all the rest. Moreover, it's hard to see how it would work for (3). I've already indicated my solution for MAPCAR; I agree with Jeff that insisting that all things that take functional arguments that might be symbols (or variables) would be a right pain. So that leaves S-4. It is clearly the best solution, but rather difficult to devise. The Scheme world will eventually do it for modules and macros in Scheme. Scheme won't support symbols as functions, and it won't have EVAL. I think I've sketched an interim solution which would work as effectively as pacakges do now, and gives what I regard as several advantages: eg, data is immune from the package system (so [modulo UNINTERN and its ilk] there's only one symbol with a given printname; one can write macros which do package manipulation, such as "(in-a-package Package Form*)" which compiles the Form's in the context of that package. I'm not seriously suggesting that it's a candidate to go into CL; it's far too late for that. But I think that it demonstrates that there is a rational alternative to read-time packaging. Scheme, then, will offer a reasonable set of solutions. But (a) some regard it as a high price to pay, and (b) the Common Lisp solution, imperfect as it is, is available now and, moreover, was available back when people were writing whatever applications we're using now. Well, I agree with that. I just wish the rational reconstruction was what we'd been given in the first place! -- Jeff [Hey, Jeff, I didn't mention [omitted] once!] -- Regards, Kers. | "You're better off not dreaming of the things to come; Caravan: | Dreams are always ending far too soon."