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 Lassi Kortela 17 Jun 2022 19:59 UTC

> Thank you, it's clear I failed to search properly in the SRFI body (I searched rather cursorily for 'raw strings').

https://srfi.schemers.org/?keywords=reader-syntax (Filter by keywords ->
Reader syntax). Not easy to find, but it shows all SRFIs that add new
lexical syntax.

> The only remark I have is that SRFI-109 is not a simple SRFI, so there may be some value in providing just those basic features in a way that is compatible with SRFI-109.

Yes, simpler subsets of more complex functionality can be useful.

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

Thanks, I didn't realize something so common was missing. Now added.

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

Lexical syntax should be regarded with more reverence than most language
features because it's close to the core of the language. Scheme (and
Lisp) could really use more features in the string syntax, but if it's
done for a few implementations only, the new syntax will make it more
difficult (rather than easier) to write portable code and to understand
unfamiliar code you read on the internet.

String syntax is central enough that ideally some kind of "council" of
Lisp implementers should come together and get it right once. But that
is wishful thinking at this stage.