From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id uHEEO7hZBGZdzAAAqHPOHw:P1 (envelope-from ) for ; Wed, 27 Mar 2024 18:39:05 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id uHEEO7hZBGZdzAAAqHPOHw (envelope-from ) for ; Wed, 27 Mar 2024 18:39:05 +0100 X-Envelope-To: patches@johnnyrichard.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=V8iPECGl; dkim=pass header.d=johnnyrichard.com header.s=key1 header.b=zZpJFSw8; 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=quarantine) header.from=johnnyrichard.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnyrichard.com; s=key1; t=1711561144; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: 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=FTybC4BafEnUVISssz1zakMDryQJX11tG0RNB11yuHw=; b=gbO8QLuu+J8n84GnGZCJ/DE8UwAzJJrqaIRBE8/cQ1uVC6dtXvpb+kVYxSxLroKO+Xy4s3 XvFCueokBN+4EH1DhDZ9IkmscZToaYfiAx/sfJq0XZOZShED1KkCBBoiAPWuFV/z9SH8KA Gj8UrhqMJcRhDuvybr9IubsARyx28C8Y5EHAdfmv24a/8EmPctZv+c9VHpzOqwfR544+DS fAwA0Uf/mIZcMzLly12ByJEJrrZu4r4yBFRCKS7w0DqI/82hL2NulvZ4ENKTlbmHF+NS0A DXDEBmfo9i9hhOGpyqAs68FjWDa+Vlz1GbmqWPYqvp1XubpXpArXNONeJHKw0Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=V8iPECGl; dkim=pass header.d=johnnyrichard.com header.s=key1 header.b=zZpJFSw8; 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=quarantine) header.from=johnnyrichard.com ARC-Seal: i=1; s=key1; d=johnnyrichard.com; t=1711561144; a=rsa-sha256; cv=none; b=ATZyn0Hjd4/ktD17lJM2eMeDeWqyVxhfp56H5qhX4KTrZSpLoVc1GTNV06j6ot4qW6fQKT yJbjyaBqGzSQqigCTbkIiMxk4uJ7PqFGhzgc8f/7KMFCBYPN6QqdE4ZgS8u+GDxjB1CUt6 zD3MUDCvEYnJ31e2FXJQ8pfKJrSNplw/gVnQa2V/oh8kvMzGaW0nMWs5iYDO3lgI+1SqgJ eyGEE7Smfh3obguTsigk3NRLCk8ANZmDRqt+S+UiEBMq0txhEGp3VT9ApdOAOV7YR4usvW JZKIyuJOKhavM2R7hq+T6850j1BdJRBEeeLBxlcXmBOp98o8KzDb0bUDvXZOcg== 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 DCB166DDFF for ; Wed, 27 Mar 2024 18:39:04 +0100 (CET) DKIM-Signature: a=rsa-sha256; bh=Su2N7X2jxt+BSJZ1mCez/BsdbQ6vUbKV2dbl2NJ8Krs=; c=simple/simple; d=lists.sr.ht; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-Unsubscribe:List-Subscribe:List-Archive:List-Post:List-ID; q=dns/txt; s=20240113; t=1711561143; v=1; b=V8iPECGlytALUIZ+pCUO6IJQmoLjAj21wC2kdA6DA0OTYLQQC0UlGtlj78yvWjbBH4Bp9KJn YG2EIBvv79nCDuv3qdNOIk3wo/vT5f1iWc2RbIEXg/9nKNLthOCNRisa/FF2hT1pgIQjiGMelaN 7nMrVuy/aaOQSGhBGJsxwjhfC0KPTKhRxVOf03IJkbrnsA2L/ev+tPtuyRTVTTfQQVkeMeFbvqU WYhu2AuKogDaQ0cL5aHfxSttoi/EnWyDnZ4u7L4hxyCb8K93dP+qYNPgriLo3Y9k3oD4X1Hb5c8 atl95MiDWuFMTb/WqUlyPpVGVkhOdb7kVuqOJZIRG99nw== Received: from lists.sr.ht (unknown [46.23.81.154]) by mail-a.sr.ht (Postfix) with ESMTPSA id 36DF72026C for ; Wed, 27 Mar 2024 17:39:03 +0000 (UTC) Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by mail-a.sr.ht (Postfix) with ESMTPS id 805A720265 for <~johnnyrichard/olang-devel@lists.sr.ht>; Wed, 27 Mar 2024 17:39:02 +0000 (UTC) Date: Wed, 27 Mar 2024 19:39:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnyrichard.com; s=key1; t=1711561142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FTybC4BafEnUVISssz1zakMDryQJX11tG0RNB11yuHw=; b=zZpJFSw86iOgk56UVllPG/tn0HF0yaduhbaHVHncw7BLMVlocy9yQw/TeT3vMl63+GK3uk KFeEeykOMEgaTeydQuoGNhWBq9bidywWjIhbxaajp5e/c4OylrBkbJMgXLZTeuugHY2IDE VGz2/7pUqVF9moTvJvkLTvF3EWm7KVXa0AxWkYhkDW8d3pmtYv1ZHTcyTuYPhmjOllm+EF 2HbKt7fGgtZpXV7OrmlmoSb6WAVbyF0cQMucSNU/IYThcgASH9eDEz1bfZy4nOvqJw1gPT XCHZkOojm5QE4vGvCkM0MBHqPCPXe0+5atN8KdBPgVfoVMrYDHkDMguM/jYvvw== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Johnny Richard To: Carlos Maniero Cc: ~johnnyrichard/olang-devel@lists.sr.ht Subject: Re: [RFC] Namespaces in OLANG Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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-Queue-Id: DCB166DDFF X-Spam-Score: -10.10 X-Migadu-Spam-Score: -10.10 X-Migadu-Scanner: mx10.migadu.com X-TUID: sLqhFFrwQURU Thank you very much for providing this insightful reading material. Although I've appended a few comments, I'm hesitant to make significant decisions at this early stage of language development due to my limited expertise. However, if you're confident in the direction proposed, I won't obstruct progress. On Sat, Mar 23, 2024 at 11:46:46PM -0300, Carlos Maniero wrote: > Using namespaces in olang > ------------------------- > > Before we begin, I want to ensure that we’re all on the same page regarding the > following points: > > 1. Deterministic Code Generation: Our goal is to be able to examine an olang > function and precisely predict the assembly code that will be generated. > > 2. Full Compatibility with C: We aim for seamless integration with C. We don’t > 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 additional > boilerplate. > > 3. Manual namespacing is inconvenient: While it’s possible to create 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 create > macros in C to improve the readability, but completely optional. > > #define NSMATH(name) olang_core_math__##name I think this is too ugly and very hack. I would prefer to call olang_core_math_add instead. > 3. Manual namespacing is inconvenient: > > You don't need to manually namespace every function with the cost of start > every single file with a *ns* statement. If we keep managing names manually, we already have the *1* and *2* for free. So, the only benefit of namespacing would be to avoid the inconvenience of adding it manually. > An important observation of the *ns* usage is that it must match the directory > 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: I know we don't have written down nicely the goal of the language, but I prefer being explicit and avoid convention over configuration. > 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 compatibility > with C. The current suggestion doesn't solve the all compatibility with C. We have to provide a way of calling a C function from olang code without namespacing (in case of namespace being mandatory). > - It simplifies the resolution of imports. I would suggest to not go much further with import resolution (unless you already want to define modules). Perhaps we could have namespace doing nothing else than namespacing... > These advantages come with the minor stipulation of initiating all files with a > namespace statement, which, in my view, is a small price to pay for the > benefits gained. I'm not keen on the idea of enforcing strict adherence to the folder structure. How about we introduce a namespace block instead? Within this block, everything would automatically have the namespace added as a prefix. This could offer more flexibility while still maintaining organization. > 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. I think module has a different meaning. If you want to have modules, for sure we have to discuss import resolution. IMHO namespace shouldn't do anything else than namespacing. > 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 file > in the AST and the program node does not seems appropriated for it. Today we can use the "new" as the main entrypoint for a source file. Could we use this AST node to attach the file path to it? Or even better, is there a way of embed the .ol file into the ELF binary?