[nem-pl] Uwagi różne
Marcin 'Qrczak' Kowalczyk
qrczak at knm.org.pl
Sat Feb 21 00:33:13 CET 2004
W liście z pią, 20-02-2004, godz. 21:39, Kamil Skalski pisze:
> > using Foo.A; // Wprowadza funkcje foo() i bar()
> > macro m() {
> > <[
> > defrule bar {...}; // defrule to jakieś śmieszne makro
> > foo() + bar()
> > ]>
> > }
>
> Kluczowe pytanie czy 'def bar' jest widoczne tutaj czy dopiero po ekspansji
> makra.
Dopiero po ekspansji. W tym sęk.
> jeśli natomiast sama definicja bar jest dopiero wyprodukowana przez ekspansję
> to tej intencji co piszesz nie zachowamy.
No to dupa. Makra nie umieją wprowadzić prawdziwej nowej składni
definicji i ogólnie wiązań, nadają się tylko do wyrażeń składających się
z podwyrażeń - żadnych wzorców w podwyrażeniach, chyba że wewnątrz
wbudowanych, znanych rozwijaczowi konstrukcji.
> Na szczęście mam na to lepszą odpowiedź - zasłonię się regułą lexical-scoping,
> bar zostanie związane z tym, co jest widoczne (a nie wygenerowane) w miejscu
> definicji makra.
To, że rozwijacz makr tego nie widzi, nie jest usprawiedliwieniem.
Po to zrobiłem makro defrule, żeby mieć nową składnię definicji,
równie prawdziwą jak te wbudowane, o takich samych prawach.
> Czyli nawet jeśli defrule wygeneruje 'def bar =' to prawidłowym zachowaniem
> jest związanie 'bar()' z Foo.A.bar. Jeśli ktoś chce inaczej, to to jest
> niehigieniczność i powinien sobie z tym poradzić robiąc z 'bar' jakiś
> NewSymbol ().
Nic podobnego. Potraktowanie defrule jako definicji wiążącej argument
bar jest prawidłowe, higieniczne i wskazane. A to, że tego nie da się
stwierdzić już w momencie wstawiania rozwinięcia makra to kodu, to
przykra rzeczywistość - przeszkoda wysoka, ale do pokonania. Scheme
sobie z tym radzi, Dylan też, mój język też sobie będzie radził.
> Nie wiem, może w ten sposób ograniczamy się mocno, ale naprawdę zdziwię się,
> jeśli zobaczę program, w którym ta sterylność, bo to już nie jest tylko
> higieniczność, jest przydatna.
To jest najnormalniejsza higiena połączona z możliwością definiowania
makr-definicji, oraz z możliwością definiowania makr-wyrażeń używających
w środku wzorców (tzn. np. takich jak match i try). Przed rozwinięciem
makra nie rozpoznasz, które fragmenty jego argumentów staną się
wzorcami, więc nie wiesz, które nazwy są użyte, a które wiążące,
a z tych użytych - czy nie trafią przypadkiem w zakres jakiegoś
wiążącego, pochodzącego z innego parametru tego makra.
> No właśnie nasz system ma tą zaletę, że nawet mi się mieści w głowie - jest
> prosty i przejrzysty, więc może taki bedzie i dla userów.
Ale bardzo ograniczony. To już lepiej darować sobie higienę - będzie
można robić jak w Common Lispie, ręcznie gensymy i kwalifikowany nazwy -
niż w ogóle uniemożliwić robienia makr używających wzorców i definicji.
--
__("< Marcin Kowalczyk
\__/ qrczak at knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
More information about the devel-pl
mailing list