From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id yO81JjpoGGbnMgEA62LTzQ:P1 (envelope-from ) for ; Fri, 12 Apr 2024 00:46:18 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id yO81JjpoGGbnMgEA62LTzQ (envelope-from ) for ; Fri, 12 Apr 2024 00:46:18 +0200 X-Envelope-To: patches@johnnyrichard.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b="N/4VrJxA"; dkim=pass header.d=disroot.org header.s=mail header.b=AskXC7Bn; spf=pass (aspmx1.migadu.com: domain of lists@sr.ht designates 46.23.81.152 as permitted sender) smtp.mailfrom=lists@sr.ht; dmarc=pass (policy=reject) header.from=disroot.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnyrichard.com; s=key1; t=1712875578; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=+SiruvfSz++fhTq0O2mMVZws4W6gazTy3c5lHp6Olc8=; b=m2YaEsexsZ1fyOCXQEH0czznvhLaI5eeiDKgdssGWPjZu8xG82gm7nWO8c3TZbfByb2jvP 9J62xaRNe05Hb1CiQl9MqGdUquAVo2zsBeHgPQvCApVptYj4yFZuuj/oJiq3q3ejwRWT1D y/CmxT/MeC0P7nof+l2N88lXE2996v55mhbcdxK/tCFke9PKGqhKj2CKZ4JopDPAj2jwUv aHtigjzJnbaX7JbPxwBk4ROiHkFNfGT+zred7UintTqCfc5z8BTpDRp83+UB8fN3FL5Rty Fsrzw2OknPpZ7NpORtXezX7CYuMgb1390Gs+aY4qT/0uCjNn2btm+6JbzoNlkw== ARC-Seal: i=1; s=key1; d=johnnyrichard.com; t=1712875578; a=rsa-sha256; cv=none; b=gBzcQDjHFWP/pzBq+3K2GS4A2WHgNavS3S959KA6eN4BJ9KFD5YWZD/XQopsBvR9y7sJil FdJXnvWOJtos9SAFxwn1YiDn3i7YpdMRBqt8AUKoqM/n2e6+u9XbeyCQVZ2LI/2KzStVll 7e68lU6AdzAuORiNhfUhkkZQrKE7GkwI4/3h25wxf+WbsNwZFNhatRTKnscdX6/cWPlWND O8EISoi4I07prHnYJLK8CdAhBd6WaZwcxfKVJ/yJk6kazCtcVWf+A16nwdkAt+c0iL2mwf /ir/IqGCEaNpkRVWEXVPTKV9JWv0wZtEJzFdo1y5ns8KrXtIFtBQuzPWh4PZEQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b="N/4VrJxA"; dkim=pass header.d=disroot.org header.s=mail header.b=AskXC7Bn; spf=pass (aspmx1.migadu.com: domain of lists@sr.ht designates 46.23.81.152 as permitted sender) smtp.mailfrom=lists@sr.ht; dmarc=pass (policy=reject) header.from=disroot.org 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 24D02632DC for ; Fri, 12 Apr 2024 00:46:15 +0200 (CEST) DKIM-Signature: a=rsa-sha256; bh=0loplJ2gkImHOzyxSpij61VoYe97NawNsaAobtbjKJM=; c=simple/simple; d=lists.sr.ht; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-Unsubscribe:List-Subscribe:List-Archive:List-Post:List-ID; q=dns/txt; s=20240113; t=1712875574; v=1; b=N/4VrJxAdC7JBI68C8Pt/hJp6HH7N5BpMm9/LgAXRelWnrOl+FIAaeVE6rE3gXiSygFAs3J0 eGjKbQewmwlCfEAN1ybBnH7ua/fNx2RJXBSI5nRt7XXpXnMaW4PZw74v6yqIlv5IJfmurZfVk9u 61hKlM4kp5/YYhHS6vcjfMEfVBZoa72S+9QnU88GXssAZCsVYTEdDi5zlV+2Hzq0EaY6bz8di8R Ly+5JLCufSeGm01fwSnuG239/ZVBZylgG1l6if8ER7k01RGOY+ZWwwJavVGKpkONLgK1LqKPaUL hIFkZE+gRvU5hrDuBXrT0e7mdVyObbLqGa+ctNNI6bQow== Received: from lists.sr.ht (unknown [IPv6:2a03:6000:1813:1337::154]) by mail-a.sr.ht (Postfix) with ESMTPSA id 9156220288 for ; Thu, 11 Apr 2024 22:46:14 +0000 (UTC) Received: from layka.disroot.org (layka.disroot.org [178.21.23.139]) by mail-a.sr.ht (Postfix) with ESMTPS id C105F20261 for <~johnnyrichard/olang-devel@lists.sr.ht>; Thu, 11 Apr 2024 22:46:13 +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=1712875572; bh=0loplJ2gkImHOzyxSpij61VoYe97NawNsaAobtbjKJM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=AskXC7BnOmp6qGH53cps+DvPChKRNYP6wrJa5pnwkYaizWEtov01Vp3/k1UhV5Ijt vbaAbZjPS38vpWaH9MMsckN/UlFcPbSfw0oeHcCGzmD1YpnPFch4y5bk5gas3x5PWL 7FfixmAUyUSkMhbcy77fvA5BSCClpd0eKiqnoz4aJDdy65QLNZldjnqoRasuOkZSpW E1PS0cHJOv89zhhir7j6JojquYelKl0AS+6leaeZKhEA9s95v1sDgX4A6yWkRp+iX7 up6Y5hUlfVdF3DAsrYWNCT84HtIr2EzeAB1d0fcCIQT4/bEScW3uS1bOZoT0zjA7Ug B60pHVxOVLoWQ== To: johnny@johnnyrichard.com Cc: carlos@maniero.me, ~johnnyrichard/olang-devel@lists.sr.ht, Ricardo Kagawa Subject: [PATCH] fixup! docs: spec: add variables and constants specification Date: Thu, 11 Apr 2024 19:39:58 -0300 Message-ID: <20240411224539.42752-1-ricardo_kagawa@disroot.org> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Sourcehut-Patchset-Status: UNKNOWN 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-Country: NL X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -9.10 X-Spam-Score: -9.10 X-Migadu-Queue-Id: 24D02632DC X-Migadu-Scanner: mx13.migadu.com X-TUID: tZu6zxsBAjgn From: Ricardo Kagawa > subject to semantic checks. Attempting to bypass these checks to > reassign a global constant will result in a segmentation fault > (SEGFAULT) and will be accepted at the function level. I would be careful with the wording here. Are you absolutely sure you can enforce this rule in case of a bypass attempt? If not, use something like "should" or "may" instead of "will". In the current version of the specification, it would be impossible to bypass the `const` check, and it would be possible to enforce it at compile-time. But depending on what you are planning to add to the language, it might become impossible to do so later. > Since this patch adds support to assignments, lets also add support to > all assignment operators like "-=" "+=" "<<=" and so on. I disagree. Support for those assignment operators should only be added when both assignments and operators are defined, and none of these operators are defined yet. > This patch lacks support to the following valid assignment expression > (which I think adds flexibility to the language): > > var x: u32 = a = b = c = 1 Personally, I don't like this idiom, but I wouldn't stop you from adding it. Johnny's patch actually already enables this, and also the following (for clarity, of course the `if` statement does not exist yet, but it is included here as an example of what might come in the future): ``` var x if (x = next()) { return x } ``` Which is something I don't like either, just as much. > > > We don't need to define twice the variable-definition for "var" and > > > "const", let's combine both in a single rule. > > > > I don't know if you noticed, but variables has an optional assignment > > while const has required assignment. > > Sure, I noticed. I took a look to how C solve this problem and seems > like it allows defining a const without assignment (I don't know why...). > > I would do the same to keep the gramma simple. And if we really want to > advice the developer about weird declaration, we could warning message > during semantics checking phase. I agree with Carlos, unless you have plans to allow constants to be initialized later (or not even initialized), which I don't like. I don't know what your plans for the future are, but in the case of the C language, I guess they didn't have a choice but allow for uninitialized constants. The compiler can validate the immutability of the constant, _as long as it is strictly accessed through its binding_. But the C language allows for pointer arithmetics and inline assembly, which allows the program to access memory positions in other ways besides references to the variable name. So the immutability of `const` variables is not a hard guarantee, but more like an advice, in this case. The compiler simply cannot make that many assumptions on what pointers point to, or where your assembly code writes things to. This is so bad that in legacy operating systems, it was possible to override kernel instructions, as long as you knew where they were in the physical memory. In modern operating systems, processes never have access to physical memory addresses, but they still have full access to their own memory. In other words, a pointer can still mutate constant variables, and even literal values in instructions (or the instructions themselves, which means macros are not immune to mutation either). Other languages can make stronger assumptions about constant variables, as they do not allow for direct memory manipulation. So, in my opinion, the decision should hinge on the compiler's ability to properly validate the constant's immutability, and whether or not late initialization should be allowed (complicating semantic checks). > I believe we may need two non-terminals, one for assignment which is > just the '=' and other for reassignments. I sort of agree here. But I guess the non-terminal names are bit confusing. The `=` sign in `const` and `var` declarations is _not_ an assignment operation, but declares an initializer. The semantics are subtly different, but still different, so assignment operators should not be allowed in variable/constant declarations. --- Discussions: - Are you planning to hoist declarations, or are declarations required to be placed before their use? - Are you planning to include type inference for variable declarations? If so, the variable type in variable and constant declarations could be made optional. -- >8 -- - Moved statements common to the translation unit and function bodies to their own non-terminal. - Restored Carlos' definition of variable and constant definitions, as they are not quite the same, structurally and semantically. Personally, I'd rather constants to be initialized immediately, but you may have a different opinion on this. - Moved some non-terminals from the "Statements" section to the "Functions" section, as there will be some statements that are function-body specific, some that are translation-unit specific, and some that are common to both. - Renamed "assign" to "assignment", for better wording. - Renamed from Carlos' patch to (must not be used in ). Signed-off-by: Ricardo Kagawa --- docs/pages/language-specification.md | 36 ++++++++++------------------ 1 file changed, 13 insertions(+), 23 deletions(-) diff --git a/docs/pages/language-specification.md b/docs/pages/language-specification.md index 2650dd9..b218462 100644 --- a/docs/pages/language-specification.md +++ b/docs/pages/language-specification.md @@ -24,15 +24,14 @@ language. (* Entry Point *) ::= ( ( | ))* - ::= - | - | +(* Translation Unit *) + ::= | (* Variables *) - ::= ':' ( )? - ::= 'var' - | 'const' - ::= + ::= 'var' ':' ? + ::= 'const' ':' + ::= + ::= '=' (* Functions *) ::= 'fn' ':' @@ -40,27 +39,18 @@ language. ::= '(' ')' ::= ::= + ::= '{' ( )* ? '}' + ::= | + ::= 'return' (* Statements *) - ::= '{' ( )* ? '}' ::= ';' | - ::= | | - ::= 'return' + ::= | | (* Expressions *) - ::= | | - ::= - ::= '=' - | '*=' - | '/=' - | '%=' - | '+=' - | '-=' - | '<<=' - | '>>=' - | '&=' - | '^=' - | '|=' + ::= | | + ::= + ::= '=' (* Identifiers *) ::= 'u32' -- 2.44.0