Question: API design for LLL module

[alxiong]

I'm a little surprised by the API design for many methods/functions under class LLL, particularly on decision between in-place mutation and immutable-functional-style, fpylll seems to choose neither.

Specifically, reduced_A = LLL.reduction(A) currently also mutate the original A which is counterintuitive. I think we should choose one of the two:

• LLL.reduction_in_place(A) that doesn't return anything + LLL.reduction(A) that doesn't mutate A and returns the reduced matrix. (this pattern can also be found in other library, such as the fft() and fft_in_place())
• alternatively, we can remove the return parameter of the current API completely and expect users to know that we always modify in place.

I find the first option more ergonomic.

[malb]

Hi, we're more or less trying to mirror FPLLL in our API since the idea is to make that, including its low-level routines, accessible for easy experimentation. This also means it is easy to shoot yourself in the foot with the library, by design. So, while I get the dissatisfaction with the API from an application perspective, I'm not too keen to change it drastically.

But perhaps an additional high-level API could be defined and added as a submodule?

[alxiong]

I see, that's fair. Thanks for the clarification.