Riffing off recent discussion from The APL Orchard: I wonder if there's benefit to making booleans their own numeric tower of sorts

So something like b+1 is 'not' , b=b is XOR

Unlikely to want to sort a Boolean array so 2< could be bitshift instead

And if you want regular list semantics you can cast to `i (may not change underlying data repr, just the semantics of the operation)

(XOR should be ~b=b or b+b)

@chrispsn Interesting to think about whether it would be "better" if adding booleans wrapped or instead saturated. Depending on the convention it could go either way (e.g. this). If adding saturated, you could replace | with + (& being redundant with * regardless)

Although treating them as normal integers has its own uses (even extending as far as this)

splitting bools off into their own type seems like unraveling a series of nice symmetries

@JohnE it's true, but maybe there's a gain in practicality

Dicts already have different treatment to lists for a few ops (filters, for example)

It could be an opt-in thing (explicitly requires conversion to/from `b depending on what semantics you want)

I think there may also be somewhat of a parallel to the relationship between strings and symbols. there are times when you want to “crack open” something that is otherwise convenient to treat as an atom

@coltim interesting comparison!

In this context it could be useful to make derived verbs using 'under' (temporary switch to dict semantics or bool semantics, or temporary swap of domain and range)

'Dict' versus 'table' is another example of a semantics switch where the underlying data basically stays the same

@coltim not sure if it was present in earlier dialects but (boolfn)# (and _ and ^) has been one of the best parts of k9

imo the real benefit would be using an internal representation for 1/0 vectors that stored them as actual bits, in much the same way one could represent rank-2 rectangular arrays in K as actual dense matrices in memory, and decompose them into lists-of-lists only when forced to do so. afaik dyalog does something like the former?

in a discussion I had with arthur a long time ago I suggested that k symbols could be removed in favor of a generic box/unbox primitive; box a string and you get a single unit that is internable and vectorizable like a symbol, but you could just as easily apply this operation to a GUID made of integers or a small dictionary, etc

in APL, boxing and unboxing is mostly a tool for working around the rigidity of rectangular arrays. K avoided that by offering ragged lists. Boxing to control the depth of application is often useful, though, and K symbols only resolve the most common situations.

much as it is freeing and natural to generalize dictionaries to support any type as a key, it is good to be able to make any value vectorizable

@JohnE i think k9 does this - not sure about dense rank-2 matrices but i have a hunch it does?

From Arthur's descriptions it definitely sounds like k9 does that, using the narrowest number of bits (1, 2, 4, 8, 16, 32 or 64) for ints -- pretending that there's only one integer type (I). I have no idea when the interpreter would notice and down-convert today; It surely up-converts on FFI.

And it makes a lot of sense as it can be completely transparent except in the case of in place amend/dmend (which would not be in place if you need to e.g. assign 500 inside a previously 8-bit integer vector) - but would still only be visible in O(n) instead of O(1) access tim when something needs to be increased in size.

widen automatically, narrow explicitly. While it would be possible to e.g. recognize x|y&z and y&x|z as special combinations that may choose to narrow, it would be simpler and probably less surprising to have a cast-to-boolean (and cast-to-byte, etc) operation tucked into dyadic $ or something like that

I think amend-in-place needs to be a special case. Mutating a vector should truncate to the width of cells of that vector

@chrispsn I've only gotten to play around with the # version, but it has definitely proved useful! I wonder if something like (expr)<list would be useful to sort things with some custom order

@JohnE Could also throw an error there. I think this behavior overlaps with what happens when you e.g. replace the only non-integer in a general list

yeah, that might also be reasonable

is there an easy way of detecting overflows while still using simd instructions?

@ngn I don't think there's an "easy" way

I mean except ignoring them and leaving it up to the user =P (which while probably pretty far from the "mathy" version of things still has tons of practical utility)

@coltim that's how i do it now. it gives the programmer tight control over type widths but it's also very annoying having to type `i$ and 0i everywhere..

it's still mathy - the ring Z / (2^n)*Z :)

@ngn does ngn/k support other integer types? e.g. shorts/chars

@coltim i have chars (but no integer 1-byte bytes) and i'm experimenting with shorts: `h$ and 0h should work.. mostly

What about byte booleans? Or at least the e.g. 0101b syntax

@coltim yeah, if i add 1-byte integers, that could be a good substitute for bit-booleans. but currently chars are the only 1-byte type and they display as chars.

@ngn ooh. another random question: what about adding more overloads of currently unused things? e.g. <int

@coltim what would that be?

>int is close(fd), by the way

@ngn ooh didn't realize ngn/k had that! and nothing specific but it seems like a design decision

like overloading everything "just because" probably isn't great

but then one looks at the golfing languages and the standards... slip a bit

@coltim i'm trying to be realistic. i'm the underdog among implementers. very few people even care to try my impl. if i hit them with unfamiliar syntax, they'd just move on. the only chance to create something meaningful is to adapt to the syntax of a popular language/dialect.

yeh, I think following the general k stuff makes sense. more about the little edge bits that vary more between implementations (e.g. =int)

i mimicked k6. it had =int, but sadly k6 is dead.

time for a new start? :)

@ngn do you want to widen ints if they overflow?

@ktye i'm exploring the options, generally yes

having to specify types manually with `i$ and 0i is annoying

personally the fun part for me with k/apl is thinking about the operations and how they interact. all the little idioms. so playing around with what they are is the next step =P

upto where, arbitrary length?

@coltim slippery slope to starting your own impl :)

@ktye ideally yes, but i'm still far from that

ha, most of the time it just results in getting a greater appreciation for the nuances already present

and doesn't klong have big int support?

i had this in apl/iv as an option. you can switch the numeric tower dynamically.

@coltim i haven't played with klong much. it's too far from k for my taste.

@ktye what do you mean by switch tower? some ints wrap around and some turn into bigints?

@ngn iirc (some) simd has a way to store cumulatively if any overflow happened, which you can check afterwards

@ngn what did =int do?

@beagle3 unit matrix (try it online)

Thanks!

clang has some nice builtins