Czytelność wyrażeń S.

W skrócie i dla tych, którzy nie wiedzieli, funkcje / operatory / konstrukcje Lisp są jednolicie nazywane w następujący sposób:

(function arg0 arg1 ... argN)

Więc co w języku podobnym do C wyraziłbyś jako

if (a > b && foo(param))

przekształca się w Lisp sexp

(if (and (> a b) (foo param)))

. W miarę jak rzeczy stają się bardziej realne / skomplikowane, podobnie jak ich odpowiednie wyrażenia s, dla mnie.

Zdaję sobie sprawę, że jest to najprawdopodobniej subiektywne pytanie, ale - czy dla wielu hakerów Lisp to jedno irytowanie, z którym zawsze trzeba będzie sobie poradzić?

Czy może prędzej czy później przyzwyczaisz się do tej (brak) składni?

W każdym razie, czy dodawanie linii nieciągłości (których w większości przypadków nie dodajesz w ekwiwalencie C) dla czytelności jest dobrym pomysłem, szczególnie na dłuższą metę? Wszelkie inne sugestie byłyby mile widziane.

Jak analizujesz

if (a > b && foo(param)) {
  doSomething();
} else {
  doSomethingElse();
}

Drzewo parsowania prawdopodobnie wygląda jak

if:
  condition:
    and:
      lt:
        left: a
        right: b
      function:
        name: foo
        param: param
  true-block:
    function:
      name: doSomething
  false-block:
    function:
      name: doSomethingElse

hmm ... zserioryzujmy to drzewo do listy, notacja prefiksowa

if(and(<(a, b), function(foo, param)), function(doSomething), function(doSomethingElse))

Ten format drzewa analizy jest dość łatwy do manipulowania, ale mam jeden problem. Nienawidzę separatorów. Lubię terminatory. Jednocześnie lubię posypywać białe znaki.

if( and (<(a b) function(foo param)) function (doSomething) function ( doSomethingElse))

hmm ... dodatkowe białe znaki utrudniają analizowanie niektórych rzeczy ... Może mógłbym po prostu ustanowić zasadę, że drzewo jest przedstawiane jako (liść liścia korzenia).

(if (and (< a b) (function foo param)) (function doSomething) (function doSomethineElse)

Teraz moją serializacją parsowanego drzewa jest lisp (zmiana nazwy funkcji do zastosowania, i to prawdopodobnie działa). Jeśli chcę programów, które piszą programy, miło jest po prostu manipulować parsowaniem drzew.

Nie do końca tak powstały wyrażenia s, ale zostały wcześnie zidentyfikowane i jest to jedna z funkcji używanych przez programistów Lisp. Nasze programy są w pewnym sensie wstępnie przeanalizowane, a pisanie programów do manipulowania programami jest dość łatwe ze względu na format. Dlatego brak składni jest czasem uważany za siłę.

Ale jak powiedział David, użyj edytora świadomego wyrażania s-wyrażeń. Bardziej prawdopodobne jest, że stracisz śledzenie zamykającego nawiasu klamrowego w wyrażeniu s niż zamykającego nawiasu klamrowego w xml ( </foo>tylko zamyka <foo>, ale prawy paren zamyka DOWOLNE wyrażenie s). W przypadku rakiety użycie nawiasów kwadratowych dla niektórych wyrażeń w połączeniu z dobrym stylem wcięcia rozwiązuje większość problemów.

Wersja lisp:

(if (and (< a b) (foo param))
  (doSomething)
  (doSomethingElse))

Nieźle.

To, co jest naprawdę miłe w s-exp, to to, że po krótkim czasie już ich nie widzisz, to jest jak pyton dla twoich oczu, ALE komputer wciąż ma drzewo.

• Wcięcie jest więc automatyczne, nie ma dwuznaczności, nie musisz naciskać klawisza Tab dwa razy, ani czegoś takiego, gdy chcesz zakończyć blok.

• Jeśli wybierzesz jakiś losowy kod, to wszystko można łatwo wciąć jednym poleceniem z ulubionego edytora

• Możesz naprawdę łatwo poruszać się po kodzie , przeskakiwać między s-exp, zamieniać je i tak dalej z dobrym edytorem

Ponadto, ponieważ manipulowane dane są takie same, jak kod, który piszesz, możesz użyć tego samego języka do manipulowania kodem, prawda?

Cóż, możesz to zrobić, takie są makra, manipulujesz pisanym kodem, zanim zostanie oceniony jak każda inna lista, dlatego mówi się, że Lisp jest „Programowalnym językiem programowania”. Piszecie kod, który pisze kod za was.

Oto fajny artykuł opisujący naturę Lisp i dlaczego programiści Lisp uśmiechnęli się, widząc XML.