Nushell core team meeting 2024-06-12

Attendees

• Jack
• Darren
• Devyn
• Antoine
• Michael
• Stefan
• Andy

Agenda

• devyn's recent work on registers, et al
• (@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 from nushell/nu_scripts#875 be the norm for writing scripts? i.e. getting strings only and then parsing at runtime

Discussed Topics

IR

• How the IR evaluation works underneath
  • IR definitions
  • IR evaluation
  • AST to IR compiler
• 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

Image Not Showing Possible Reasons

• The image file may be corrupted
• The server hosting the image is unavailable
• The image path is incorrect
• The image format is not supported

Learn More →

the issues which needs-core-team-attention

Image Not Showing Possible Reasons

• The image file may be corrupted
• The server hosting the image is unavailable
• The image path is incorrect
• The image format is not supported

Learn More →

Note
to list all the PRs currently opened in nushell/nushell:

gh pr list --json url,number,author,title
| from json
| each {|i|
    $"- [($i.number)]\(($i.url)\) ($i.title) \(@($i.author.login)\)"
}
| reverse
| to text