nushell / nushell/nushell.github.io

Confusing example on script definition order

Aperta
#1,163 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Lingua principale
TypeScript
Stelle
258
Fork
561
Merge medio
3h 20m
PR unite (30g)
15

Descrizione

Issue

I'm currently reading the book which claims that

there is no requirement that definitions have to come before the parts of the script that call the definitions [...]

while showing these scripts as examples of how definition order does not matter:

def greet [name] {
  ["hello" $name]
}

greet "world"
greet "world"

def greet [name] {
  ["hello" $name]
}

This choice of examples is a bit unfortunate in my opinion as, when running both scripts, they have different output.
My understanding is that this is caused by the last expression in a script being printed which evaluates to ["hello" "world"] and nothing respectively.
However, this confused me initially and I would expect this to trip up some other new users as well.

Possible improvements

  1. Changing the script to e.g.
def greet [name] {
  ["hello" $name]
}
greet "world" | null

or

def greet [name] {
  ["hello" $name]
}
let foo = greet "world"
$foo

would result in the same output when moving the command invocation line around but might raise other questions.

def greet [name] {
  ["hello" $name]
}
def greet-world [] {
  greet "world"
}
greet-world

and then moving the definition of greet-world to the top is probably the best example I can think of right now.

  1. Alternatively, the different output could be explained in a small note. I'm not even sure sure if the book explains the last expression of a script being printed up to that point. It's definitely explained in a note for functions but I don't remember reading that the same applies for scripts. I wouldn't rule out that I simply missed that part, though.

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia dalla pagina della documentazione di scripts collegata nell’issue e rivedi gli esempi sull’ordine delle definizioni insieme alla spiegazione circostante dell’output dello script. Aggiorna l’esempio oppure aggiungi una nota, in modo che la differenza nell’output sia spiegata chiaramente quando viene spostata l’invocazione. Il lavoro è completato quando la documentazione dimostra accuratamente l’ordine delle definizioni senza trarre in inganno chi è alle prime armi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Ambito
documentation
Tipo di issue
Documentazione
Difficoltà
2/5
Tempo stimato
1-3 ore
Stato di attività
Ferma
Chiarezza
Abbastanza chiara
Idoneità per principianti
45/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.