[nem-pl] Uwagi różne

[Kamil Skalski]

On Saturday 21 of February 2004 01:56, Marcin 'Qrczak' Kowalczyk wrote:
> w Common Lispie, bez higieny), czy to syntax-case (porządny system
> domyślnej higieny i kontrolowanego łamania higieny). Widać ludzie tego
> potrzebowali i standardowe makra im nie wystarczały.

To jest argument. Dlatego niewątpliwie rozważymy różne systemy higieniczności 
makr i ich semantyki. Jeszcze raz dzięki za wskazanie kierunków,  w których 
powinniśmy iść.

> Aha, nie słyszałem o makrach tego rodzaju, które byłyby statycznie
> typowane. Template Haskell jednak wyglądają inaczej (z tym jawnym
> zaznaczeniem, że rozwijamy makro, a nie wołamy funkcję). Chyba
> wkraczacie na terytorium, na którym nikt nie był.

No mamy nadziję, że choć kilka rzeczy jest nowych - składnia wyraźnie 
oddzielająca język od meta-języka, przezroczyste użycie makr (to może jest 
przeciwne do poprzedniego punktu, ale tak powinno być - makra powinny być 
pisane tak, żeby nie było widać że to są makra (jeśli chodzi o ich 
działanie), a potrzeba posiadania skompilowanych makr przed ich użyciem 
świetnie rozgranicza fazy kompilacji - patrz hacki (bezpośrednie pisanie co
od siebie zależy) w tej pracy o MzScheme. 
Poza tym makra ładnie operujące na OO typach, no i największy cukierek
czyli makra które typują drzewa na których operują. Proponuję zamknąć dyskusję 
o higienie, doszliśmy już chyba do dość klarownych wniosków i skupić się 
raczej na fajniejszych featurach.

> Którego nie będzie można poprawić inaczej niż rezygnując z używania
> danego makra (np. while) w rozwinięciu innego makra, tylko rozpisując
> go ręcznie. Tu nie chodzi o niespodzianki, tylko o dostępną
> funkcjonalność.

Nie, makr można u nas przecież używać w quotowaniach. Jedynie semantyka
przeciekających definicji symboli z tych makr będzie inna. Ale zaznaczam, że 
być może zdecydujemy się jednak na ten model.

> Bardzo z grubsza. Próbowałem opisać dwa listy temu, jak sobie wyobrażam

Uhum, dzięki za te i tamte wyjaśnienia oraz linki.

>
> Nie zawsze. Na przykład nie chciałbym, żeby przy napisaniu 1/x wyskoczył
> błąd kompilacji, że kompilator nie jest pewien, czy przypadkiem x nie
> będzie 0. Błąd powinien wyskakiwać w czasie kompilacji tylko jeśli
> faktycznie jest błędem, a nie tylko czymś, co może być użyte poprawnie
> bądź nie.

Miałem na myśli błędy, które są oczywiste <[ 1 + true ]> w żadnym przypadku
nie jest poprawne i powinno się wywalić podczas kompilacji makra. Tak jak 
Michał zauważył, typowania quotowań (sprawdzanie poprawności) będzie bardzo 
ograniczone, w szczególności nie powinno wołać o błędzie, że coś jest 
niejednoznaczne (w sumie po prostu obecność $ dziurawi tutaj system typów i 
to nie jest problemem, bo po prostu błąd wyjdzie w użyciu makra).

> To, że niehigiena nie przedostaje się dalej? Zależy od punktu widzenia.
> Czasem chcemy, żeby się przedostała (jeśli robimy repeat za pomocą while
> i chcemy, żeby break działał po staremu), a czasem nie (jeśli robimy
> while za pomocą lokalnej funkcji i wcale nie chcemy, żeby w ciele pętli
> znalazło się return z funkcji - załóżmy dla potrzeby przykładu, że
> funkcje niehigienicznie wprowadzają "return" tak jak w C).
>
> Jedyne zdrowe rozwiązanie tego dylematu, jakie znam, to stwierdzenie:
> niehigiena  dotyczy tylko miejsca bezpośredniego użycia makra, kropka.
> Jeśli ktoś jest taki kozak, że pisze makro rozwijające się do
> niehigienicznego makra, to sam w nim musi dodać forward nazwy:
>    def $implicit.break = break;
> i musi być świadomy, które nazwy mają przecieknąć. Nie ma możliwości
> automatycznego przeciekania wszystkiego (poza sztuczką, którą opisałem
> poprzednio, której się chyba nie poleca).

A teraz to podajesz bardzo ładne argumenty za użyciem naszego podejścia... 
Twój system nie pozwala na użycie niehigienicznego makra (prawdopodobnie 
dobrego, np. dobrze przemyślanego) w innym makrze... Nasze pozwala i jeśli 
coś ma się zepsuć, to zrobi to w ostatecznym miejscu expansji użycia.

> Czyli "macro" jest niehigienicznym makrem. Oby _N_ctx było wprowadzane
> na tych samych zasadach, co przez inne niehigieniczne makra, bo inaczej
> ludzie się pogubią.

Eeh, to jest taki hack, potem będzie coś w stylu niejawnej funkcji implicit, 
ona też jest niehigieniczna. A jakoś to należy zrobić. Poza tym można 
uhigienicznić _N_ctx, ale wtedy trzebaby dostarczyć zestawu funkcji, które 
pozwalają z niego korzystać (w sposób niejawny).