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 Marc Nieper-Wißkirchen 21 Oct 2022 11:54 UTC

Am Fr., 21. Okt. 2022 um 13:12 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> IMHO a language feature to evaluate side-effecting expressions in
> arbitrary order is not a good idea.
>
> I can see the didactic value of such a construct in an algorithms
> textbook, but for real programs it's best to leave it to the compiler.
> The compiler's optimizer should be free to re-order or parallelize
> expressions whenever it can prove the effect stays the same.

Yes, and the SRFI 236 expression form does leave it to the compiler
where as a "begin" would impose an order (which is not good if the
programmer has to choose an arbitrary order).

> Giving programmers an easy-to-access construct with a short name to say
> "the order doesn't matter" (with no compiler check that this claim is
> true) will do its part to encourage the kind of micro-optimization
> culture that is endemic in C and C++. It leads to bugs and obscure code.
> Scheme should have fewer gotchas, not more.

It's exactly the opposite. Leaving possible compiler optimizations
aside, it is about documenting your program and clarifying your
intention.

> I can't stop the community from promulgating such a construct, but I'd
> like to ask that the name be changed to something less encouraging that
> more obviously says "here be dragons".

No direct comment on this. More generally, when you have
side-effecting expressions, there are always some dragons lurking.
When you write "begin," you make clear that the order matters because
of the dragons. No one should come up with the idea of changing the
order when refactoring the code later.  When you write  "perform", you
make clear that the order does not matter for the algorithm you have
in mind, on the other hand.  This is not a gotcha, this is inherent
when doing side-effectful programming.