[exitb]

You probably shouldn’t do those things. The point of a high level language is to not have to think about such details. If you can’t get the performance you need, you should use a different tool, instead of trying to circumvent implicit limitations.

[gus_massa]

Sometimes you can write mostly high level code and only add trick and annotations for speed to very hot loops.

[exitb]

There are two major problems with this approach. First of all, the intent is implicit, so it won't be clear for a new set of eyes. Second, by peeking behind the curtain you can get some gains, but only as long as everything behind this curtain stays the same. Author written about Guile 3, but is it also true of Guile 2 or 1? Will it hold true for Guile 4? Anybody's guess really.

In contrast to this approach, I'd point at Numpy. It optimises specific cases in Python code, but does so in an explicit way and its interface is even sufficiently high level to match Python well.

[gus_massa]

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.