Ruud H.G. van Tol on Sat, 30 Sep 2023 14:32:24 +0200

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: bug in simplify_shallow

On 2023-09-30 13:27, Bill Allombert wrote:
On Sat, Sep 30, 2023 at 01:10:23PM +0200, Ruud H.G. van Tol wrote:
On 2023-09-29 23:05, Bill Allombert wrote:
On Sun, Aug 27, 2023 at 05:01:07PM +0200, Ruud H.G. van Tol wrote:
On 2023-08-27 16:13, Karim Belabas wrote:
[...] What Bill and I suggested was to return "a copy of the
inserted element"
instead. I don't really see a scenario where this would break
compatibility ... except this would make insertion about twice slower,
even in cases where the returned value is ignored.
Yes, so I wondered if the "void calling context" is decidable at
compile-time, such that any new overhead can be avoided where feasible.
Indeed there used to be a bug in the compiler that I just fixed
that caused it to fail to take the void context into account in
some case.
Thanks for the changes and fixes!

(also for not making it return the final length of the list ;) )
Well, there still the issue that

? my(L=List());a=listput(L,5)
? a
%2 = 0

because GP convert void to 0...

And listpop() acts similar:

? my(L=List([42,43,44])); a=listpop(L); #L
%2 = 2
? a
%3 = 0

Maybe have an enabled compiler-error for such, to avoid surprises.

default(strictvoid, 1)

P.S. In paridecl.h, comparing listpop:

  void    listpop(GEN L, long index);

shouldn't these now also be void?

  GEN     listinsert(GEN list, GEN object, long index);
  GEN     listput(GEN list, GEN object, long index);

(or does GEN cover that already?)
GP uses listinsert0 and listput0 which returns void.
I have kept the return value for the C functions.

I presume that is good practice, to prevent breaking something at a distance.

-- Ruud