Am Sa., 22. Okt. 2022 um 00:32 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

[...]

> Agreed - imperative code is tricky in general. In a perfect world
> everything would somehow be declarative, which would automatically give
> the compiler a precise and correct specification of where order matters
> and where it doesn't.
>
> To get Haskell levels of safety you need static types - something we
> can't add to Scheme. IIRC the research language Koka manages to do full
> inference of effect types, but the price is an even more complex static
> type system.

Having a static type system is orthogonal to banning mutation, isn't it?

> > Or take first-class continuations (delimited or not).  They make code
> > hard to reason about, but (as I think) they have their niche in
> > well-encapsulated modules.
>
> Agreed. All useful languages need to make compromises, but they are best
> tucked away in a clearly indicated "unsafe" corner.

I think that the adjective "unsafe" is not the correct one here.  I
would call language features that breach abstraction barriers unsafe,
e.g. "peek" and "poke" in Basic.

[...]

> > Here we have to agree that we disagree.  I find it harder to reason
> > when superficial assumptions are made (like the order of evaluation
> > when it doesn't matter).
>
> Well, harder to reason about intent but easier to reason about what the
> computer will do :) It's a tradeoff.
>
> > In any case, we probably fundamentally disagree on that part of
> > Scheme, which is touched by this SRFI.  Thus, it is probably pointless
> > to carry this discussion further.  If I understand you, you think it
> > is best to withdraw this SRFI.  From my point of view, many points you
> > raised speak actually for this SRFI.
>
> It seems we disagree only about priorities, not about the facts as such.
>
> It's not my place to ask anyone to withdraw a SRFI. Just pleading to
> clearly label parts of the language that don't offer the usual level of
> safety.

First of all, I think it is your right to ask to withdraw a SRFI
(proposal) if you feel like it; in fact, if you think a SRFI does more
harm than it does good and that it is fundamentally flawed, you
probably should ask to have it withdrawn.

If you don't see it that drastic, feel free to suggest different names
that you think would better carry the meaning of the "perform" form. I
just defy calling the form "unsafe". There's nothing unsafe about it
in the usual sense of unsafety. (For, otherwise, every procedure
evaluation and every "let" form would be unsafe, as well as would be
"map", etc.) The name should not be too complicated because people
should be encouraged to use the form whenever it carries the semantic
content better than "begin".