List Commands Library for 50g

[3298]

(09-06-2017 02:22 PM)DavidM Wrote:  I'm actually using a variant of that technique quite a bit in the library -- instead of ticR (which returns the boolean), I've been using 'R (which only returns the object). I actually learned the technique when tracing through one of the built-in routines (probably DOLIST), and it is indeed a nice way to handle things in certain cases.

Told ya, there's always someone who knows the trick already. I used ticR because it tells the surrounding code when the list ends, but 'R is fine if you do that another way. DO ... LOOP doesn't use the return stack, so combining these may be a simple way to avoid that RSWAP hassle while keeping the benefits.

(09-06-2017 02:22 PM)DavidM Wrote:  For small lists, it's actually slightly slower than "explode/ROLL/ROLLD", but the difference isn't great enough to make up for the benefits it provides. In particular, it's very nice as a means to almost have a "spare stack" to draw objects from that doesn't cause you to have to juggle others. And as list sizes grow, its measurably faster than the ROLL/ROLLD sequence.

Yes, that's what I expected. I didn't throw the profiler at it, but ROLL/ROLLD needs to move a block of memory (part of the stack) which scales linearly with the list size, ticR and 'R are done in constant time (ignoring the possible garbage collection, because if that kicks in, it would have done the same in the explosion step). The "spare stack" argument applies to a major case I used ticR in too; it involved iterating over a list of variables and doing some complex operations on their contents with no return value (searching a project for INCLUDE directives, as part of my CRLIB replacement; the "return values" of the routine were appended to LAMs). Having to deal with changing offsets to the values I stored on the stack wouldn't have been pleasant, so having the option to stash the list somewhere else without slowing down the iteration process (like a CARCOMP/CDRCOMP combo would, which would also be a major memory hog) was a gift from heaven.

(09-06-2017 02:22 PM)DavidM Wrote:  Please continue to chime in with these suggestions! Although I already knew of this one (or its cousin), there's tons that I don't. I occasionally see things like this when tracing code with Nosy, and it can take a bit to figure out what it's for. This one caused me some head scratching until I actually copied some of the code and stepped through it to understand it better.

Will do whenever I find something useful. For now, I'll tell you some more details about my ticR use:
I guess you read the text file that comes with Nosy? It contains some programming tricks in its last section. In this context one of them could be interesting, filed under "Advanced looping". It consists of an optimized replacement for the indefinite loop structure, and I've combined that with ticR to write my own fast iteration program. In the process I found a workaround for the problem created by the presence of COLA_EVAL (namely evaluating the top of the stack). This is the code - as usual, if it works for you, don't hesitate to use and/or modify it, I'm sharing it for the greater good.

Code:

::
  >R IDUP RSWAP ticR
  NOTcase COLASKIP RSWAP
  3@REVAL AGAIN
;

It may not be immediately obvious, but it takes the list from the stack and the operation from the runstream, so assuming it's named iterate, this will calculate 0+10+11+12:

Code:

BINT0 { BINT10 BINT11 BINT12 } iterate #+

Taking the operation from the runstream makes it necessary to skip it afterwards, so I was able to replace COLA_EVAL by COLASKIP, avoiding the evaluation problem.
This might be just a little bit faster than other loops doing the same. Stupid me made this speed advantage mostly irrelevant by using a ROMPTR as the operation, though. In hindsight, I should have done this:

Code:

' iterate ' my_romptr ROMPTR@ DROP TWO ::NEVAL

instead of

Code:

iterate my_romptr

because using the ROMPTR directly as operation recalls its contents on every iteration.

(09-06-2017 02:44 PM)DavidM Wrote:  

(09-06-2017 01:52 PM)3298 Wrote:  The downside is that you need to dive into SysRPL, obviously.

Why is that a downside? That's been my preferred environment for 48-50 coding for some time now. The ListExt library is entirely a SysRPL project, except for 20 or so Saturn routines strategically placed to enhance performance.

Not a downside for us, of course. Just for those poor fellas who read this thread without having prior SysRPL experience.