From nobody Sun Jan 31 17:28:52 2021 Authentication-Results: mail-b.sr.ht; dkim=pass header.d=hagelb-org.20150623.gappssmtp.com header.i=@hagelb-org.20150623.gappssmtp.com Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by mail-b.sr.ht (Postfix) with ESMTPS id 92FC011F029 for <~technomancy/fennel@lists.sr.ht>; Sun, 31 Jan 2021 17:28:52 +0000 (UTC) Received: by mail-pl1-f170.google.com with SMTP id b8so8647923plh.12 for <~technomancy/fennel@lists.sr.ht>; Sun, 31 Jan 2021 09:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagelb-org.20150623.gappssmtp.com; s=20150623; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=wC6xYFvDtEq0HU50ITeRmdJR2bKpxdl9L+P0cp7ovSk=; b=ZIXltGS3HzdpsLExClQ8DgCTk4AItcnOIOmIWbhhNJ7Y/Fy2RsBgewm+izqDGQjj83 uzXWWTUAJN2H1tdcwCG+ig79TUqa/IqMcx9BdR+gh7tOi5t97Hxf8y0tt0+u1S3hfXp9 c31MFBKAY6GM1LadPazSx4q63+OWbgdJdJhOjGmNdqtwvJEHBKlfu1a3+yIwDL8kmup8 uWmiex+p5bsRvRJefpkxXbra5erKQWoYXNXrQf98U95Ba3qJeQLgac4PP60iEVMnasYv 9dvCs4CvAP81CWHRLdHQaMaDGMVywv7Qct5qPPgRzTfKwYTmsUCEwvrEvH8fvAd5bYic ycYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=wC6xYFvDtEq0HU50ITeRmdJR2bKpxdl9L+P0cp7ovSk=; b=ButT+k47Mt4YYcWF3pLfr11wZjhXwWyttgZJGY7om2G+ti5UfVO8UMcOX/ppjLCcEX LEAbmDxpkxZmGgX6B/4L3SM/PKmf61XeJ7OI1jezAN9LtFUDvYP0Sjsh2IgvSPJgAZUE U/WbxbljnKbe/Sh/mBEjJBp4UxAlHX7O9cgCO9iNmeDFi78YoHaxSQiaNQ+k+vXs6YEP GxGV2qoG8qNaKeoy3VJDkfnRmVKOlPYmiz1MwRGWuK7J9Tp+66jkahlNSiKgD0hqiV1W +0WtFS/pR4g9cDqA3W9UKhY4MkRWQHSwoDd28ftCVZn8KWXO5vkYbtub5k7ej/VV0E9b 0xQw== X-Gm-Message-State: AOAM531DIo+l2hSztgCz/TjizEhFMiOhRxPn29PC0QvtKIVxVnJO4puu x1qGLmc+T1tW6soTftnnKBxrnmlvC8Dacg== X-Google-Smtp-Source: ABdhPJxr4p4fV9JycGMMCG1brDMuE5kaCiEj5lupUDj7R6bFHVRTNau2+p+hkOHxPQLH8mW2C+fRKw== X-Received: by 2002:a17:90b:31cc:: with SMTP id jv12mr13587823pjb.213.1612114131551; Sun, 31 Jan 2021 09:28:51 -0800 (PST) Received: from whirlwind ([71.212.154.47]) by smtp.gmail.com with ESMTPSA id i10sm14972350pgt.85.2021.01.31.09.28.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 Jan 2021 09:28:50 -0800 (PST) References: User-agent: mu4e 1.0; emacs 26.1 From: Phil Hagelberg To: Andrey Orst Cc: ~technomancy/fennel@lists.sr.ht Subject: Re: Raw string syntax proposal for Fennel In-reply-to: Date: Sun, 31 Jan 2021 09:28:48 -0800 Message-ID: <878s89yq0f.fsf@whirlwind> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Andrey Orst writes: > So I propose a different delimiter variants for raw strings. Here's a > plenty to choose from: > > 1. r" "r - r is for raw string. > 2. @r" "r - parser macro style. > 3. r#" "# - Rust style [2]. > 4. <" "> - Quote tag style Thanks for bringing this up. I don't want to rule this out completely, but my first reaction here is "we already have two notations for strings, and I'm not totally convinced that's not too many already". In particular the first three here evoke a very strong negative reaction. > Options 1 and 2 can be increased in depth by increasing amount of `r` > symbols around the string. This seems like a downside to me. The notation is already unpredictable enough that allowing nesting just makes it worse. If we introduce a new string type, the rules around it need to be extremely simple. Raw strings should be raw; the idea of treating certain things differently inside a raw string specially seems to defeat the purpose. The only thing that's not interpreted as string content should be the closing delimiter. If you need a string which contains the closing delimiter, you'll just have to use normal strings with escaping. Honestly my preference would be to use =C2=ABfoo=C2=BB or =E3=80=8Cbar=E3= =80=8D or possibly even =E2=80=9Cbaz=E2=80=9D but ... I expect some resistance to that. The first i= n particular is very easy to input in Emacs, but not everyone uses Emacs. =3D) And I don't know how easy they are to input in other systems. But I would imagine that Fennel support modes for various languages could have commands for inserting these for you. > If raw string contains square brackets, Fennel compiler no longer can > produce simple `[[]]` string, and has to analyze raw string for having > at least one `[` or `]`. But as far as I can see this is already > done, because docstrings are produced with `[[]]` strings already, and > therefore this can be already done for raw strings too. So a raw > string with brackets like this: The idea of emitting strings differently depending on what notation was used to input them seems problematic. Right now a string in the AST is just a string. If some strings must be treated differently from others, suddenly we have to carry along metadata with it now? Even if we solve that within the compiler, suddenly macros now have to be updated to reflect the fact that strings are sometimes represented as not-strings. Seems like this would be very error-prone and confusing. Anyway, I'm interested in hearing what others think here too. =2DPhil --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEICQrrLvpWtoi0K/XgIoz03nIBsMFAmAW6NAACgkQgIoz03nI BsNxxwv/bT5LqtK0HINxKKEk5XfR9n8OTzebe6p7sFsvKodoPlC26Fuu3I8RzLhD Vzigu3HF0o3WlhBe9ZcjRSBMHPfXqWcf51zwbE/iE60ZuuGxENiQZYNiU8/H0QCd B73/0f8feJnZpkDfrQPwv/gESwyXMHGGXBGtZ49nj+FLdzQKANYhyLDCMOslgjUq p9amalHpgNrooPla18+eyD2d0PX+YxRCqc1uCPOZG0cCV0uWu3LbP6+96dBzD921 r0g3AgWSizGzlcq/qGjxXny8xPOuhn1t61w5uHg92O02qJP5+5H8J83gnu4SOiUP rklsvH/cc3BOcglSiqfcWrS0yrXACHFeVACu5rptVrOjIbVmypWQTKYc/qVN6oVa VhFHJrBr/2V0OPaIFHUYDXdVs5+Wtgn0QIyJ4tYed1y+Q2VdmL5vN5FmK0SjBfiI xQRIF/w7g7Dt1k3AiVRmQK9hjNCDlpbqnwLfwgzAs2jxCMbQRF4rTOXRlSqqHruv BCwIARR0 =njE7 -----END PGP SIGNATURE----- --=-=-=--