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