What's wrong with your HEAD?

[DavidM]

(10-08-2018 10:06 AM)3298 Wrote:  Yes you could add something! ... well, to your list commands library.
...
If you want to be even more efficient, you could investigate how stable PTR 1933C is across ROM versions (or at least across the ROM versions you want to support), and possibly use that in place of the innermost embedded subprogram.

(10-08-2018 11:03 AM)Werner Wrote:  That's why, in my GX library for the SX, I implemented HEAD as
...

^ErrBadDim (FPTR 6 92) appears to be a supported flash pointer that performs the # 501 ERROROUT sequence, at least on the supported platforms for ListExt.

I certainly don't mind including a list-focused HEAD replacement in ListExt ('LHEAD' definitely follows the established naming convention ). Both of the above approaches are able to check for an empty list and isolate the first element fairly efficiently, and a preliminary check on an emulated system shows them to perform similarly. I'll follow that up with some tests on a real 50g when I get a moment, but I'd be surprised if there were any meaningful performance differences between the two approaches. 3298's is a couple of bytes smaller, so I'd lean in that direction if there's truly no performance difference on real hardware.

(10-08-2018 02:08 PM)pier4r Wrote:  In the listExt there should be already LPOP or LPOPR to have a sort of head behavior, isn't it?

The big difference with LPOP/R is that they leave the residual list elements on the stack. This means that they both have a need of traversing and copying the entire list in order to return the complete results, thus incurring the performance penalties both of those steps require. The main benefit of something like LHEAD is that it would only need to deal with the first element, and thus it can operate much faster than something that has to scan/rebuild the entire list. If you don't need the residual list elements, LHEAD would be significantly faster than LPOP NIP.

Nice discussion!