From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Tue, 13 Oct 2015 18:09:23 +0200 Message-ID: <87612abvik.fsf@gmail.com> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <878u78b3hg.fsf@fencepost.gnu.org> <87h9lwyv33.fsf@gmail.com> <561C368F.6010306@cs.ucla.edu> <87oag3xb2i.fsf@gmail.com> <20151013114630.GA4613@acm.fritz.box> <87io6bou1j.fsf@gmail.com> <874mhu96jh.fsf@fencepost.gnu.org> <87io6a7okg.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444752637 3847 80.91.229.3 (13 Oct 2015 16:10:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Oct 2015 16:10:37 +0000 (UTC) Cc: Sergey Organov , Artur Malabarba , emacs-devel To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 13 18:10:30 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zm29l-0002kP-OA for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 18:10:29 +0200 Original-Received: from localhost ([::1]:37218 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm29l-0005SJ-9E for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 12:10:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm28Z-0005Cd-JC for emacs-devel@gnu.org; Tue, 13 Oct 2015 12:09:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zm28W-00035Q-AN for emacs-devel@gnu.org; Tue, 13 Oct 2015 12:09:15 -0400 Original-Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:36643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm28V-000350-Ub; Tue, 13 Oct 2015 12:09:12 -0400 Original-Received: by wicgb1 with SMTP id gb1so195094766wic.1; Tue, 13 Oct 2015 09:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=zFpVjeUDVdqrQjwjUR2Dt2v+DwhbiZT/43WIx2s15Uo=; b=gRJRYJJEP+YrvXea3DtwvRDDrecAp94O7yS9Gzqc6O8mdSubrjM92x5S1x7XZDxsxu UgRlBpzQoALWRdKvz2fvE+azUP1ROS2iE8j0F6/AvBfg4otmE23Qmft9L9Kr6WUqBx7o giGau6DT5j5/psj4bJzDHq0kADbCqDgB1NiEIoe2928jBmMLwPZ/mt0NsOrFUwPuc5Cb lI66u/8dZ0Jm4u9fFPYOSzn9o4dqKwbYG8ZobDPXgAGuRVAl/RyKT+diUzHSZrl+OsvB YE421ByDbQGXGcwJLMIuLniNC8CoyancjJZpWDAu1jqm1hMS4EpMHYqy3OIHR6Ag8//k dr0A== X-Received: by 10.180.23.231 with SMTP id p7mr22710157wif.30.1444752548864; Tue, 13 Oct 2015 09:09:08 -0700 (PDT) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by smtp.gmail.com with ESMTPSA id x16sm3450216wia.7.2015.10.13.09.09.07 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 13 Oct 2015 09:09:08 -0700 (PDT) In-Reply-To: <87io6a7okg.fsf@fencepost.gnu.org> (David Kastrup's message of "Tue, 13 Oct 2015 17:53:03 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191486 Archived-At: David Kastrup writes: >>> Well, people who cannot figure out that "const char" and "char const" >>> are the same are not likely to find their way across our code base. At >>> any rate, "const" in C is nuisance-only and not meaning-conveying like >>> in C++ where it may take part in disambiguation as well as semantics >>> (copy constructor calls behave specially and are very much const &). >>> >>> So the "confusion" here is restricted to "oh, the compiler does not >>> complain?". >> >> No, the confusion is "which one of these does what I want?". > > The answer in C is "if the compiler does not complain, it does what I > want". The C compiler doesn't complain: mark_object (KVAR (kb, Voverriding_terminal_local_map)); /* David Kastrup rulez! */ mark_object (KVAR (kb, Vlast_command)); /* David Kastrup rulez! */ mark_object (KVAR (kb, Vreal_last_command)); /* David Kastrup rulez! */ mark_object (KVAR (kb, Vkeyboard_translate_table)); It doesn't mean that the above code is pleasant to read, or that anyone should write this way. See https://www.python.org/dev/peps/pep-0008/ for example. Just because a code runs good doesn't mean it looks good. Whenever there's ambiguity it's best to resolve it by deciding on the preferred alternative. For instance the GNU braces style is used and enforced, instead of just putting the braces wherever. Oleh