From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id EG2OFySU/2W9/wAAqHPOHw:P1 (envelope-from ) for ; Sun, 24 Mar 2024 03:47:00 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id EG2OFySU/2W9/wAAqHPOHw (envelope-from ) for ; Sun, 24 Mar 2024 03:47:00 +0100 X-Envelope-To: patches@johnnyrichard.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=PL9qSay9; dkim=none ("invalid DKIM record") header.d=maniero.me header.s=hostingermail1 header.b=pDbeM9dC; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=maniero.me (policy=none); spf=pass (aspmx1.migadu.com: domain of lists@sr.ht designates 46.23.81.152 as permitted sender) smtp.mailfrom=lists@sr.ht; arc=pass ("mailchannels.net:s=arc-2022:i=1") ARC-Seal: i=2; s=key1; d=johnnyrichard.com; t=1711248420; a=rsa-sha256; cv=pass; b=AEwdRBakphuRUNsMRPqRhDK4i7RPKL8pkWTHNRpBMKTRFtM2xvge4ZNc1kzH3dmFYHKEur QD66sx/HAEUWUraas55rS4wtl6dkrYW4FHnBI7rugrCYDO6MFGxm05tfchvJbUNdW+oL9b 29FWpf3/mz6GfCYslXPl87DbOGEp4FK92ZBCyP3XwQ8qKPmCFCQpEKPG9otO5glghaPKu1 KNJMexV6p4a5ixaQUYn86bcqfk4MSdQvXkXeUlswGg1MrZib5wHzYikcF1OKH2wx0fvpg7 XPOL6yEPBY4Q8UziaUR5eVY+LBTXGhz7Ho6ahFKHJPZGs8tifqM0HpoiD0WRXg== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=PL9qSay9; dkim=none ("invalid DKIM record") header.d=maniero.me header.s=hostingermail1 header.b=pDbeM9dC; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=maniero.me (policy=none); spf=pass (aspmx1.migadu.com: domain of lists@sr.ht designates 46.23.81.152 as permitted sender) smtp.mailfrom=lists@sr.ht; arc=pass ("mailchannels.net:s=arc-2022:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=johnnyrichard.com; s=key1; t=1711248420; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=5QvKrpwnbCHUMjxc0/JGnrPUKwCVBCe37RM19VAlU58=; b=qGwroWieIkWkVPYyTW7APy/QV9JyYxdkzXD6SQKx3NuPksQivCARa9c0kSkuPYWVhB1iOu BlSk6elTKIIBvNiQGrvUWpPcmv9kOFgXQ/GK+WT+MGWdgVTLyG80JXhaETdxpyiL5mFpoT jButpTx4tfBQtA9beHhfSGzqWjhQ0BDpSN90FmeZz1IH2dfR/BL+iw7bAvhFj7xdpOlBNh 6hSvH2mjLIg7dFxkRv3/GyglBp63RqKTCuFewB2KmNylF2v8QVRcwt/eLVCrFvZfTFhVwl yIDi0WyFhoqbI3tT/eYWlmjFt5kYZ+iaZG/ph6r5ThUSfo0u6e0MatKgLirjIg== 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 1D59911630 for ; Sun, 24 Mar 2024 03:47:00 +0100 (CET) DKIM-Signature: a=rsa-sha256; bh=Upd93dnYzeVUru7oxRj4S3Zz2l5m1iWXh/qQFzJ0btI=; c=simple/simple; d=lists.sr.ht; h=Date:Subject:From:To:List-Unsubscribe:List-Subscribe:List-Archive:List-Post:List-ID; q=dns/txt; s=20240113; t=1711248419; v=1; b=PL9qSay9z5KsDaLL2Iac3vg2eU+ZoqWpyLU/peYRUXnELpbZgEN8HaZWuLGlunJrnzOJaCEJ P6JfzyZHxOHwnWzKcWXfOHGFxB4VA4ulo6FNwDYLN2H6cUnL87VHOI6m1SITGW196qs/pk0V69b CIH9NKh7VZUToYdwAyvEUsLxMdCSt40GsrF8+mCRe6WDAeSsSXI2ooI10fOl2lw1zvZOKqPi1i6 2gW8x+06sezI2VsdY7/zXUFsD6xSNshroQXZkvt5OUt688BmzSpY8h7WZn1JUGfgoi7l0KU/hPP CJj1OLPbeX7AQUznBVJfkWPwp8CWpct7UHhBOPNzu3uBg== Received: from lists.sr.ht (unknown [46.23.81.154]) by mail-a.sr.ht (Postfix) with ESMTPSA id 8CE8E202B1 for ; Sun, 24 Mar 2024 02:46:59 +0000 (UTC) Received: from buffalo.tulip.relay.mailchannels.net (buffalo.tulip.relay.mailchannels.net [23.83.218.24]) by mail-a.sr.ht (Postfix) with ESMTPS id 770BF20250 for <~johnnyrichard/olang-devel@lists.sr.ht>; Sun, 24 Mar 2024 02:46:58 +0000 (UTC) X-Sender-Id: hostingeremail|x-authuser|carlos@maniero.me Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 390316C08F8 for <~johnnyrichard/olang-devel@lists.sr.ht>; Sun, 24 Mar 2024 02:46:55 +0000 (UTC) Received: from uk-fast-smtpout5.hostinger.io (unknown [127.0.0.6]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 369A36C0C3C for <~johnnyrichard/olang-devel@lists.sr.ht>; Sun, 24 Mar 2024 02:46:54 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1711248414; a=rsa-sha256; cv=none; b=LzJe3nyrxe1ovDFWCQAFZwuTdLJJLZhe9azHijUnxH99JTQAWfVTWMudmGM3uMGNQc/EhC nXZw4YUuPBtNu6PnObp22sZRubzWJiSrRXkEJ5sBpNFpAd6GCt7/pN5q2IfUqD4TmqM6y9 oVaUzRDvcRAQKpxEoOaKTyx+o6t7TQJvdwtxkv6lslcBHrudufVypSrPSWYaSsH3Tj0kfD iYelIGhk3CuYTtxBgHGRau3oOBi7yDEiPqFil83rIO3t5kIAeFqfCCZSJZ4z6IGdEKqZUh SdW74mQld2f2PcWRF2FSoCGmJZew9rM28MZLs3//Y1N/niKwh/q6qY8a72OZFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1711248414; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=5QvKrpwnbCHUMjxc0/JGnrPUKwCVBCe37RM19VAlU58=; b=QCJAzesptIrB4SL3Tz8XL94eghZjqw0n7a8cdXkLZzIy6XQwH0NytOXqI/NuY0uuaefLQh lDoy6V9X1ACi0/tluFkwum49aEu/reoNrzUmDTV9m4ZgG595ly9Sx7LkiW9vojFiE3vmd5 h1kPxgqURt/SYwSe1z/viJYh5OCfUjbfDs2s5ztJt2RK6sJL8g1fl1zxU82T7E+5KvA56j gQ4Q7s2idIMRFnsdhvkyg60qVpvqfrSRSt8jAK6ee0VI21E754qE6HBoyWB29LpkQ4tkBN +4oAw9r9Jwdh+8jYBDoWqIxpxqiLs5+TBMU76nJcDu8zbqYDF1UfkOjAV1ShtQ== ARC-Authentication-Results: i=1; rspamd-6c65898bb7-2lpt7; auth=pass smtp.auth=hostingeremail smtp.mailfrom=carlos@maniero.me X-Sender-Id: hostingeremail|x-authuser|carlos@maniero.me X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authuser|carlos@maniero.me X-MailChannels-Auth-Id: hostingeremail X-Fearful-Snatch: 2f3eed770196fd67_1711248414898_1263520970 X-MC-Loop-Signature: 1711248414898:2602293444 X-MC-Ingress-Time: 1711248414897 Received: from uk-fast-smtpout5.hostinger.io ([UNAVAILABLE]. [31.220.23.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.99.189.244 (trex/6.9.2); Sun, 24 Mar 2024 02:46:54 +0000 Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maniero.me; s=hostingermail1; t=1711248412; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=5QvKrpwnbCHUMjxc0/JGnrPUKwCVBCe37RM19VAlU58=; b=pDbeM9dCPVzttLnVINWsILFG6xHutichyaQGMxjnAGkaXdK2E4GCBPvKGDiV2vjSj+ex2c ztPYD3UxuAnIAZhVrSRl8hI8Q5n4syYHLkK8Vd+k8Y5EH7hLX7ojyhiAPM/Zzh5Z+ulQkr Gz4bdH0wOjWHnh3mRivdSm/qkfZzcQ0dqNs24FzHci9y3UXmMtEITIhAxOtQCtrydP2zrL YV/S52uLqpiZi94FJ3Dd1jeGwbc7fQb4hLyWlxFeUA2Y7MmE/6JXM6I2D+snjwl9L5w5Wy XsnpWQLImrvi1YeyBhsEZx0TIy+9V1Z7Vjykr/4Tsb8AEV+x5ljxV9ON2bD6eA== Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 23 Mar 2024 23:46:46 -0300 Message-Id: Subject: [RFC] Namespaces in OLANG From: "Carlos Maniero" To: <~johnnyrichard/olang-devel@lists.sr.ht> X-Mailer: aerc 0.15.2-211-g37d5fc691aff X-CM-Analysis: v=2.4 cv=B6m/0vtM c=1 sm=1 tr=0 ts=65ff941c a=WwxFCuf3mf1fs3oSi6/dng==:117 a=WwxFCuf3mf1fs3oSi6/dng==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=bvo2XIDTXyw_f6icmccA:9 a=QEXdDO2ut3YA:10 a=BXDaF_L80NY05PYiAFlV:22 X-CM-Envelope: MS4xfG9TJMQvzOVfc4ziSvXamVE7/t6XS1TgJd0htI3sI5IEmu5fU7l+wi72lMRm1mBk/oFLa+97cCwUif1YUXPwOBcTk1dSSp2RFIcUfyywdETL4yjej3OU KG0BvO4W9VKsC9vmBxCQ07RMHzej0SdFlVTlzeUkOGfofUUYIm7YpX/1P2MuF7AgjrlpCk5+f4qUEuY/g41FUmuVfTrMy0VY0ik= X-AuthUser: carlos@maniero.me 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-Spam-Score: -5.04 X-Migadu-Queue-Id: 1D59911630 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -5.04 X-TUID: xQ7VvazLsg20 One of the inconveniences in C programming is the necessity to manually namespace our functions to prevent conflicts. Consider the example bellow: File: list.h ... void add(list_t* list, void* value); ... File: math.h ... void add(int a, int b); ... File: main.c require require This will result in a compilation error, as both *list.h* and *math.h* defi= ne a function named *add*. The reason for this behavior in C is straightforward: C uses function names= as assembly labels. This means that in the example above, there will be an att= empt to create two assembly labels named add, which is not allowed. How other languages deal with that? ----------------------------------- Many languages solve this issue by creating custom labels for functions. Let's examine an example with C++ int sum(int a, int b) { return a + b; } int main() { return sum(1, 2); } =20 Assembly: _Z3sumii: ... movl %edi, -4(%rbp) movl %esi, -8(%rbp) movl -4(%rbp), %edx movl -8(%rbp), %eax addl %edx, %eax ... ret ... main: ... movl $2, %esi movl $1, %edi call _Z3sumii ... As you can see, the sum function was named as _Z3sumii. While this is a goo= d way to deal with name conflicts, it completely breaks C=E2=80=99s compatibi= lity. Let=E2=80=99s say we need to call this function from C. Assuming that the f= unction name is deterministic and standard for all C++ compilers, we would need to refer= to this mangled name in C, which could lead to a fragile implementation. File: main.c extern _Z3sumii(int a, int b); To make the C++ and C integration more reliable, the *extern* keyword can b= e used. extern "C" int sum(int a, int b) { return a + b; } The example above will produce a assembly function with *sum* label which i= s easily referable in C. sum: ... movl %edi, -4(%rbp) movl %esi, -8(%rbp) movl -4(%rbp), %edx movl -8(%rbp), %eax addl %edx, %eax However, the use of *extern "C"* comes with its own set of challenges. Whil= e it facilitates the integration of C and C++ code, it simultaneously exposes us= to potential naming collisions. Additionally, it can introduce an element of distraction within the code. Using namespaces in olang ------------------------- Before we begin, I want to ensure that we=E2=80=99re all on the same page r= egarding the following points: 1. Deterministic Code Generation: Our goal is to be able to examine an olan= g function and precisely predict the assembly code that will be generated. 2. Full Compatibility with C: We aim for seamless integration with C. We do= n=E2=80=99t want to introduce features to the language solely for compatibility with C.= Any code compiled by olang should be usable in C without requiring any addition= al boilerplate. 3. Manual namespacing is inconvenient: While it=E2=80=99s possible to creat= e a manual namespace for your functions in C by prefixing them with a namespace, this approach can be cumbersome and inconvenient. To address conflicts while still ensuring predictable code generation, compatibility with C and without the need for manual namespaces, I purpose = the *ns* statement. ns olang.core.math fn add(a: u32, b: u32): u32 { return a + b } This could generate an assembly label called *olang_core_math__add*. Let's evaluate this solution against our three key criteria: 1. Deterministic Code Generation: It is deterministic! The function label is always {ns}__{fn_name}. 2. Full Compatibility with C: It is completely compatible with C! int olang_core_math__add(int, int); If you think it is ugly to call a function that way directly, you can cr= eate macros in C to improve the readability, but completely optional. #define NSMATH(name) olang_core_math__##name int NSMATH(add)(int a, int b); int main() { return NSMATH(add)(2, 3); } 3. Manual namespacing is inconvenient:=20 You don't need to manually namespace every function with the cost of sta= rt every single file with a *ns* statement. An important observation of the *ns* usage is that it must match the direct= ory structure. The path of a file that declares the namespace *olang.core.math* must ends with *olang/core/math.ol*. This requirement is need for future import resolution. Alternatives: ------------- 1. Automatically create namespaces based on the filename: Automatically creating namespaces based on the filename presents a unique s= et of challenges. The primary hurdle is determining the starting point of the namespace. For instance, if we have a file located at */a/b/c/d.ol*, it=E2= =80=99s unclear where the namespace should start. This is a route that Python has taken, and it=E2=80=99s not uncommon to enc= ounter developers wrestling with import-related issues as a result. 2. Manual namespaces: ... Conclusion ---------- In my opinion, the introduction of a namespace statement offers numerous benefits: - It aids in resolving function name conflicts. - It facilitates deterministic code generation while maintaining compatibil= ity with C. - It simplifies the resolution of imports. These advantages come with the minor stipulation of initiating all files wi= th a namespace statement, which, in my view, is a small price to pay for the benefits gained. Note that *ns* is just a suggestion, we can go with *module* or any other keyword. I don't know if we have plans to have C++ like namespaces which is= a totally different thing. Also I started to think about it because I'm working in adding debugging information on the code we generate and I have the need to represent a d fi= le in the AST and the program node does not seems appropriated for it. If we goes with *ns* the olang spect will look like it: (* Namespace *) ::=3D 'ns' ::=3D (* Entry Point *) ::=3D (* Functions *) ::=3D 'fn' ':' ::=3D ::=3D '(' ')' ::=3D ::=3D (* Statements *) ::=3D '{' ( )* ? '}' ::=3D ';' | ::=3D ::=3D 'return' (* Expressions *) ::=3D (* Identifiers *) ::=3D 'u32' ::=3D ( | '_') ( | | '_')* (* Literals *) ::=3D | ::=3D #'[1-9]' ( | '_')* | '0' ::=3D #'0[Xx]' ( | '_')* (* Utilities *) ::=3D + ::=3D * ::=3D | ::=3D #'[\n\v\f\r]' | '\r\n' ::=3D #'[ \t]' ::=3D #'[a-zA-Z]' ::=3D #'[0-9]' ::=3D | #'[a-fA-F]' ::=3D #'$'