From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29339 invoked by alias); 14 Dec 2006 00:46:09 -0000 Received: (qmail 29332 invoked by uid 22791); 14 Dec 2006 00:46:08 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 14 Dec 2006 00:45:54 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga09.intel.com with ESMTP; 13 Dec 2006 16:45:53 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga002.fm.intel.com with ESMTP; 13 Dec 2006 16:45:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,165,1165219200"; d="scan'208"; a="26740566:sNHT23389146" Received: from scsmsx412.amr.corp.intel.com ([10.3.90.31]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 16:45:50 -0800 Received: from scsmsx413.amr.corp.intel.com ([10.3.90.32]) by scsmsx412.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 16:45:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: is systemtap's language more complicated than needed. Date: Thu, 14 Dec 2006 06:51:00 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: is systemtap's language more complicated than needed. Thread-Index: AccfF2k2vXjtfAqbSjOADfBKXIOmWQAAKPiQ From: "Stone, Joshua I" To: "Frank Ch. Eigler" , X-OriginalArrivalTime: 14 Dec 2006 00:45:49.0599 (UTC) FILETIME=[332402F0:01C71F19] X-IsSubscribed: yes 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/msg00668.txt.bz2 On Wednesday, December 13, 2006 4:33 PM, Frank Ch. Eigler wrote: > "Stone, Joshua I" writes: > 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. Ah, I thought there was a bug on that, but you caught me being too lazy to go look... :) >> 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. [...] >=20 > 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(...)". I don't think the current language is all that verbose. The main value I see in shortening it is for the benefit of one-liners. Would it make sense to do this generally and provide some sort of auto-completion? For example if I say 'probe foo', and there is no 'foo', but the only possible expansion is 'foobar', it could be automatically expanded. Wildcards almost do this, except that auto-completion means to give exactly one unambiguous match, rather than all matches. Josh