Re: Appending Queues
Noah Lavine writes: > The only change I was considering is allowing an arbitrary number of > arguments, but that's something I can implement if people agree that > we want the functions in (ice-9 q). I'm loath to add anything to (ice-9 q) since I find the names, and the lack of a distinct type, less than satisfactory. However, if you are going to add them, I'd recommend sticking with the q- prefix. So, q-append and q-append!. Keeping the naming consistent means one less exception to remember. Also, I think it might be wise to add a list->q and q->list, with the obvious simple implementations (define (q->list q) (car q)) (define (list->q l) (if (null? l) (make-q) (cons l (last-pair l -- Ian Price -- shift-reset.com "Programming is like pinball. The reward for doing it well is the opportunity to do it again" - from "The Wizardy Compiled"
Re: Appending Queues
Hello, On Fri, Nov 2, 2012 at 1:20 PM, Ian Price wrote: > > I'm loath to add anything to (ice-9 q) since I find the names, and > the lack of a distinct type, less than satisfactory. > Fair enough. I'd be just as happy to implement a new queue container. I think we need to keep (ice-9 q) around for compatibility, though, so I'm tempted to say we should go ahead and make it as good as it can be. > However, if you are going to add them, I'd recommend sticking with the > q- prefix. So, q-append and q-append!. Keeping the naming consistent > means one less exception to remember. > > Also, I think it might be wise to add a list->q and q->list, with the > obvious simple implementations > You're right. :-) Noah
Re: Merging stable-2.0 into master
Hi, Mark H Weaver skribis: > I went ahead and pushed a proper merge of stable-2.0 into master. Great, thanks! Which method did you use? Ludo’.
Re: Appending Queues
Hi, Ian Price skribis: > Noah Lavine writes: > >> The only change I was considering is allowing an arbitrary number of >> arguments, but that's something I can implement if people agree that >> we want the functions in (ice-9 q). > > I'm loath to add anything to (ice-9 q) since I find the names, and > the lack of a distinct type, less than satisfactory. +1. And there are functional queue implementations around that are worth promoting, IMO. Ian: would you like to turn (pfds queues) into a patch against Guile? :-) Thanks, Ludo’.
Re: propose deprecation of generalized-vector-*
Hi! Daniel Llorens skribis: > today I filed a bug on generalized-vector->list > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12465 > > I remember similar bugs in the past, and I'm thinking that these functions > are redundant since we have array-ref, array->list, and so on, which also > work on strings, uniform vectors, etc. Agreed. > The only generalized-vector-? function that doesn't have a direct array-? > correspondence is generalized-vector-length. However, even for arrays of rank > > 1 it is often convenient to have a function such as > > (array-length a) = (car (array-dimensions a)) > > or maybe > > (array-length a) = (fold * 1 (array-dimensions a)) > > Personally I'd favor the first as there's nothing to compute, but either > would work to replace generalized-vector-length. Yes. That procedure would only make sense for one-dimensional arrays anyway. It could just as well throw an error when passed a multi-dimensional array, no? [...] > TLDR, I propose to remove the generalized-vector-? functions since the > array-? set can replace them. I think I agree, but I’d like to hear what Andy thinks, since he’s done a major overhaul of this part recently (and actually, thanks to this, generalized-vectors.c is very small.) Thanks, Ludo’.
