search

lmj / lparallel

Parallelism for Common Lisp
http://lparallel.org
BSD 3-Clause "New" or "Revised" License
243 stars 29 forks source link

loop keywords polluting cl-user package #20

Closed mwjohnson0 closed 9 years ago

mwjohnson0 commented 9 years ago

When invoking loop in src/package.lisp, the loop keywords (e.g. 'for, 'in, 'collect, etc. ) are interned into the CL-USER package. This is a new behaviour since the patch "convert to more common `loop' style" from May 7. Prior to this patch, loop was invoked with keywords from the keyword package (e.g. :for, :in, etc).

Putting symbols into CL-USER causes a problem for our system build as we use lparallel, but also use iterate, and want to be able to import iterate's keywords (for, in, collect) into CL-USER.

It is only the use of loop in CL-USER, which happens only in src/package.lisp that causes this problem for us. I wonder if it would be possible to use symbols from the keyword package in this one situation?

lmj commented 9 years ago

I don't mind making the change -- I made a similar change in issue #5 -- but as I mentioned there, remember that implementations are allowed to add anything to cl-user. Tomorrow your favorite implementation could intern for into cl-user.

In the meantime, the problem goes away if you load and :use iterate before loading lparallel, right?

mwjohnson0 commented 9 years ago

Well, you make a fair point about not being allowed to rely on CL-USER to be hygenic. If I am reading the HYPER-SPEC correctly (http://www.lispworks.com/documentation/HyperSpec/Body/11_abb.htm), I think it is consistent with your comment.

It is also true that if I (use-package :iter) prior to compiling lparallel, this problem would be avoided. I'm sure it would be possible to modify out asdf system build to do that, though for now its easy enough maintaining a local patch to lparallel.

lmj commented 9 years ago

As a matter of principle lparallel should pollute as little as possible, so I think your suggested change is a good one. I was just making the side point that, in the long term, it is better to move away from assuming a clean cl-user because implementations can "pollute" it.

Earlier I said an implementation could intern for into cl-user, but that is suggestive of a present symbol, whereas the symbols added to cl-user will probably be inherited, e.g. (package-use-list :cl-user) for SBCL is (#<PACKAGE "SB-PROFILE"> #<PACKAGE "SB-GRAY"> #<PACKAGE "SB-EXT"> #<PACKAGE "SB-DEBUG"> #<PACKAGE "SB-ALIEN"> #<PACKAGE "COMMON-LISP">).