fuzzball-muck/fuzzball

Add flag? MPI Function

tanabi opened this issue · 2 comments

This is the equivalent to the flag? MUF prim.

Calling signature:

{flag?:#ref,str}

where 'str' is one or more flags to test for. 'M' flag will ignored and a number will be used for MUCKER bits. So, thusly:

{flag?:#123,ACBM3}

and

{flag?:#123,ACB3}

are equivalent. This isn't a hard requirement; if there's an existing library function we can use to check multiple flags by string (I don't remember off the top of my head, but check around first!) then use it and have the function work whatever way the existing code works. But I'm about 80% sure there's not an existing call.

Returns boolean true if all flags match, boolean false if any flag isn't set.

I think all flag-checking is currently for one flag only. In fact, since FLAG? also needs to recognize flag aliases, I was going to propose this suite of flag-manipulation processes:

These primitives already exist but recognize aliases.

  • SET - sets or resets a single flag
  • FLAG? - checks for a single flag

These new primitives would check for multiple flags.

  • SETFLAGS - sets or resets at least one flag - no aliases
  • FLAGS? - returns 1 if all the given flags in the argument string are (re)set, else 0

These MPI functions could be analogs of the above.

  • {set} / {flag?} for the single-flag case. Not strictly needed, but consistency can be good.
  • {setflags} / {flags?} for multiple flags

And finally...

  • @flagset to set multiple flags via a command. I thought the name could mirror @propset, but there's a case for making it @setflags.

Or...

  • We could make the single-flag versions recognize multiples, though that seems messy for the current primitives.

I'm currently trying to unify all flag management functions under the hood (slow-going), so this is very relevant. I haven't added an issue yet since I'm still working on the approach. Feel free to, though, if you think the flag code needs updating too!

This all sounds very sensible to me. I think @flagset is fine; @setflags does have a logic to it, but I think the consistency with @propset is good and I anticipate that being kind of a rarely used command. In fact, I'd say do it only if its easy, I don't think its really worth a high degree of effort. Especailly since it would be trivial to implement in MUF if someone wants it given the new prims.

The rest, looks good to me!