Czy Wzór Rachunku stanowi krok naprzód w językach, czy właśnie wracamy do LISP?

Barry Jay w swojej książce wysuwa śmiałe twierdzenia - w zasadzie mówiąc, że u podstaw programu wszystko jest albo atomowe, albo złożone. Następnie rzeczy można łatwo iterować, filtrować, aktualizować, po prostu nawigując w tej relacji kompozycji.

Czy to nowa granica w informatyce dla języków komputerowych - czy właśnie wracamy do LISP?

Jedną z głównych zalet niedawnej pracy Jaya jest to, że zmniejsza kod, który należy napisać, aby przejść przez struktury danych w celu wykonania operacji takich jak mapa . Rachunek wzorów umożliwia jednokrotne zapisanie kodu przejścia dla wszystkich struktur danych i zastosowanie go do własnej struktury danych. To z pewnością zmniejsza ilość wymaganego kodu, ale nie umożliwia pisania programów, których inaczej nie można byłoby napisać. Na pewno jest wiele interesujących pomysłów w pracy, ale pozostaje do udowodnienia, że ​​faktycznie działa.

Nie jestem zaznajomiony z ostatnią pracą Barry'ego Jaya, ale jego starsza praca zawiera rzeczy, których nie można zrobić w Lisp, ponieważ typy zawierają dodatkowe informacje.

Załóżmy na przykład, że chcesz zdefiniować rozmiar struktury danych Lisp. Jest to 1 dla atomu, a n dla listy n atomów, a bardziej ogólnie rozmiar (x) + rozmiar (y) dla (cons x y).

Teraz dodaj typy do mieszanki. Rozmiar listy byłby jego długością. Teraz jaki jest rozmiar listy list atomów? Jeśli weźmiesz pod uwagę tę strukturę danych jako listę (której elementami są listy atomów), odpowiedzią będzie długość listy. Jeśli weźmiesz pod uwagę tę strukturę danych jako zawierającą atomy, które znajdują się na liście list, odpowiedzią jest suma długości list elementów.

Typy pozwalają rozróżnić te dwa widoki (kształty) surowych danych. Potrzebujesz systemu typów, który pozwala rozróżniać pomiędzy (List) (List Atom) i (List List) (Atom). Najczęstszą implementacją tego rozróżnienia są klasy (jak w Haskell).