Od kilku lat bawię się funkcjonalnymi językami programowania i ciągle spotykam się z tym zwrotem. Na przykład jest to rozdział „The Little Schemer”, który z pewnością poprzedza blog pod tą nazwą (nie, ten rozdział nie pomaga odpowiedzieć na moje pytanie).
Rozumiem, co oznacza lambda, idea anonimowej funkcji jest zarówno prosta, jak i potężna, ale nie rozumiem, co w tym kontekście oznacza „ostateczność”.
Miejsca, w których widziałem to zdanie:
- Tytuł rozdziału 8 The Little Schemer
- Blog: http://lambda-the-ultimate.org/
- Seria artykułów „Lambda the ultimate X”: http://library.readscheme.org/page1.html
Mam wrażenie, że brakuje mi tutaj referencji, czy ktoś może pomóc?
functional-programming
terminology
history
lambda
Eric Wilson
źródło
źródło
Odpowiedzi:
Tak, to po prostu powtarzające się zdanie w tytule kilku artykułów, poczynając od kilku z lat 70., w których Sussman i Steele demonstrują wykorzystanie rachunku lambda do programowania, za pomocą minimalistycznego dialektu Lisp o nazwie „ Schemat ”, dla którego opracowali cel. Możesz znaleźć same dokumenty tutaj ; są interesujące i zaskakująco istotne.
Nie jestem pewien, czy kiedykolwiek zostanie to wyraźnie stwierdzone, ale jest jasne (z kontekstu, po przeczytaniu artykułów i znajomości ogólnego tła i zainteresowań badawczych autorów), że zdanie to po prostu chwytliwe hasło dla ich twierdzenia, że abstrakcje lambda , jako prymityw obliczeniowy, są nie tylko uniwersalne w sensie formalnym (możliwość kodowania dowolnego programu w pewien sposób, choć niezręczny), ale uniwersalne w sensie praktycznym, że każdy konstrukt obecny w innych językach, nawet tych, które są wypalany od podstaw, może być ponownie wdrożony w języku opartym na lambda w sposób zarówno skuteczny, jak i naturalny.
Powtarzająca się fraza prowadzi do oczywistej uogólnionej formy „dla wszystkich X, lambda jest ostatecznym X”, co ogólnie rozumiem jako „Lambda the Ultimate” jako nazwę bloga, zauważając, że LtU zajmuje się językiem programowania projekt i teoria. Jak na ironię, LtU byłoby prawdopodobnie jednym z najlepszych miejsc do znalezienia kogoś, kto mógłby ci powiedzieć o czymś, dla czego lambda nie jest ostateczną implementacją. :]
Zauważ też, że Sussman jest jednym z autorów SICP , bardzo wpływowego podręcznika, który również używa języka Scheme i spędza sporo czasu na wprowadzaniu abstrakcyjnych lambda jako koncepcji.
źródło
Lambda The Ultimate odnosi się do idei, że lambda rachunku lambda mogą skutecznie implementować każdą wbudowaną koncepcję w każdym języku programowania, przeszłości, teraźniejszości i przyszłości. Klasy, moduły, pakiety, obiekty, metody, przepływ kontrolny, struktury danych, makra, kontynuacje, wzory, generatory, zestawienia list, strumienie i tak dalej.
Tak się składa, że ta ostateczna natura obejmuje reprezentowanie Anonimowej Funkcji. Ale lambda nie są w istocie ograniczone do anonimowych funkcji. Uczą się w ten sposób, ale istota lambda sięga znacznie głębiej niż funkcje matematyczne bez imion. Innymi słowy, mam problem z:
W praktyce użycie lambdas jako abstrakcji syntaktycznych („makr”), które nie są funkcją call-by-value / aplikacyjną (które to funkcje matematyczne), jest absolutnie kluczowe dla przyjęcia idei, że lambdy naprawdę mogą służyć jako rdzeń każdego systemu przetwarzania języka programowania.
For Theory: Istnieje ciekawy związek z paradoksem Bertranda Russella i aksjomatami zrozumienia (i rozszerzenia) w naiwnej teorii mnogości. Lambda jest funkcją, co notacja konstruktora zestawu jest zestawem: lambda to notacja konstruktora funkcji. Istnieje ważna różnica, zwykle ignorowana, między (lambda (x) (* xx)) a tym, co ocenia (funkcja kwadratu). Jeśli nie uda się rozróżnić między nimi w ogóle, to znaczy między notacją a denotacją (błąd, który popełnili zarówno Church, jak i Frege), wówczas popełni się paradoksy. W przypadku zestawów i Frege ilustruje ten błąd fryzjer z Sewilli Bertrand Russell. w przypadku funkcji i Kościoła jest to Wyrocznia Zatrzymania Alana Turinga.
Zauważ, że paradoksy są dobre, praktyczne. Chcemy, aby EVAL był wyrazisty i chcemy, aby lambda oznaczały więcej niż tylko funkcje. Zakładanie, że przeciwieństwo prowadzi do sprzeczności, jest pożądanym rezultatem; służy to jako dobry test rozsądku: lambdy nie mogą być ostateczne, jeśli wyrażają jedynie zwykłe funkcje.
Racket (wcześniej PLT Scheme) nadal podąża za ideą, że praktyczne języki programowania naprawdę można budować od podstaw na „just lambda”.
Kernel , według Shutt, twierdzi, że lambda nie jest tak naprawdę ostateczną abstrakcją. Twierdzi, że istnieje jeszcze jedna bardziej prymitywna koncepcja (w języku greckim, nazwana vau), która była znana Sussmanowi jako FEXPR.
Felleisin i firma (dla Racket) czerpią wiele mocy vau Shutt'a, wykorzystując koncepcję faz lub metalevels, co w przybliżeniu oznacza uruchomienie kodu źródłowego przez wiele etapów tłumaczenia (jak w przypadku wstępnego przetwarzania C, ale przy użyciu tego samego języka w każdym „krok” i „kroki” nie są w rzeczywistości całkowicie odrębne w czasie). (Twierdzą więc, że lambda w wyższej fazie wystarczająco dobrze zbliża się do vau.) W rzeczywistości twierdzą, że fazy są lepsze niż FEXPR, właśnie dlatego, że są bardziej ograniczone; w skrócie: „FEXPR są zbyt potężne” (patrz praca Wand, przeciwko której Shutt argumentuje).
3-Lisp Briana Smitha, „Refleksja proceduralna w językach programowania”, próbuje rygorystycznie przeformułować teorię języków podobnych do LISP zgodnie z ostrym rozróżnieniem notacji (symboli / języka / programów) od denotacji (rzeczy / referencji / wartości / wyników) ). http://dspace.mit.edu/handle/1721.1/15961
„Teoria FEXPR-ów Mitchella Wanda” wysyła więcej gwoździ do (tymczasowej?) Trumny, którą Kent Pittman stworzył dla FEXPR-ów (który, podobnie jak Felleisen, argumentuje przeciwko FEXPR-om, utrudniając kompilację).
Paul Graham z całą mocą argumentuje w „On Lisp”, że prawdziwą mocą są lambda jako transformatory składni (makra), a nie jako transformatory wartości (funkcje matematyczne). Opracowanie przez Plotkina aplikacyjnego rachunku lambda można uznać za nieco kontrastujące, ponieważ Plotkin ogranicza rachunek Kościoła do jego podzbioru call-by-value / application. Oczywiście sprawne obchodzenie się z częścią aplikacyjną jest bardzo ważne, dlatego ważne jest, aby opracować teorię specjalizującą się w tym zastosowaniu lambda. (Plotkin i Graham nie kłócą się ze sobą).
W rzeczywistości pojęcie Lambda jako Ultimate jest tylko jednym z takich zwrotów w wiecznej debacie między skutecznością a ekspresją; jest to pozycja, w której lambda jest ostatecznym narzędziem ekspresji, a przy wystarczającej analizie ostatecznie okaże się także ostatecznym narzędziem wydajności. Innymi słowy, możemy, jeśli chcemy, postrzegać przyszłość języków programowania jako nic więcej i niczym więcej niż naukę, jak efektywnie wdrożyć wszystkie praktycznie istotne fragmenty rachunku lambda.
Landin's „The Next 700 Programming Languages”, http://www.cs.cmu.edu/~crary/819-f09/Landin66.pdf , jest dostępnym odniesieniem, które przyczynia się do rozwoju tej koncepcji, że Lambda jest ostateczna.
źródło
Sądzę, że jest to po prostu odniesienie do niektórych artykułów napisanych przez Sussmana i Steele w latach 1975–1980:
Zobacz artykuł w Wikipedii.
źródło