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.