From owner-freebsd-arch@FreeBSD.ORG Wed Oct 31 01:27:35 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC53516A420; Wed, 31 Oct 2007 01:27:35 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id CEEA013C48A; Wed, 31 Oct 2007 01:27:34 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup55.ach.sch.gr [81.186.70.55]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l9V1CDiQ012508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2007 03:12:49 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l9V1C3fd033586; Wed, 31 Oct 2007 03:12:03 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l9V1Bbw8033585; Wed, 31 Oct 2007 03:11:37 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Wed, 31 Oct 2007 03:11:36 +0200 From: Giorgos Keramidas To: Bakul Shah Message-ID: <20071031011136.GA33331@kobe.laptop> References: <20071030055840.GS33488@elvis.mu.org> <20071030163613.E70665B30@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071030163613.E70665B30@mail.bitblocks.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.925, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.47, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Poul-Henning Kamp , Alfred Perlstein , Garance A Drosehn , freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2007 01:27:35 -0000 On 2007-10-30 09:36, Bakul Shah wrote: > The structured macro paper referenced on the K wiki page also > seems rather interesting. A powerful macro facility needs to > be well integrated with the language (much like Lisp or > Scheme's macros) so that you can write for instance > > critical_section(lock) { > ... > bar: > ... > if (cond1) break; > ... > if (cond2) goto foo; > ... > if (cond3) goto bar; > ... > if (cond4) return; // from enclosing function > ... > } > ... > foo: > > and have it transform to vanilla C code that does proper > unlocking on any exit. To a first approximation I think of > them as compile time "functions" that take identifiers and code > as arguments and return code. That sounds interesting indeed. Even userlevel code can benefit greatly from a structured macro enhancement to plain, vanilla C. I've been reading a lot about macros in both C and Lisp Usenet groups, but I am not sure how feasible it would be to have in a C-like language the deeply integrated macros like: (exception-handling-code (critical-section (lock) ...)) without an equivalently advanced mechanism for handling exceptions in the case the macros fail. At least, not in a way that doesn't make the C-like language sufficiently unportable to be tricky to implement & use. For example, in the critical_section() macro above, 'break' is a quite 'plain' C feature, but it should suddenly grow enough knowledge about the encapsulating macro to DTRT. The 'return' keyword is similar. Anything that is related to scope of the lock object too, and we are already in our way to design something that is superficialy similar to C but only in a very basic level of syntax :/ > Coming up with something that is semantically well defined & > integrates well with C can not be easy. All budding feature > designers ought to read Tony Hoare's "Hints on programming > language design". Still relevant after 33 years. Search for > cb-p193-hoare.pdf. Right on the spot, indeed.