# Nushell core team meeting 2024-06-12
## Attendees
- Jack
- Darren
- Devyn
- Antoine
- Michael
- Stefan
- Andy

## Agenda
- [x] devyn's recent work on registers, et al
- [x] (@amtoine) should we allow IO pairs with the same input type?

def f [--alternate]: [
    nothing -> list<int>,
    nothing -> string,
] {
    if $alternate {
        "alternate"
    } else {
        [1, 2, 3]
    }
}

note that the following is completely fine imo because there is no ambiguity about the IO pairs

def f [] [
    list<int> -> float,
    list<float> -> float,
    list<duration> -> duration,
] {
    math avg
}

- [ ] (@amtoine) about scripting...
- should we allow complex type annotations such as `list<int>` in the arguments of scripts?
- should [this dev flow](https://github.com/amtoine/nu_scripts/blob/script-arg-parsing/stdlib-candidate/std-rfc/script-parsing.nu#L24-L31) from [`nushell/nu_scripts#875`](https://github.com/nushell/nu_scripts/pull/875) be the norm for writing scripts? i.e. getting `string`s only and then parsing at runtime

## Discussed Topics

### IR

- How the IR evaluation works underneath
- [IR definitions](https://github.com/devyn/nushell/blob/ir/crates/nu-protocol/src/ir/mod.rs)
- [IR evaluation](https://github.com/devyn/nushell/blob/ir/crates/nu-engine/src/eval_ir.rs)
- [AST to IR compiler](https://github.com/devyn/nushell/blob/ir/crates/nu-engine/src/compile/mod.rs)
- Are we just fighting the same battle earlier? Need to define IR in a way that has the same semantics as the existing engine.
- Stefan had concerns about whether we'll be able to match the existing behavior well, because our tests are not complete enough
- Ideally new parser AST can compile to new IR, while old parser AST still compiles to new IR, so we can compare both
- On the plus side we can also dramatically restrict how many weird things that commands can do with AST

### IR and Evaluation
- If we are able to get an evaluation engine working with the old AST and the new IR
- Then we can use the same IR for the new AST and will get the evaluation engine for free

### Documentation

- Are we going to run into an issue where people in the community are documenting features of Nushell's semantics that were not intended?
- Nushell doesn't have a specification - there's no spec that says what we do for each language feature
- We should probably develop a reference so that we have something to compare to, and when we make changes we're aware of how that differs from current specified behavior

### Ambiguity on output types

- Utility as a shell vs perfect typechecking
- Things like `ls -l` or `transpose --as-record` have different output types depending on flags
- We don't have the expressivity to be able to typecheck that, we can just say the command might return `table` or `record`
- But should we forbid it entirely, or should it just be a style thing?
- Discussion came out of `std` RFC, whether a command should be able to have a drastically different output type depending on flags
- Style guide? Avoid designing commands like that
- Flexibility in the shell is great, but it complicates scripting and it would be good to know about it in the LSP

### Complex types in script arguments

- Is it better to have only simple argument parsing and do things like comma separated lists when talking to the outside world? Or allow use of Nushell types
- Do we like complex types as NUON or not?
- Antoine wrote a stdlib command that parses command line arguments via NUON

### Lazyframes

- It's easier to do a lot of simple stuff using the eager frames, especially cross-dataframe operations
- Does it make sense to get rid of lazy operations?
- Jack: I think I'm finding that it's good to have both, rather than remove eager stuff
- It probably doesn't make sense to copy the Python API exactly
- Darren: I would like to see it be easier to construct pipelines for dataframe stuff
- It would be great to be able to rely on the Python polars documentation and be able to see the overlap between Nushell and that API, to make it easier to discover how to use dataframes
- Devyn: a tutorial would be nice
-

## Issues
> :bulb: the issues which [needs-core-team-attention](https://github.com/nushell/nushell/labels/needs-core-team-attention)

> :bulb: **Note**
> to list all the PRs currently [opened in `nushell/nushell`](https://github.com/nushell/nushell/pulls):
> ```nu
> gh pr list --json url,number,author,title
> | from json
> | each {|i|
> $"- [($i.number)]\(($i.url)\) ($i.title) \(@($i.author.login)\)"
> }
> | reverse
> | to text
> ```