Nushell core team meeting 2023-11-22

Attendees

• Sophia
• Stefan
• Antoine
• Jakub
• Darren
• Storm
• Windsoilder
• Andres

Agenda

• Left over from last meeting
  • Secret project demo; Related discussion:
    • new parser
    • runtime debugger / profiler
  • spread operator from #11006
    • seems ready to land
  • Hopes/plans for new parser integration?
  • case sensitive B for bytes in #6807
  • boolean switches and options in #7260
• is operator? (out-of-the-blue PR: https://github.com/nushell/nushell/pull/11091)
  • we have describe -d already
• Well-written issue about types: https://github.com/nushell/nushell/issues/11108
  • "Full" types (incl. enums, like Rust) vs. current "structural" types
  • generics (we toyed with overloading before)
• should command take pipeline inputs AND parameter? (related to #11105)
• discontinue std testing
• error make -> throw error + throw warning
• Developer documentation, Call to action
• Lessons from the survey for us
• Redirection improvement in #10271
• Banning certain words on discord

Discussed Topics

Inspector Kubouch presents an interactive debugger demo

spread operator

ready to land for list, thanks to @ysthakur

New nu-parser

• cooking in the core team
• new parser will have several parses
  • light parsing (not making too many guesses)
  • name binding (where variables/commands are defined and used)
  • type inference and check -> final parse for ambiguous literals etc.
• EngineState and StateDelta will need some tweaking
• more keywords (how will they now be implemented in the engine - open)

--flag: bool / can you override bare flags with a variable

Currently --foo != --foo: bool
The former can only be toggled dynamically in an if statement (problematic in), the latter requires a passed value

WindSoilder's comment on the issue thread:

https://github.com/nushell/nushell/issues/7260#issuecomment-1811354775

Possible idea, tight coupling to flag with =

def foo [--bar: bool, baz?] {}

foo --bar=$var

current state

Design remains unclear, iterate before boxing us into a new design

is operator

not ready yet

• different syntax for types in signatures and this op

concern around "static" types vs runtime type information

• not boxing us in prematurely around the runtime info
• we want to support

Type system wishlist in #11108

• nominal types (i.e. giving name to a particular record spec or true struct)
• sum types (i.e. enums with payload)
• type inference for end to end checking
  • stability questions pre-1.0
• generics

Feedback to the issue author:
- Stefan
- break up
- we are tightening up the design for 1.0
- what needs to be designed before 1.0

commands that take data both from the pipe and the input.

When does it become ambiguous?

[foo.txt, bar.txt] | cp baz

Case by case analysis, what is the meaning of the arguments and input is it absolutely equivalent

Counterpoint we now have a spread operator: ...$in

• let's wait this out for start

Design thoughts raised

If we can replace implicit or flag heavy magic with compositional patterns
(e.g. enumerate instead of implcit args)