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

[Kamil Skalski]

Saturday 28 of February 2004 00:30, Marcin 'Qrczak' Kowalczyk wrote:
>
> 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.

Hmm, to jak w takim razie właściwie definiujesz niehigieniczne zmienne? Bo ja 
je rozumiem jako takie, które mogą przykleić się do czegokolwiek. 
Rzeczywiście generalnie nie powinny być nigdy używane - mechanizmy które 
dajemy (w tym nazwy pokolorowane miejscem użycia makra) są bardzo bogate i 
chyba wystarczające. 

Zacząłem już implementację systemu i wydaje się, że wprowadzenie/zlikwidowanie 
niehigienicznych makr, to jest zmiana jednej lini kodu. Zanim jednak będziemy 
czegoś takiego próbowali musimy wszystko doprowadzić do końca i usunąć z 
samego kompilatora użycia niehigieny. 

Kwestią otwartą jest czy pozwalać na niehigienę, natomiast jeśli już jest, to 
chyba w takim znaczeniu jak pisałem... inaczej sobie nie wyobrażam, który 
kolor miałoby dostawać? Ten sam co <[ x ]>? to wtedy nie jest niehigieniczne.

>
> 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!

char buf[1024];
for (i = 0; i <= 1024; i++) buf[i] = 0;

Twój argument jest taki jak powiedzenie, "ale operator przypisania pozwala na 
pisanie powyższego kodu! tak nie może być!"
Niehigiena z definicji pozwala coś zepsuć.


> 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.

Aha, teraz już rozumiem. Tak to jest jak się nie ma imperatywnych elementów w 
języku. Złożoność wszystkich algorytmów wzrasta o czynnik O(n) i trzeba 
stosować różne hacki, które to likwidują (wprowadzając same złożoność 
O(n * log n) ;-P)

Kamil