From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: defconst in lao.el Date: Wed, 17 Nov 2004 10:41:48 +0900 (JST) Message-ID: <200411170141.KAA24828@etlken.m17n.org> References: <200411141856.iAEIuEM24284@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1100655763 22254 80.91.229.6 (17 Nov 2004 01:42:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 17 Nov 2004 01:42:43 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 17 02:42:31 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CUEq7-0000lF-00 for ; Wed, 17 Nov 2004 02:42:31 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CUEyt-0004Uw-I5 for ged-emacs-devel@m.gmane.org; Tue, 16 Nov 2004 20:51:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CUEyl-0004Ug-Ah for emacs-devel@gnu.org; Tue, 16 Nov 2004 20:51:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CUEyk-0004UT-S9 for emacs-devel@gnu.org; Tue, 16 Nov 2004 20:51:27 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CUEyk-0004UQ-QD for emacs-devel@gnu.org; Tue, 16 Nov 2004 20:51:26 -0500 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CUEpf-0005SO-Gk for emacs-devel@gnu.org; Tue, 16 Nov 2004 20:42:04 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.12.3/8.12.3/Debian-7.1) with ESMTP id iAH1fnTH009476; Wed, 17 Nov 2004 10:41:50 +0900 Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6p2/8.11.6) with ESMTP id iAH1fmA13854; Wed, 17 Nov 2004 10:41:48 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id KAA24828; Wed, 17 Nov 2004 10:41:48 +0900 (JST) Original-To: teirllm@dms.auburn.edu In-reply-to: <200411141856.iAEIuEM24284@raven.dms.auburn.edu> (message from Luc Teirlinck on Sun, 14 Nov 2004 12:56:14 -0600 (CST)) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29949 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29949 In article <200411141856.iAEIuEM24284@raven.dms.auburn.edu>, Luc Teirlinck writes: > I believe that all defconst's in lao.el should be > defvar's. Several are changed in the file itself and > produce compiler warnings. I propose the patch below. I > am not sure what to do about the Copyright: > ;; Copyright (C) 1997 Electrotechnical Laboratory, JAPAN. > ;; Licensed to the Free Software Foundation. Please keep it as is and add a new Copyright line below it (see leim/quail/latin-post.el) if you modify this file. But... > ! (defconat lao-key-alist ... > ! (defvar lao-key-alist The original defconst doesn't yield a warning, and this variable is surely not modified later. > ! (defvar lao-consonant-key-alist nil) > ! (defvar lao-semivowel-key-alist nil) > ! (defvar lao-vowel-key-alist nil) > ! (defvar lao-voweltone-key-alist nil) > ! (defvar lao-tone-key-alist nil) > ! (defvar lao-other-key-alist nil) I used "defconst" for them because they have to be set back to nil when lao.el is re-loaded. They are setup in the following (let ...) form to correct values. If we change them to "defvar", they are anyway set to nil in that (let ...) form. And, conceptually, they are "constant". So I think "defconst" is better. Then, how to avoid the compiler warnings? The problem is that their initial values are calculated at the same time (not one by one) in the "let" form. --- Ken'ichi HANDA handa@m17n.org