Yann Hamdaoui

Update: since we don't generalize types automatically, we might get away with a bidirectional type system that would support these implicit casts (or equivalently, subsumptions) of arguments to a less...

I think this issue is now superseded by [RFC004](#691). We can close it once it's in an acceptable state and merged.

`Term::ParseError` is here for the LSP, which needs to be error-tolerant (otherwise, a simple syntax error would preclude any basic functionality in the rest of the source file). We had...

Hello, Indeed, `callPackage` is currently not implementable in Nickel. Such a builtin may be technically possible, but not trivial, as the destructuring function arguments is desugared to a plain functions...

Revisiting this issue, I agree that pipes provide reasonable ergonomics. List comprehension can be still useful for iterating from multiple sources, like `[ x + y + z for x...

Sure, my point wasn't that this is not possible with higher order functions (since list comprehensions are just syntactic sugar), just that this is slightly less convenient and readable :slightly_smiling_face:

# Type equality for contracts After a bit more thinking, here is a proposal for type equality on contracts. ## Aliases One basic case that I think we want to...

> Or make forcing a value to Wrap a contract violation. Except in the special unwrapping case. It's kind of awkward too. But maybe less awkward. That would be my...

@MagicRB I wouldn't say so. Effects have been on hold for now, as there have been other fundamental aspects of the language to discuss, design and implement. We'll probably come...

Sorry, I missed this. But I think @litchipi is now on it, right?