Email list hosting service & mailing list manager

raw string literals lloda (16 Jun 2022 19:52 UTC)
Re: raw string literals Per Bothner (16 Jun 2022 20:08 UTC)
Re: raw string literals Lassi Kortela (16 Jun 2022 21:49 UTC)
Re: raw string literals lloda (17 Jun 2022 17:44 UTC)
Re: raw string literals Arthur A. Gleckler (17 Jun 2022 17:52 UTC)
Re: raw string literals Lassi Kortela (17 Jun 2022 19:59 UTC)
Re: raw string literals lloda (17 Jun 2022 17:34 UTC)

Re: raw string literals lloda 17 Jun 2022 17:44 UTC


> On 16 Jun 2022, at 23:49, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
>>> I have prepared a draft SRFI for raw string literals. The draft is here: https://github.com/lloda/guile-raw-strings/blob/master/srfi.md, but I describe the general ideal below.
>
> You may or may not want to add it to our unofficial pre-SRFI collection for early review:
>
> https://github.com/pre-srfi
>
> #r syntax has prior applications in Scheme and Common Lisp:
>
> https://registry.scheme.org/#hash-syntax
>
> http://clhs.lisp.se/Body/02_dh.htm

Thanks, I had wondered if something like that existed. I see some gaps, for example I don't see the SRFI-4 prefixes.

#r for numeric vectors seems redundant with #f32 and I'd probably wouldn't mind stepping on that, or on the CL conventions.

But if there's already an SRFI with its own characters for the same functions then of course it doesn't make sense for me to propose different ones. I was simply unaware of SRFI-109.

Regards

	Daniel

>
> Lisp has an unusually sparse lexical syntax, so expect pushback against any suggestions for new syntax. But the SRFI process will host any reasonably presented proposal.
>
>> I suggest taking a look at the extended string literals of SRFI-109
>> (https://srfi.schemers.org/srfi-109/srfi-109.html).
>> They are implemented in Kawa.
>> SRFI-109 literals reduce the issue with nested escapes.
>> One reason is you can use the delimters '{' and ']' in
>> the string without quoting as long as they're nested properly.
>
> +1