From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12317 invoked by alias); 16 Sep 2009 00:47:13 -0000 Received: (qmail 12308 invoked by uid 22791); 16 Sep 2009 00:47:12 -0000 X-SWARE-Spam-Status: No, hits=-10.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: sourceware.org Received: from proofpoint2.lanl.gov (HELO proofpoint2.lanl.gov) (204.121.3.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Sep 2009 00:47:09 +0000 Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by proofpoint2.lanl.gov (8.14.3/8.14.3) with ESMTP id n8G0l8up003175 for ; Tue, 15 Sep 2009 18:47:08 -0600 Received: from alvie-mail.lanl.gov (alvie-mail.lanl.gov [128.165.4.110]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 112D515C9E56 for ; Tue, 15 Sep 2009 18:47:08 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by alvie-mail.lanl.gov (Postfix) with ESMTP id 0F8D87D009D for ; Tue, 15 Sep 2009 18:47:08 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at alvie-mail.lanl.gov Received: from [130.55.124.157] (manticore.lanl.gov [130.55.124.157]) by alvie-mail.lanl.gov (Postfix) with ESMTP id F3FD97D009C for ; Tue, 15 Sep 2009 18:47:07 -0600 (MDT) Subject: Re: GSL 2.0 roadmap (one man's view) From: Gerard Jungman To: GSL Discuss Mailing List In-Reply-To: References: <48E25CA9.6080306@iki.fi> <490DE4BD.7070907@iki.fi> <497B00F6.2080400@iki.fi> <498727E5.6080407@iki.fi> <49AA9DB5.6030908@iki.fi> <49FB01D1.30000@iki.fi> <4A7ADFDC.9080408@iki.fi> <1251414774.23092.80.camel@manticore.lanl.gov> <1251414939.23092.82.camel@manticore.lanl.gov> Content-Type: text/plain Date: Wed, 16 Sep 2009 00:47:00 -0000 Message-Id: <1253062179.23092.971.camel@manticore.lanl.gov> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2009-09-15_11:2009-09-01,2009-09-15,2009-09-15 signatures=0 Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00048.txt.bz2 On Mon, 2009-09-07 at 16:07 +0100, Brian Gough wrote: > At Thu, 27 Aug 2009 17:15:39 -0600, > Gerard Jungman wrote: > > There are also significant usability issues with the simple aspects > > of the interfaces. The get() and set() functions have been deplored > > by many users. > > Is there an alternative in C? I can only think of providing macros > for expressions like *gsl_vector_ptr(v,i) = x if one prefers to assign > to an l-value. Yes and no. For example, in 9/10 cases the underlying data is just a contiguous block of double (with unit stride). In that case I can always just extract the pointer and apply []. Ok, you say, this is very dangerous because somebody could pull the rug out from under you, or you might forget about striding, etc. True. But the GSL interface should not make it harder to do things in the simplest 9/10 cases. There should be a way for the data pointer (or block) to coexist with the meta-info for layout, so that both can be used as needed. It smells like a view, and indeed it is. But it is a notion of view which is more central to the design than the current one. Everything should be a view. Again, more details will follow, if I get around to typing what is in my head. But we're all experienced adults here; isn't it clear that there must be a better way, independent of what I end up typing? -- G. Jungman