From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/27695 Path: main.gmane.org!not-for-mail From: Hrvoje Niksic Newsgroups: gmane.emacs.gnus.general Subject: Re: CVS: Symbol's function definition is void: ignore-errors Date: 04 Dec 1999 21:10:11 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: <9t9wvqu8o2k.fsf@mraz.iskon.hr> References: <3153296531820047@birk150.studby.uio.no> <82bkll$j5d$1@quimby.gnus.org> <9t9g0xi4lf6.fsf@mraz.iskon.hr> <9t9aenqa3tt.fsf@mraz.iskon.hr> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035164674 25860 80.91.224.250 (21 Oct 2002 01:44:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 01:44:34 +0000 (UTC) Return-Path: Original-Received: from bart.math.uh.edu (bart.math.uh.edu [129.7.128.48]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id PAA24787 for ; Sat, 4 Dec 1999 15:10:48 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by bart.math.uh.edu (8.9.1/8.9.1) with ESMTP id OAB10980; Sat, 4 Dec 1999 14:10:36 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sat, 04 Dec 1999 14:10:48 -0600 (CST) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id OAA14255 for ; Sat, 4 Dec 1999 14:10:37 -0600 (CST) Original-Received: from mraz.iskon.hr (root@mraz.iskon.hr [195.29.170.8]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id PAA24779 for ; Sat, 4 Dec 1999 15:10:12 -0500 (EST) Original-Received: (from hniksic@localhost) by mraz.iskon.hr (8.9.3/8.9.3/Debian 8.9.3-6) id VAA20774; Sat, 4 Dec 1999 21:10:11 +0100 X-Authentication-Warning: mraz.iskon.hr: hniksic set sender to hniksic@iskon.hr using -f Original-To: ding@gnus.org X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h writes: > > b) Some of them carry interesting meta-information that is not easy to > > transfer, such as instructions for byte-optimizer. cl.el is > > smarter than it appears -- some of the seemingly cluttered function > > and macro constructs compile to efficient byte-code. (See the > > various compiler macro definitions in cl-macs.el) > > Yup. That's why I want the byte-code, not the functions themselves. But the byte-code doesn't have the whole info. My point is that, for instance: (disassemble (lambda () (eql x 'bar))) ...disassembles to code that uses `eq' because it's safe. OTOH, this: (disassemble (lambda () (eql x y))) ...disassembles to code that uses `equal', because EQUAL has its own byte-code instruction, and it's faster than calling `eql'. If you do something like (fset 'gnus-eql (indirect-function 'eql)), you lose this meta-information. This is a trivial example, but there are more. EQL is a trivial example, but there is more where that came from. "compiler macros" != "Lisp macros". > #[(cl-seq &rest cl-keys) "byte code removed" [cl-delete-duplicates cl-seq cl-keys nil] 4 596479] > > Er. But the cl functions call other cl functions. Er. Uhm. Hm. > Can I alter the contents of the byte-compiled function to call the > Gnus functions instead? My, this is getting rather complicated... Yup. > > Maybe it would be a better approach to really really beg Stallman > > to allow Gnus to use the nice CL thingies. Gnus is *huge*. I > > don't think anyone will notice the difference. > > I think it's mainly a name-pollution thing for RMS. Having > `delete-duplicates' in the namespace will make people believe that's > a proper Emacs function and stuff. Isn't it, really? It ships with Emacs, it's GPL-ed, it's assigned to the FSF, it works nicely, it sings and it cooks for you. If noone is supposed to use it, why is it there in the first place?