Add and and or keywords

[MicroProofs]

They could even have special prefixes but this would be really useful because it is common to have very long chains of booleans.

and(
  expr,
  expr,
  ..
)

• It would parse to a new ast node that hold a Vec<UntypedExpr>
• We can desugar it during typechecking into a binop chain

[rvcas]

+1 cause the current and and or functions in aiken/list require looping over a list which is just wasting budget for no reason. Doing this we can have some ergonomic benefits and is free.

Another alternative is to have better formatting for BinOp chains.

[waalge]

Can the compiler optimize list.and in these cases?

[KtorZ]

@waalge that's a bit more complicated to this at this stage because the compiler has no notion of stdlib whatsoever. That means you'd need some heuristic to first detect that this is one of the case, and then apply the optimisation.

What @MicroProofs suggests is fairly straightforward as it can be done entirely as a syntactic sugar. That is, something that's fully handled by the parser / type checker; a shorthand to produce a more complicated AST.

[waalge]

I can only take your word for it on that - I have no grasp on the complexity of getting the compiler to recognize things like this pattern.

I think adding new key words is a marginal increase on user cognitive load - there would be two things which look quite similar. And and or from list can no longer be pulled into the namespace.

I'm not in a position to provide a better fix. Chaining binops is also suboptimal. I use multiple expect True instead.

[rvcas]

@waalge if this were to be a thing, I suspect we'd get rid of the list functions in stdlib.

That said though, I think just having the formatting look good would do a lot here

[waalge]

Really? I think you still need to operate on lists. It's only if their elements are determined at compile time then the compiler could recognize a more efficient compilation.
Actually I think agree. In my head I'm parsing and and or as all and any which are more natural

[waalge]

Think i might change my mind on this.

map |> and is covered by all but there is no all2 for map2 |> and etc.
So you end up with map2 |> all ( fn(x) {x} )

(I'm sure alternatives are available)