Email list hosting service & mailing list manager

mutation naming conventions Alex Shinn (24 May 2023 02:08 UTC)
Re: mutation naming conventions Marc Nieper-Wißkirchen (24 May 2023 05:59 UTC)
Re: mutation naming conventions Alex Shinn (24 May 2023 08:28 UTC)
Re: mutation naming conventions Marc Nieper-Wißkirchen (24 May 2023 08:53 UTC)
Re: mutation naming conventions Alex Shinn (24 May 2023 10:10 UTC)
Re: mutation naming conventions Marc Nieper-Wißkirchen (25 May 2023 16:30 UTC)
Re: mutation naming conventions Shawn Wagner (31 May 2023 00:11 UTC)
Re: mutation naming conventions Wolfgang Corcoran-Mathe (25 May 2023 17:34 UTC)

Re: mutation naming conventions Wolfgang Corcoran-Mathe 25 May 2023 17:34 UTC

I agree that !-suffixed names are a strange choice for procedures
that don't mutate but that might expose mutation. I don't much like
linear update and I now think we'd be better off without things
like SRFI 1's reverse!.

Aside from that …

On 2023-05-24 11:08 +0900, Alex Shinn wrote:
> I'm not going to debate how important or useful call/cc safety
> it.  In the context of arrays I will likely never want it due to the
> impractical overhead it incurs, but others might want it.

This point deserves more discussion. Do we have to incur "impractical
overhead" to avoid mutation leaks? This seems to be so in R6RS or
R7RS-small Scheme, where there is no portable way to shield a mutable
temporary structure in a higher-order function from exposure.

But are there tools that could give us efficient shielding? Among other
things, Marc has talked about "liquid" bindings which are accessible
only in their native continuations. (I don't remember the details,
so perhaps he could elaborate.)

If we can have shielding for cheap, we should; if it does turn out
to be an inherently expensive kind of safety, then perhaps it would
be better to provide shielded alternate procedures for situations in
which they're needed.

Regards,

Wolfgang

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>