From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) by sourceware.org (Postfix) with ESMTPS id 987A13851C19 for ; Wed, 10 Feb 2021 16:50:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 987A13851C19 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bothner.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=per@bothner.com Received: from [10.9.9.72] (helo=submission01.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1l9shP-0002TD-1j; Wed, 10 Feb 2021 17:50:43 +0100 Received: by submission01.runbox with esmtpsa [Authenticated alias (524175)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1l9sh9-000270-6V; Wed, 10 Feb 2021 17:50:27 +0100 Subject: Re: Fwd: Value of given type cannot be case to its own type. To: "J. Vincent Toups" , kawa@sourceware.org References: <9a702bae-a8f6-1dbf-dc27-b5c0702f4219@bothner.com> From: Per Bothner Message-ID: Date: Wed, 10 Feb 2021 08:50:24 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 16:50:53 -0000 On 2/10/21 8:38 AM, J. Vincent Toups via Kawa wrote: > The issue was that I had defined a class called mecs in lib and there > was also a library called mecs in lib. So there were two classes lying > around called lib.mecs. > > It makes sense in retrospect but I wonder if it might not also make > sense to indicate in the class name of a library that it is produced > by a define-library form rather than a class definition to prevent > such classes in most cases. This is covered in moderate detail here: https://www.gnu.org/software/kawa/Module-classes.html It is convenient and flexible to compile both a library (lib mecs) and a class mecs in package lib to the class lib.mecs. Sometimes (as you saw) there can be a clash, but I think the convenience makes up for it. Furthermore, changing it at this point might break things. Kawa should catch this situation if both classes are produced by the same invocation of the kawa command. (If not, that is arguably a bug.) However, if they're produced at different times, then it's harder to catch. Also, if Kawa is confused by an existing incompatible lib.mecs class while it is generating lib.mecs, that is also a bug. I've run into some problems like that in the past, and I've tried to fix them. If you have a reproducible simple test-case I can take a look. -- --Per Bothner per@bothner.com http://per.bothner.com/