@coltim I think the verbs are leaky, rather than dicts per se

note for later: make primitive text resize to fit on one line

bit of a problem here: k.miraheze.org/wiki/Within

@Razetime it'd be so much easier to only have to target documenting one K version =|. for example within in k4/q is inclusive on both sides

it's important to be comprehensive in a wiki

thanks for the info

ngn/k, (c) 2019-2021 ngn, GNU AGPLv3. type \ for more info
 0N#0
,0

surprised by this

@chrispsn true. and I am not against dicts (or even further extensions like tables) by any stretch, they are incredibly useful. if anything, I prefer prioritizing pragmatic/practical usecases

@chrispsn it's a no-op, matching the behavior of 0N_x. useful when combined with x?y returning 0Ns

@coltim ah interesting

like dropping the first instance of a given value and everything after it, without needing to do anything special to handle instances where the value isn't present. i.e. (x?y)#x

interesting that #x for 'not found' gives that result for take but (obviously) not for drop

maybe a wiki page could be 'trade-offs of null'

@chrispsn they're somewhat easy to workaround, either with (#x)^x?y or with (x;0N)x?y (any desired not-found value could easily be swapped in to either), but I just like nulls more than lengths

also worth noting that in k4 x^y with a list x also fills (not just with a scalar x). which makes it more like a blend operation which also has its uses

@coltim "dict_key matches list_index too" - yes, that's why i liked your suggestion to implement _ that way :)

@coltim "empty lists falsey in conds" - aren't they already?

@ngn oops, yep. got mixed up when porting something from oK

@ngn what about this? it's messy but anything other than i_dict would be keys_dict as it was previously (I_dict I dunno what to do with. probably just treat it as keys_dict rather than indices cut dict)

@coltim seems a bit inconsistent to me

at least when compared to dict_key

@chrispsn that returns them in the wrong order and fails for ?``a