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