[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