[nem-pl] Drugi rysunek już ze światłocieniem

[Marcin 'Qrczak' Kowalczyk]

W liście z pią, 27-02-2004, godz. 23:56, Kamil Skalski pisze:

> O ile dobrze to sobie wyobrażam, to 
> niehigieniczna zmienna pojawi się w kodzie i "piętro wyżej" zostanie 
> potraktowana jako zwykła zaquotowana (hmm, nie pomyślałem o tym wcześniej, 
> niby to dobra rzecz, ale myślałem że niehigieniczne będą się przedostawać 
> wyżej). Intencja jest taka, że niehigieniczne w naturalny sposób nie łączą 
> się z globalnym kontekstem widocznym w miejscu definicji quotowania/makra, 
> tylko są "wolnymi strzelcami".

To jest inny schemat. Chcesz chyba powiedzieć, że $("m" : var) połączy
się z dowolną zmienną o symbolu "m", nie biorąc pod uwagę koloru. W moim
modelu takich zwierząt nie ma, każda nazwa ma kolor uwzględniany przy
dopasowywaniu, a relacja zgodności nazw jest przechodnia.

Jeśli niehigieniczne nazwy mają ignorować kolor, to jest niedobrze,
i to nie tylko dlatego, że niehigienicznego makra nie da się zamknąć
w higieniczne. Jeśli niehigienicznie wstawiona nazwa występuje w pozycji
wiążącej, to popsują się nazwy higienicznie użyte przez makra w środku.
Te makra nie miały obowiązku wiedzieć, że ktoś użyje ich w takim
kontekście.

Na przykład niech makro m1 odwołuje się higienicznie do widocznego w
miejscu jego definicji globalnego symbolu x, a makro m2 niehigienicznie
wprowadza x i wstawia swój argument w zakres widoczności tego x. m2 było
przewidziane do bycia używanym w taki sposób:
   m2 (...coś zawierającego x...)
ale jeśli ktoś napisze
   m2 (...coś używającego m1...)
to m1 nie ma prawa się popsuć, bo to, że ono używa x, nie jest znane na
zewnątrz m1!

> Tylko z tym xorowaniem to nie rozumiem i nie rozumiałem już u Dybviga
> - u nas wszystko dostaje kolor raz i taki ma mieć, a nie że nagle kolor
> znika nie wiadomo co to właściwie było.

Makro ma dodać pokolorowany kawałek kodu z wklejonymi argumentami, przy
czym argumenty mają mieć ten sam kolor, co miały na początku. Zamiast
nadawać kolor w trakcie obliczania cytatów, można to zrealizować tak:
rozwijacz makr koloruje argumenty makra nowym kolorem (tzn. kolor jest
zbiorem / listą znaczników i dodajemy nowy znacznik); makro opakowywuje
te argumenty fragmentami kodu od siebie, które nie są pokolorowane;
następnie rozwijacz makr koloruje cały efekt rozwinięcia jeszcze raz tym
samym kolorem, przy czym tam, gdzie ten kolor dotrze do argumentów,
kolory się znoszą i przywracany jest poprzedni.

Zalety: nie trzeba komunikować koloru między rozwijaczem makr a cytatami
kodu, tzn. cytat kodu staje się pure wyrażeniem nieużywającym zmiennych
globalnych. Poza tym Dybvigowi to jest potrzebne do leniwych podstawień
przy lambdach, ale nie rozumiem, po co w ogóle coś podstawiać przy
lambdach.

Wady: być może to już wymaga leniwego kolorowania. Bo inaczej będziemy
kolorować argument makra dwa razy zamiast ani razu, a ten argument może
być duży. Poza tym funkcje odpowiadające scheme'owym bound-identifier=
i free-identifier= (które nie wiem, jak bardzo są potrzebne ani jak
powinny być zaimplementowane) być może są trudniejsze w realizacji,
a być może nie.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/