| Early this year, I've been suffering with @guvectorize in Python, so I don't disagree completely... Anyway: > First of all, the intent is implicit, so it won't be clear for a new set of eyes. Yep. Many times the change is obvious, like changing + to fx+ But if the change needs a big rewrite, it probably needs a good comment explaining the simple versions and the tricks to make it faster. Even better, have the functions `something` and also `something_slow` with the simple slow implementation so you can make a few test and check they give the same result. I've used that for big refactoring/rewriting, in the moment I run the two functions and the results differ by more than 1E-10, I made a mistake and I have to revert the last change (hopefully). > Author written about Guile 3, but is it also true of Guile 2 or 1? Will it hold true for Guile 4? I don't know about the details of Guile, but I know about Racket. (I guess Guile has a similar culture.) It the code is fast in the current version 8, then nobody is sure if it's also fast in the previous versions 7 or 6 or ... The compiler get a lot of tiny invisible improvements and perhaps one of them made your code fast. It's difficult to know. About version 9 ... There is an informal implicit promise to make idiomatic code faster. So I expect fast idiomatic code in version 8 to be fast in version 9. Moreover, I'd classify a big slowdown as a almost-bug and hope it's fixed for next edition. (It happened in the 7 -> 8 transition when the back end was changed completely, but the problems were rare.) Non idiomatic code is more problematic, for example if you use too many `set!` to make the code faster. I don't expect that code with `set!` to be slower in version 9, but perhaps the version without `set!` may be faster in the new release. About the changes proposed in the article, I don't expect them to cause problems in the future. Perhaps the Guile compiler will be improved to make them unnecessary, but they don't look problematic. |