Czy jest jakaś różnica międzyniech vs regularnych misji w GHCi
f x = x + 1
i
let f x = x + 1
gdy wpisane GHCi? IIUC, istnieje specjalna zasada, że let bez in wewnątrz GHCi skutecznie odnosi się do całego zakresu interpretera. Ale jeśli obecność let nie ma znaczenia, jaki jest sens tej reguły?
Edycja: przy użyciu GHCi w wersji 8.0.2.
Nie, nie ma różnicy.
Kiedyś było tak, że ghci był zasadniczo otwartym blokiem IO do. Ale niezdolność do zdefiniowania nowych typów w tej formie składni i potrzeba napisania let dla każdej definicji były postrzegane jako denerwujące ograniczenia, które często utrudniały codzienne interaktywne użycie, a więc składnia ghci powoli stawała się bardziej permisywna. Ale to tylko zmiana w składni - nic głębszego.
Należy jednak pamiętać o jednej rzeczy: jeśli chcesz uruchomić blok, musisz to zrobić jednoznacznie. Na przykład,
> f [] = 3
> f (x:xs) = 4
odpowiada
> let f [] = 3
> let f (x:xs) = 4
a nie
> :{
| let f [] = 3
| f (x:xs) = 4
| :}
Stąd będzie nowy definicja f że cień starego i jest określony tylko nie -ne listy, podczas gdy prawdopodobnie chciałeś podać dwa równania dla pojedynczego f. Z automatycznym trybie blokowym (:set +m) ghci można zauważyć, że let rozpoczęty blok i automatycznie daje ten ostatni po wpisaniu let, a więc:
> let f [] = 3
| f (x:xs) = 4
|
Nie będzie to zrobić na krótką formę (nie let) definicje.
Chociaż to pytanie zadano kilka miesięcy temu, zauważyłem trochę więcej różnic, gdy zacząłem uczyć się ostatnio Haskell.
> :set -Wall
> a = 2
> let a = 3
skutkuje ostrzeżeniem o nazwa shadowing (-Wname-shadowing), natomiast
> :set -Wall
> a = 2
> a = 3
nie. Wygląda na to, że ostrzeżenie sprawdza tylko dla wyraźnie napisanych oświadczeń let.
Która wersja GHCi? Mój nie przyjmuje "f x = x + 1" jako danych wejściowych (błąd analizy). – Mephy
@Mephy Jest nowy w GHC 8. –
Jak rozumiem, używanie "let" do łączenia nazw w GHCi jest efektem tego, jak jest on zaimplementowany. Możesz sobie wyobrazić, że wprowadzasz komendy do "do-bloku" w monadzie IO. – Erik