[alexandria-devel] COPY-FILE conflict.
Good day Edi and alexandria-devel, it appears that since June Alexandria exports COPY-FILE, as well as a bunch of other file-related primitives. Is the resulting loss of simultaneous :use-ability of cl-fad and alexandria being regarded as something undesirable by the project maintainers? regards, Samium Gromoff
Samium Gromoff <_deepfire@feelingofgreen.ru> writes:
Good day Edi and alexandria-devel,
it appears that since June Alexandria exports COPY-FILE, as well as a bunch of other file-related primitives.
Is the resulting loss of simultaneous :use-ability of cl-fad and alexandria being regarded as something undesirable by the project maintainers?
I wouldn't mind seeing the stuff in io.lisp moving from Alexandria to CL-Fad. It'd keep Alexandria stay more focused. -T.
it appears that since June Alexandria exports COPY-FILE, as well as a bunch of other file-related primitives.
Is the resulting loss of simultaneous :use-ability of cl-fad and alexandria being regarded as something undesirable by the project maintainers?
i have a lot of :shadowing-import-from in my projects due to such clashes, so it i don't consider it unusual.
I wouldn't mind seeing the stuff in io.lisp moving from Alexandria to CL-Fad. It'd keep Alexandria stay more focused.
i would, although i'm not completly against it. my concerns are: - there's no public DVCS repo for cl-fad and therefore it's more cumbersome to make changes to it. - the interface of the two versions of copy-stream represent different approaches (&optional/&key; the impl in cl-fad depends on sb-executable:copy-stream, which is arguably exported at all from there). - imho, these utilities fall in the "often needed basic stuff" category (<100 lines with comments) but on the other hand, the copy-stream in alexandria wasn't tested on too many lisps (at least by me)... so, all in all, i'd prefer to keep io.lisp in alexandria, but it's only one vote. -- attila
"Attila Lendvai" <attila.lendvai@gmail.com> writes:
- imho, these utilities fall in the "often needed basic stuff" category (<100 lines with comments)
Indeed, they do. It is, however, my opinion that such "basic stuff" should be put into the most specific project they're appropriate for. I think we should try to make Alexandria's scope as small as possible, lest it becomes a impenetrable mesh like CLOCC is. The broader its scope the harder it'll be to make Alexandria high-quality. I'd like to hear Edi's opinion about the stuff in io.lisp[*], and whether he considers it appropriate for CL-Fad's "thin library" scope. -T. [*] http://common-lisp.net/project/alexandria/darcs/alexandria/io.lisp
On Sat, Nov 22, 2008 at 4:58 PM, Tobias C. Rittweiler <tcr@freebits.de> wrote:
[*] http://common-lisp.net/project/alexandria/darcs/alexandria/io.lisp
FWIW, here's my first impression (I haven't really been paying attention to io.lisp): WITH-INPUT-FROM-FILE, WITH-OUTPUT-TO-FILE: don't like. :DIRECTION :INPUT / :OUTPUT is just as good, saved keypresses not worth the opacity. (This is something a lot of people end up macroexpanding, I think, because it is not obvious that there isn't additional magic going on.) READ-FILE-INTO-STRING, WRITE-STRING-INTO-FILE: ok. -INTO has the MAP-INTO like destructive connoctation for me, but no biggie. COPY-FILE, COPY-STREAM: ok. (Don't understand the FORCE-OUTPUT in COPY-STREAM though: FINISH-OUTPUT or nothing would make sense to me, but the weak guarantee of FORCE-OUTPUT doesn't.) (Apropos, I would suggest that CL-FAD depending on SB-EXECUTABLE:COPY-STREAM is not a good thing. (1) There is no magic there. (2) SB-EXECUTABLE is the winner of the Contrib Module Most Likely To Go Away price. (3) Even if it doesn't go avay, COPY-STREAM is the winner of the Symbol Most Likely To Be Unexported price.) Cheers, -- Nikodemus
On Sun, Nov 23, 2008 at 11:12 AM, Nikodemus Siivola <nikodemus@random-state.net> wrote:
On Sat, Nov 22, 2008 at 4:58 PM, Tobias C. Rittweiler <tcr@freebits.de> wrote:
[*] http://common-lisp.net/project/alexandria/darcs/alexandria/io.lisp
READ-FILE-INTO-STRING, WRITE-STRING-INTO-FILE: ok. -INTO has the MAP-INTO like destructive connoctation for me, but no biggie.
The docstrings are out of whack, though! Cheers, -- ns
WITH-INPUT-FROM-FILE, WITH-OUTPUT-TO-FILE: don't like. :DIRECTION :INPUT / :OUTPUT is just as good, saved keypresses not worth the opacity. (This is something a lot of people end up macroexpanding, I think, because it is not obvious that there isn't additional magic going on.)
fwiw, since then i've extended them a little to help portability by treating :exeternal-format nil as the default external format.
COPY-FILE, COPY-STREAM: ok. (Don't understand the FORCE-OUTPUT in COPY-STREAM though: FINISH-OUTPUT or nothing would make sense to me, but the weak guarantee of FORCE-OUTPUT doesn't.)
:force-output was a thinko... those two names always confuse me unless i reread the docs. pushed some fixes, including the docstrings, but it does not change my position on the issue, so feel free to move things. -- attila
Here's Edi's reply. Sounds to me like a backdown due to time issues. I still think the io.lisp stuff would make more sense in cl-fad than in alexandria. Perhaps there's anyone who wants to take over the maintainship of cl-fad? (Richard Kreuter would be my candidate of choice. Richard, are you on the list?) -T. Edi's reply: On Sat, 22 Nov 2008 15:58:53 +0100, "Tobias C. Rittweiler" wrote:
I'd like to hear Edi's opinion about the stuff in io.lisp[*], and whether he considers it appropriate for CL-Fad's "thin library" scope.
Generally, I'd like to keep CL-FAD as small as possible as it was from the beginning intended to be some kind of least common denominator lib. (In fact, it came to life as a more or less literal copy of Peter's code from his book.) Adding more stuff potentially adds more headache as it has to work the same on all supported platforms. Not to mention that I currently don't have much time to maintain my libraries anyway. So, my vote would be to keep things as they are. Symbol conflicts are things we have to live with anyway. Cheers, Edi.
"Tobias C. Rittweiler" <tcr@freebits.de> writes:
I still think the io.lisp stuff would make more sense in cl-fad than in alexandria.
Another project for which this stuff might be adequate is Osicat. See <http://common-lisp.net/project/osicat/git/osicat.git> -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
participants (5)
-
Attila Lendvai -
Luis Oliveira -
Nikodemus Siivola -
Samium Gromoff -
Tobias C. Rittweiler