From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/4487 Path: main.gmane.org!not-for-mail From: visigoth@olivier.pc.cs.cmu.edu (John McClary Prevost) Newsgroups: gmane.emacs.gnus.general Subject: Re: Questions about backend interface and ranges Date: 18 Dec 1995 06:27:03 -0500 Organization: Dementia Linux Cabal Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145229 29803 80.91.224.250 (20 Oct 2002 20:20:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:20:29 +0000 (UTC) Cc: ding@ifi.uio.no Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by miranova.com (8.6.11/8.6.9) with ESMTP id EAA17340 for ; Mon, 18 Dec 1995 04:10:01 -0800 Original-Received: from olivier.dementia.org (visigoth@OLIVIER.PC.CS.CMU.EDU [128.2.250.73]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Mon, 18 Dec 1995 12:28:06 +0100 Original-Received: (from visigoth@localhost) by olivier.dementia.org (8.6.11/8.6.9) id GAA07352; Mon, 18 Dec 1995 06:27:03 -0500 Original-To: larsi@ifi.uio.no (Lars Magne Ingebrigtsen) In-Reply-To: larsi@ifi.uio.no's message of 15 Dec 1995 20:14:50 +0100 Original-Lines: 65 Xref: main.gmane.org gmane.emacs.gnus.general:4487 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:4487 >>>>> "lmi" == Lars Magne Ingebrigtsen writes: lmi> Yup. But you should take the "range" thing in the manual with a pinch lmi> of salt. Gnus uses virtually nothing but sorted numerical lists for lmi> all these functions. (Sorted numerical lists are a degenerate form of lmi> a range, though, so the manual isn't actually wrong. It's just more lmi> strict than what the reality is.) Yup--just trying to make my code as general as possible. If your document says ranges, I'll implement ranges. ;> lmi> All the functions you outline are indeed useful. The reason that lmi> Gnus doesn't use (proper) ranges for much now is that functions like lmi> that hadn't been written yet. lmi> So if you write the functions, Gnus will begin to make them useful. lmi> :-) I'll write them up, then. They might not be the most optimal form at first (I'm not sure what needs to be done to make things optimal under emacs... maybe the more trivial things should be macros) but somone else can work that out later if need be. lmi> Perhaps `range-car' and `range-cdr' would be two useful functions lmi> instead? They would (kinda) mimic what `car' and `cdr' do for normal lmi> lists... {...being able to get "first n pieces" out of range...} lmi> That would be extremely useful. I hadn't thought of that one. Better yet--if this operation were smart enough to group sequences of numbers together (like getting the first 5 from (1 2 3 4 5 6 7) gives you (1 . 5) and not (1 2 3 4 5)...) Hmm... lmi> Common Lisp calls the equivalent list functions `but-last' and lmi> `last'... No, wait, these would return ranges (lists) and `last' jsut lmi> returns the last element... What I'm considering for names now is range-first and range-rest, to go with the "first" and "rest" of CL. Using an optional argument, it also makes sense: (range-first foo 5) is the first 5 elements of foo. lmi> I haven't suggested this to RMS yet, but I would like functions like lmi> this to exist in a separate "range.el" package, so the functions would lmi> just be called `range-eq' and stuff. Okay--I'm making a new range.el file, then. Here's my list of functions at the moment: (range-first RANGE &optional COUNT) (range-but-first RANGE &optional COUNT) (range-append RANGE1 RANGE2) (range-equal RANGE1 RANGE2) (range-is-member-p RANGE NUMBER) (range-add-member RANGE NUMBER) These are pretty much self descriptive. To be technical on what range-append means, though, this is the guarantee: { for all z | z in R1 or z in R2, z is in (range-append R1 R2) } Off to code it... John.