From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id CDo4IQQHH2bKMQEAe85BDQ:P1 (envelope-from ) for ; Wed, 17 Apr 2024 01:17:24 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id CDo4IQQHH2bKMQEAe85BDQ (envelope-from ) for ; Wed, 17 Apr 2024 01:17:24 +0200 X-Envelope-To: patches@johnnyrichard.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=OlQqMGjG; dkim=pass header.d=disroot.org header.s=mail header.b=i8G1Dbbz; dmarc=pass (policy=reject) header.from=disroot.org; spf=pass (aspmx1.migadu.com: domain of lists@sr.ht designates 46.23.81.152 as permitted sender) smtp.mailfrom=lists@sr.ht ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnyrichard.com; s=key1; t=1713309444; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=Dim/qnGb2PVLfSAdi7H6oDG/U94FVExW2nvrV3w4ssE=; b=1NKCSXyR6MEEh4K12fUS6dp/OPuIaZT3uStsw7brS1ssnxtn40C7bSBGzj1vzSHW+NQCYv EfJeqMP5sLH3WmUJAbvyzAsihLMihsEyJsLflQ/eN5yDIFu1D5ZSwbeXpohubyWq7qCOlR fM4ljCn8Go1juDdmgxPupzQPgYneXQosYvHZP9X/I0eoWfcMRqHHOxtFdP5R80UKDmEJH5 Yo3cMKD3OcFN2Sv/m8Kudm58N8IuGPtRRXsXq7koF94urXg2rFjQ0PQ/dv2T/oVr5ZkkqM TNfWZHUkDSvFG1JubhbnF/geSEBgGeAg1+U8GBqMtwuUXPsOZSGvlPMw5qanVg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=OlQqMGjG; dkim=pass header.d=disroot.org header.s=mail header.b=i8G1Dbbz; dmarc=pass (policy=reject) header.from=disroot.org; spf=pass (aspmx1.migadu.com: domain of lists@sr.ht designates 46.23.81.152 as permitted sender) smtp.mailfrom=lists@sr.ht ARC-Seal: i=1; s=key1; d=johnnyrichard.com; t=1713309444; a=rsa-sha256; cv=none; b=coGHBJGvmROvoeiYFSTyyvGw0qx4YYvSZw07PTaouDTAuicb82j3sGNXSnq/w6BSJdyJVo rUxQAv3ssgKobkkeHxCZPRY8avguIOjN5SjLj1LHzoaUVoVdq8BKHlODb0og4gM8W5WCy+ IJE2VnmzNXZvB9mNKSHURP3C6180oDrwUitZkQ2e2QNtw+EmkWtYPVPffQTRCuYxv8EIN8 wIvIRmO6Cm0nUcuExzNFp9uVHceRAT0+jUVqeeM7DAxChlRgSAddomMpymdMVPO8j1p/3w OZreIE9Yvd/qHNTIpyN0n+eUCKtURyjV88fd9Qkl2jQZbcrrJCKCnnYYlogdog== Received: from mail-a.sr.ht (mail-a.sr.ht [46.23.81.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7777760052 for ; Wed, 17 Apr 2024 01:17:24 +0200 (CEST) DKIM-Signature: a=rsa-sha256; bh=Dim/qnGb2PVLfSAdi7H6oDG/U94FVExW2nvrV3w4ssE=; c=simple/simple; d=lists.sr.ht; h=From:To:Subject:Date:In-Reply-To:References:List-Unsubscribe:List-Subscribe:List-Archive:List-Post:List-ID; q=dns/txt; s=20240113; t=1713309444; v=1; b=OlQqMGjGbpvoZkJ5b/8ko7ITI4Aq0gWsMm+SjtlIN1Hz1uH21Rf9htGASQL7NLrWLKLyMPW7 amCQn2h3tCemTGO8VOqq2I513KTestaqYaBawBFa5TlC9ygNz+jQbDE1VyGXiTlEG4QYykxhSvE l1fwnQmL746n8VjrqoHZ0ZByfXkTvYErAVkQ/3/nj9e03bbzlddgy6luVB4hwNEKMG3i77Y7T8W D828/vACHKjOGi/fBAl9041Rbq1zrBW1eiMwtOlcUj1K+qgAkUas1x5QquPbouSyqtU0MpLHuV9 D91yJqgPWgLY+5AFIVxN+9ulyzK/leGOuUPneQ3YUlJ/Q== Received: from lists.sr.ht (unknown [IPv6:2a03:6000:1813:1337::154]) by mail-a.sr.ht (Postfix) with ESMTPSA id 127312017D for ; Tue, 16 Apr 2024 23:17:24 +0000 (UTC) Received: from layka.disroot.org (layka.disroot.org [178.21.23.139]) by mail-a.sr.ht (Postfix) with ESMTPS id 2917120165 for <~johnnyrichard/olang-devel@lists.sr.ht>; Tue, 16 Apr 2024 23:17:23 +0000 (UTC) X-Virus-Scanned: SPAM Filter at disroot.org From: ricardo_kagawa@disroot.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1713309441; bh=Dim/qnGb2PVLfSAdi7H6oDG/U94FVExW2nvrV3w4ssE=; h=From:To:Subject:Date:In-Reply-To:References; b=i8G1DbbznkeQY8w1o83hkHU+Y+C0mGS5scI5hyfwyJ7E+bMsa5IDfkxFZ8DOcfFcB Cfl1CC7itx5DxIGpEJmg26FyDKJz6im1zUhAFgBZNYs9vLdORCCjyvlRNugwfVCaUU AvD4NCN9qka+g9cvGWkEGeurZ1yKfRbhv8h3gZgI0c+ZDc0GrzmmxQOjPm669ToQ+T jPlIDcd+uEDBSQg7xGOjSkF/YvJ/6REIRjRv3UebTj+9pdQkss/v7uoGdb0/8rlYj7 7uqMgvlBf2qmnWbM74PGda1DVePKE7hOn6CoZMlrEUNjUnLL/mNnhsCu/HgRF27GHW im0GJxauvUK/g== To: ~johnnyrichard/olang-devel@lists.sr.ht Subject: Re: [PATCH olang v1] spec: ebnf: add binary expressions Date: Tue, 16 Apr 2024 20:17:15 -0300 Message-ID: <20240416231715.51062-1-ricardo_kagawa@disroot.org> In-Reply-To: <52aqozoevpqhucq67znjjbaqrpb65tubgc3yrp7isqo2x2bofz@ugtgrccjdkbb> References: <52aqozoevpqhucq67znjjbaqrpb65tubgc3yrp7isqo2x2bofz@ugtgrccjdkbb> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Unsubscribe: List-Subscribe: List-Archive: Archived-At: List-Post: List-ID: ~johnnyrichard/olang-devel <~johnnyrichard/olang-devel.lists.sr.ht> Sender: ~johnnyrichard/olang-devel <~johnnyrichard/olang-devel@lists.sr.ht> X-Migadu-Flow: FLOW_IN X-Migadu-Country: NL X-Migadu-Spam-Score: -6.11 X-Migadu-Scanner: mx11.migadu.com X-Spam-Score: -6.11 X-Migadu-Queue-Id: 7777760052 X-TUID: wTsdv5PhPyPm - This patch is missing the `%` operator; - This patch seems to be missing the `>=` and `<=` operators. > I'd like to get your opinion: Is it really necessary to represent > precedence here? Some language specifications [1] chose to omit this My opinion is that there are trade-offs to consider before deciding for either convention or anything in-between. I suspect these are the trade-offs to consider: 1. Implement precedence as part of the parser or as part of semantic analysis; 2. Document precedence as part of the grammar or as a comment about the grammar. For the first item, if precedence is represented in the grammar, it might be possible to evaluate expressions in the correct order during parsing. Otherwise, the grammar is still valid, but semantic analysis must find the correct order of expressions after parsing. The grammar may be made simpler, but the complexity does not really go away. For the second item, if precedence is represented in the grammar, you don't have to define it authoritatively somewhere else (you may have other informational documents describing that same precedence), so it is automatically up-to-date. Otherwise, the grammar can be made simpler, but it must refer to somewhere else to clarify what the precedence is, which has to be updated separately. Since the grammar is not used to generate the parser, there is less benefit to representing precedence in the grammar. Still, I'd prefer to represent it in the grammar, since I'm already familiar with that convention, which might be the case for many other people and perhaps even tools. What really matters is that you are able to convey your intentions in regards to language design, so that everyone from devs to users have a close enough understanding to properly implement, use and reason about it. Whatever you feel is clear enough for most people should be good enough.