[nem-pl] Dalsze rozważania o higienicznych makrach

[Kamil Skalski]

> Dziedzina, w której makra zaczynają mieć duży sens, to własne
> konstrukcje wiążące nazwy i dopasowujące wzorce, bo tego się już łatwo
> funkcją nie obejmie.

Ee, dla mnie główna różnica jest taka, że makra są wykonywane podczas 
kompilacji i dzięki temu mogą obliczać różne ciekawe rzeczy, a potem ich 
wynik jest statycznie typowany. Makra używane do hackowania elementarnych 
elementów języka, jak definiowanie zmiennych czy funkcji, to IMHO nadużycie. 
Uważam słówko 'def' nie tylko zupełne pod względem wyrażalności, ale też 
całkowicie wystarczające pod względem wygody. Ale sądząc po tym co ludzie 
wyrabiają w Lispie i Scheme jestem w stanie uwieżyć, że można myśleć inaczej.

>> aby jego 'bar()' (Foo.A.bar () w jego intencji!) został nagle złapany przez 
>> jakiś "obcy" bar wprowadzony jako definicja przez makro.
>
>Ależ chciałby - w końcu po to wstawił definicję bar, żeby w jej zakresie
>bar oznaczał zdefiniowaną rzecz. Nie musi nawet pamiętać, które
>konstrukcje definicyjne są wbudowane, a które są makrami.

Gdyby naprawdę tego chciał i był rozsądnym programistą, to napisałby
def $("bar" : var) =... 
umieszczając przy tym komentarz, że TO 'bar' nadejdzie z TEGO 'm()', a nie z 
Foo.A

> no i można wyrazić w nim wszystko co w tamtym
>
>Nieprawda, nie da się zrobić makra wprowadzającego definicję, które jest
>używalne nie tylko w głównym programie, ale i w rozwinięciach innych
>makr.

Da się:
macro m() { <[ def $("f" : var) = ... ]> }
macro m'() { <[ m(); $("f" : var) }

>Nie nadal, tylko właśnie zaczyna być niehigieniczne. Nie pozwalasz
>zapisać higienicznego użycia makra, naturalny zapis nie jest nawet
>interpretowany niehigienicznie, tylko po prostu nie działa i trzeba
>wymyślać jakieś obejścia.

Higieniczna wersja powyższego:
mutable f : string;
macro m() { f <- NewSymbol (); <[ def $(f : var) = ... ]> }
macro m'() { <[ m (); $(f : var) }

I poraz kolejny zaznaczam, że to co dla Ciebie jest naturalne, jakimś trafem 
dla mnie nie jest... nic na to nie poradzę :)

A teraz kilka uwag konstruktywnych:
- przeczytałem algorytm z pracy Dybviga i poza tym, dlaczego to napewno działa 
wydaje się z miarę do strawienia. Nie rozumiem natomiast tego co piszesz o 
swoich pomysłach na jego zmienienie... niestety zupełnie nie mam intuicji co 
możnaby tu opuścić i dlaczego. Jego propozycja z "ostatnio związanym 
symbolem" i "oznaczeniami, a raczej zbiorem kolorów" wydaje się całkiem 
naturalna
- implementacyjnie to może zabić, zarówno szybkość, poprawność ;) i 
zrozumiałość kodu to robiącego
- nie wyobrażam sobie jak w tym systemie zrobić rozwijanie namespaców, u niego 
nigdzie nie ma przechowywania kontekstu w którym makro zostało napisane. 
Potrzebujemy tego, żeby stwierdzić, że niezłapana zmienna odnosi się do 
symbolu z namespaceu otwartego w miejscu napisania makra - do tego 
musilibyśmy z każdym makrem utożsamiać całe środowisko widoczne w miejscu 
jego definicji
- przerzucenie rozwiązywania nazw z kompilacji quotowań do ich (makr w których 
się znajdują) użycia to strata zarówno na szybkości, jak i klarowności 
komunikatów błędów (to że zrąbałeś jakieś nazwy w quotowaniu w makrze okazuje 
się dopiero w użyciu makra) - są to jednak rzeczy do przejścia, szybkość 
można polepszać, a komunikaty generalnie chyba będą przetrawialne no i będzie 
wiadomo które makro I CO zepsuło

Zatem nawiększy problem widzę w rozwijaniu, no i w implementacji, która na 
pewno będzie działać, bo ta tematyka jest dość trudna.

Kamil