I don't know Curry either. Do you mean like Prolog?

Like a value could really be all the values satisfying some condition, and then you can apply functions to all of those values at once while treating them as a single value, and at the end you can pick just the first of those values or go through the entire list?

It's more "given a list of items, create a new thing that's all the items at once"

I think that's close enough, lots of possibilities there

Mayhbe you could talk to some Brachylog programmers for inspiration

Oh wait maybe you already have let me backread the transcripts

@user the inspiration is nekomata

And how I've been beaten by a byte sometimes purely because the non deterministic nature of nekomata means you don't need extra bytes for explicit vectorisation over a list of values

@UnrelatedString you're good with prolog/brachylog right? How's the idea of [list of values] -> value which is each value at once sound in relation to non-determinism? Do you think it could be expanded any further than that?

(in relation to user suggesting to ask brachylog golfers :p)

Been pondering (certainly not committing to) doing something previously unthinkable: 1-indexing

I've seen how it can be of benefit sometimes, especially with find returning 0, but I also know that 0 indexing has a lot of nice edge cases too

I am currently undecided on which is better, and I don't have enough practical golfing experience with 1-indexed languages to make a call either way

Anyone got any input on whether 0 or 1 is better for golf?

They're both golfy (evidence: Jelly) but as someone who's recently started working on a medium-sized project in lua please spare me

vyxal's meant to be accessible

1-indexing is not accessible

@emanresuA jelly is the only reason I'm considering it lol

If golf wasn't an issue it'd be 0 all the way

There are cases where 0-indexing is golfier, there are cases where 1-indexing is golfier, and there are the vast majority of cases where it doesn't matter at all

So in your experience they're roughly the same?

It's a fairly arbitrary choice and I don't think either way makes much if any difference, but 1-indexing is a lot less intuitive to people coming from sane languages (i.e. not lua)

I know about the practical side of the decision, I'm curious about the golfing side :p

My preference is to keep 0 indexing but I'd like to know that it's a preference that isn't non-optimal

If you're interfacing with indices from input/output practically every challenge will let you choose between 1-indexing and 0-indexing. Find returning 0 is neat but it's quite rare that you want to find the potentially nonexistent index of something in a list

The only other cases I can think of are numerical formulas for indices but those are almost always equivalent

Got it. Sounds like 0 indexing will remain

@emanresuA also, what're you making with lua?

factorio mod

(that said, you might want to ping some people who use Jelly more frequently and ask if they've had any cases of 1-indexing saving bytes)

@UnrelatedString (^) (second mod ping today lol)

And @hyper-neutrino too

@lyxal That's a... really good question

It probably would work, if it's basically, like, a reflavored way to describe what ∋ does in Brachylog (namely, nondet pick an element)

Might want to look into how Nekomata's model of nondeterminism works, because I know it has a concept of "nondet object" but I haven't played with it enough to 100% have figured out whether that's an abstraction around the linearly sequenced choice points I'm used to or if they really are "special lists"

@UnrelatedString that's pretty much what it does

Huge

@lyxal Ah interesting

@lyxal make it a flag

Also if you do add more pervasive nondeterminism, having declarative failure available can also mitigate one particular utility of 1-indexing (i.e. failed searches returning 0)

@Ginger as long as you don't do the traditional APL thing where whether indices start at 0 or 1 is a scoped setting

what.

except that when you call lambdas they don't get the setting of the scope at the moment tbey were defined in, because they close over the setting, so every time you write a lambda you either have to assume that the default is going to be enabled or manually set it in each lambda

@Ginger modern APLs and derivatives tend to just choose one setting (usually 0, TinyAPL is the black sheep here) and don't allow changing it and that's a much more sane system

for tinyapl 2 i think I will set the origin back to 0 because i've found it's more useful; and then allow for call-level customization so you have the best of both worlds, because sometimes you do want some things (and only some things) to start at 1

but yeah index origin in apl is a weird subject

wack

...yeah wow that is bad in a lot more complicated ways than I thought

Global flags/state influencing fine grained behavior is always ???, and scoping it like that seems on paper like it could mitigate the problem, but there's still just no winning

Because if it is scoped, then indices passed from outside have to conform to the scoped IO, and if it isn't scoped, internal logic manipulating the indices can completely unfixably break

I guess one way to make it slightly gentler could be to tag individual integers in the input with the calling scope's IO so that if they're used directly for indexing they get shifted to compensate...? But then that failing with any kind of manipulation, even stuff that mathematically cancels out (or maybe addition and subtraction could also preserve the flag), would just be room to surprise the user

It's just a mess

@lyxal Oh yeah I kinda forgot to reply to this LMAO

I generally don't think about it since it's just kinda there, but...

@emanresuA This can come up extra in Jelly because i has the opposite argument order from e, but depending on what you're using the result for you can also get away with the likes of f

And some other fun hacks with that work just as well with 0-indexing, provided you have modular indexing either way (i.e. the not-found value is always going to point to the last element if you do index back in with it)

Also worth considering corollaries, like whatever the J equivalent is--is it more useful to have that as all-positive, or are there tricks you can use with the first element being zero

@UnrelatedString We have both 0...len(x) and 1...len(x)+1 so it doesn't matter too much

:P

smart

So I gather the takeaway is that golfwise, the indexing offset doesn't make much overall difference

Meaning that it can be a matter of pure practicality

In which case, 0 indexing and don't worry about providing a way to change it