From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26678 invoked by alias); 14 Dec 2006 00:32:59 -0000 Received: (qmail 26669 invoked by uid 22791); 14 Dec 2006 00:32:58 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 14 Dec 2006 00:32:53 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBE0WquG001741 for ; Wed, 13 Dec 2006 19:32:52 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBE0Wp3E004495 for ; Wed, 13 Dec 2006 19:32:51 -0500 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBE0WpYq002425 for ; Wed, 13 Dec 2006 19:32:51 -0500 Received: from ton.toronto.redhat.com (ton.toronto.redhat.com [172.16.14.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 48FE58001DD for ; Wed, 13 Dec 2006 19:32:51 -0500 (EST) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id kBE0Wpi4020958 for ; Wed, 13 Dec 2006 19:32:51 -0500 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id kBE0WoYV020955; Wed, 13 Dec 2006 19:32:50 -0500 X-Authentication-Warning: ton.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: Subject: Re: is systemtap's language more complicated than needed. References: From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 14 Dec 2006 01:06:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00667.txt.bz2 "Stone, Joshua I" writes: > [...] > > this change will make it much easier to read and create scripts for > > the end user, especially if a function is inlined at some point in the > > future. > > This is a strong point in your favor, for the maintainability of scripts > and tapsets. And given that the compiler might also inline functions on > its own, the function/inline distinction can be a real headache. > [...] Indeed, and resolving this problem had been recorded as the goal of bug #1570. Indeed, the issue is complicated by tension between the in-probability inline function returns and the compiler's propensity to inline things. > Perhaps we could implement what you suggest as a shorthand, but > still leave the function/inline/statement variants in place to allow > one to be explicit. [...] Perhaps, though we would be saving just two tokens ("." and "function" / "statement" / ...) for each such shorthand use. Or one could save typing effort by supporting explicit abbreviations like "k.stmt(...)" for "kernel.statement(...)". - FChE