From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:1008:1e59::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id OJWJMJ1v82XoAgEAbAwnHQ (envelope-from ) for ; Thu, 14 Mar 2024 22:43:57 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id mO+zLZ1v82VPDAEA62LTzQ (envelope-from ) for ; Thu, 14 Mar 2024 22:43:57 +0100 X-Envelope-To: patches@johnnyrichard.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=jrPIyltV; dkim=pass header.d=johnnyrichard.com header.s=key1 header.b=z0qkzLBc; 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=1710452637; 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:in-reply-to:in-reply-to: references:references:list-id:list-unsubscribe:list-subscribe: list-post:dkim-signature; bh=BHKBMEm3EQXLZ9SwoXOrEozIEa/rlsT2TP4g/1yALs8=; b=Ia/KD3HQ+9B/5FrZzn2bRpG734bm3ZKsqhloV+1lnjYvLFNUaWllyDgM8mxbHo34mkRZwU wX+IQcV7desPka1uL4ajF4aWoM64WuEKscOKDOnFTvLt7T41Rr0Dr4mzy8RJhwqdCIrtIw Tk4U6yVmUGtjHTcaaYResoAm7dtgCZW9UYeRtEPo+07W+BXeJAQ8zDTgFQ8J0f+oFbkU6t crRknMPWkcJloC2Q0tsKr/1vfgL0b8mNM+TR+8AWIeTJ2cU2b95sen+vtXtopxM9ctv7yK s5FIqfrsRTddOBOLie3oI1SkcJRC82iXONm5IErHZXEZc8wL5jevHC9Hx7lsGQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lists.sr.ht header.s=20240113 header.b=jrPIyltV; dkim=pass header.d=johnnyrichard.com header.s=key1 header.b=z0qkzLBc; 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=1710452637; a=rsa-sha256; cv=none; b=b0nw4cLxtH9P1+jVCVtRzvf9wU27Vt2BHOvKmncoToxqBbVZQ90PFx1QwskcOcwx2bkZTe 9HbCO0nbFPVtvMoGwgRFHYFd2MUV2++vChkwpJqNNiUIOEoVtG0s2VvtfMj1zdjZDA8GRa y6jwdyMWYaaqY3L3U3rGIwrR5rETWHuXzV0SR7rEkj/aZ3sgMRyV7sFvb/G1/6Af9SiUd9 90wZdTomExLpsk17bdi/R/OrtyIC5b/bsQL6f4dL91QAtbRQQureMaWOOSGYvOPrLAYeTj 11fdT8dZENlJxCCfdq583DdfhyPZvq6lOw/Y/O+jikjQVy6ZSsRmZXi3c1jmjw== 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 A37581625E for ; Thu, 14 Mar 2024 22:43:54 +0100 (CET) DKIM-Signature: a=rsa-sha256; bh=byeLk6BbCbUH4OuksSjjucp9Wcoozjhzd8BHrLEJSU0=; 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=1710452633; v=1; b=jrPIyltVTSaCgLqCLAhOLXPtu1MFbYf1dI3LsDPrV31WitnHUQOfLKd+XAMHNDF63D0uQX3K IP3Rcygpjrvq3RUSPRq/mAwHmu7uNyv7az+Vrbon8greZj2oWsi9iMzjq5JrUnV8GTcnDBCIyDE G/AdjCoTe+ZNtvf7hIDvpcE6evf1NDj5LiI1ASpC7OJjE/3sFsaVsostMqmEdVgbr/ED3To+XnF fYxGIdcZwmECULerBB3XvzHyzXfLZfhltem+Gi8F+AZwihfxTC2YZzRQc8Fwbduj84vYmiOkvzN ReQRqflC6P8HM4PCsWwpoigTKZvZ8m5M5jAduL4+uvQRw== Received: from lists.sr.ht (unknown [46.23.81.154]) by mail-a.sr.ht (Postfix) with ESMTPSA id DA8D62027E for ; Thu, 14 Mar 2024 21:43:53 +0000 (UTC) Received: from out-185.mta1.migadu.com (out-185.mta1.migadu.com [95.215.58.185]) by mail-a.sr.ht (Postfix) with ESMTPS id 1D47620114 for <~johnnyrichard/olang-devel@lists.sr.ht>; Thu, 14 Mar 2024 21:43:53 +0000 (UTC) Date: Thu, 14 Mar 2024 23:43:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnyrichard.com; s=key1; t=1710452631; 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: in-reply-to:in-reply-to:references:references; bh=BHKBMEm3EQXLZ9SwoXOrEozIEa/rlsT2TP4g/1yALs8=; b=z0qkzLBcioFUNk+3zMYZ30NqV2iRcB7eYc48VDcUobCn6PWZt9ltO2I/q6FDtNV503zBFw w3xxxIbPIyNvEw9IQOAOk6y+duG7IDSlceG+wcoE4TxOrhgrG6cd4rEb1ETwqab3s8Mgks Ihhx/BKZJP9MC68QudfaILax3cHdGBAQuK1YqGSKKWMgN5k/NtN6yOzWCimkTkVDsTFK6e SDeUwRQ/CKzIyU8nF2jUyLP5567+S93nt5T4BkYgBYPJbPzGrIXKh82r0OjDjqX0d/jWeY zcNCD6duinlifFrCVu7Tgp0ZCtsFQxDNa/Oj7Ox4FA1vF7fP02tu6yyl66O7oQ== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Johnny Richard To: Ricardo Kagawa Cc: ~johnnyrichard/olang-devel@lists.sr.ht Subject: Re: [olang/patches/.build.yml] build success Message-ID: References: <88cb1a82-809e-4db5-95cd-2bbe828d0166@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88cb1a82-809e-4db5-95cd-2bbe828d0166@gmail.com> 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-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -10.07 X-Spam-Score: -10.07 X-Migadu-Queue-Id: A37581625E X-TUID: NCDGv8BkS9nU Thank you very much for you contribution, I love it <3. nitpick for next replies: 1) You've replied to the CI build reply. Next time try to reply to the right thread. 2) Your message has few weird line breaks. I don't know why it's happening (noticed you are using Thunderbird). However, you can make sure your setup is correctly configured to send plain text emails by visiting this website https://useplaintext.email/ On Thu, Mar 14, 2024 at 01:29:09AM -0300, Ricardo Kagawa wrote: > >> This grammar adds the token SEMICOLON (';') for every statement. I know > we > >> agreed make it optional, but the SEMICOLON makes the parser much more > >> convenient to implement. > >> > >> And this is the first topic I would like to discuss. Let me know if you > >> agree otherwise I can adapt the grammar to make SEMICOLON optional. > > > > (...) Therefore, I'm curious about your statement that using a > > semicolon makes the parser much more convenient to implement. Could you > > elaborate on this? Have you encountered any new considerations that might > > complicate the implementation? > > My limited understanding is that the semicolon would indeed be more > convenient, as it would be a definitive end-of-statement symbol, > requiring no lookahead to resolve as such. The LF token could be > ambiguous on its own (between end-of-statement and white space), so > some lookahead would be required to resolve it. You are right about it. I had to implement the lookahead capability in order to skip LF tokens. > But it should be alright, as long as the language remains context-free. > Even if it becomes ambiguous, non-deterministic, or requires a long > lookahead. Ideally it should be determinitstic for linear time > performance, but it seems there are parsers that can run close to it in > the average case, as long as the language remains close to > deterministic. > > And I don't have a strong opinion on the semicolon issue, except that > it must be an option. But whatever we do, we must avoid the following > pitfall from JavaScript: > > ```javascript > example > ;(x) > ``` > > The semicolon is mandatory here, because otherwise `(x)` is handled as > an argument list, and `example` would be called as a function. That is, > it would be a multi-line statement, instead of two separate statements. > > And why anyone would do this? > > ```javascript > const x = y.example > ;(() => { > console.log(x) > })() > ``` I strong agree on avoid those odd JavaScript design. I think we can continue with optional SEMICOLON. I also think it makes a better programmer experience. > >> The grammar was made by using a EBNF evaluator tool[1]. > >> > >> [1]: https://mdkrajnak.github.io/ebnftest/ > > > > I would add this link at the markdown, so then people can play with it. > > I would make an even stronger argument for including the link in the > docs. A good language specification also specifies which language > specification grammar is used for the specification itself. And the > EBNF in particular is not properly standardized, so you really need to > specify which EBNF variant you are using. > > The link should thus be good enough to refer to the EBNF implementation > used in this specification, although a permanent (version locked) link > would be better. Sure, I can add it to the document. I'm not sure how you want to version lock this variant. Should I add a specific github/git tag version to the document? > As for my revision of the grammar: I liked all comments and definitely it seems to be better version. In my option we can start with you changes and keep this document alive for future discussion. Not sure about Carlos. Let see his thoughts on that as well. > Further discussion: > > - Is the language going to support Unicode? If so, `` could use > the _L:Letter_ Unicode category instead of being limited to > `[a-zA-Z]`. But the EBNF tool does not support Unicode categories in > its regular expressions (it does not support flags). Also don't > forget to rename it to `` in that case. > > - It would help developers in non-English speaking countries, but it > could be difficult to work with multi-byte characters and Unicode > normalization. I lack knowledge to answer this question right know. I would say to keep it simple as much as we can on this earlier stage (ASCII only) unless you have a big concern. > - There are more linear space and line break characters than the ones > included here, even within ASCII, although they are not all that > important. Even more in Unicode (some under _Cc:Other/control_, > others under _Z:Separator_). Should we support them? Let's add the remaining ASCII ones meanwhile. > - The function definition could accept a single expression as an > alternative to its ``, similar to Kotlin. Scala also has this capability. But I think it doesn't fit well in our current function declaration: fn f(): u32 ^ If we don't add a token in here like **=** it will be very weird. No strong options here to be honest. > - The integer literal could include optional underline separators for > readability. Just need to be careful not to start with underline, to > avoid ambiguity with identifiers. I like that. We can have it as well. > - I guess we don't have to support the full set of Unicode digits, since > we don't know if these digits would even be decimal in the first > place. The numbering system could be very different from our own, so > it is likely not feasible to support them. Perhaps we could postpone the Unicode support? > - I have not checked if this syntax would avoid that edge case with > JavaScript I mentioned in the beginning. I might check that next > time (I'm still not sure of how). Maybe we are going to discovery it on the implementation process. > - It might seem strange that I included semantic non-terminals here, > despite having removed non-terminals for symbols and keywords. I can't > say for sure, since this is my first time trying this style, but I > suspect that besides making the language specification easier to > understand, the important bits to hook into in the parser will be > around these symbols. That is, it could simplify some work on the > parser. ACK