Please change the name Lassi Kortela (21 Oct 2022 11:12 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (21 Oct 2022 11:54 UTC)
Re: Please change the name Lassi Kortela (21 Oct 2022 13:03 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (21 Oct 2022 13:16 UTC)
Re: Please change the name Lassi Kortela (21 Oct 2022 14:31 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (21 Oct 2022 15:00 UTC)
Re: Please change the name Lassi Kortela (21 Oct 2022 16:25 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (21 Oct 2022 17:43 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (21 Oct 2022 18:10 UTC)
Re: Please change the name Lassi Kortela (21 Oct 2022 22:32 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (22 Oct 2022 08:03 UTC)
Re: Please change the name Lassi Kortela (22 Oct 2022 11:30 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (22 Oct 2022 11:39 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (22 Oct 2022 11:53 UTC)
Re: Please change the name Marc Feeley (22 Oct 2022 12:19 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (22 Oct 2022 12:29 UTC)
Re: Please change the name Lassi Kortela (22 Oct 2022 13:17 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (22 Oct 2022 13:26 UTC)
Re: Please change the name Marc Feeley (21 Oct 2022 13:17 UTC)
Re: Please change the name Marc Nieper-Wißkirchen (21 Oct 2022 13:26 UTC)

Re: Please change the name Lassi Kortela 21 Oct 2022 22:32 UTC

> Actually, my idea of the "perform" form was born from problems arising
> from a piece of imperative code, which would have benefited - at least
> in my mind - from a perform form.  Most forms of imperative code are
> not easy to use correctly, but only a few programming languages are as
> radical as Haskell.

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.

> 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.

Arguably call/cc is advertised too readily, but it's difficult enough to
use that people are thereby discouraged from using it a lot.

Common Lisp is unsafe if you do (declare (optimize (safety 0))), but
that expression clearly communicates you intend to disregard the normal
safety guarantees.

> 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.