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

[Marcin 'Qrczak' Kowalczyk]

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

> > Możliwość łamania higieny powoduje, że nie wystarczy pamiętać wyników
> > szukania. Jeśli dana nazwa okaże się nazwą makra, które niehigienicznie
> 
> Wydaje mi się, że problem o którym mówisz występuje zawsze przy użyciu 
> niehigienicznej nazwy - ona nie ma podczepionego znaczenia globalnego.

Chodzi o to, że niehigienicznie wstawiona nazwa będzie musiała być
wyszukana w środowisku, w którym użyto danego makra. To środowisko już
dawno przestało być "bieżące", bo użycie makra mogło być głęboko
schowane w cytacie wstawionym przez inne makro i potem przekazywane
sobie przez różne makra, więc trzeba je gdzieś przechować w drzewie
składni.

Klasycznym rozwiązaniem jest doczepianie go do identyfikatorów i
wyciąganie z nazwy makra. Być może można zamiast tego doczepiać je do
innych wyrażeń, np. do aplikacji (które potencjalnie mogą być
aplikacjami makr), nie jestem pewien.

> > wprowadzi inną nazwę, to w tym samym środowisku trzeba będzie szukać
> > czegoś innego. Czyli niestety trzeba dołączać całe środowisko albo coś,
> 
> Nie widzę różnicy w wywołaniu makra przez kod
> <[ m() ]> i <[ $("m" : var) () ]>
> oba mają te same właściwości i mogą wytworzyć to samo.

Nie wiem, co znaczy $("m" : var). Łamanie higieny, jakie znam ze
Scheme'a, polegałoby na tym, że m jest wyszukane w środowisku wołania
makra używającego tego cytatu kodu zamiast w środowisku cytatu +
środowisku samego makra. To środowisko wołania makra jest pobierane
z nazwy makra (w Schemie jawnie - makro ma dostęp do całej swojej linii
wywołania, tam widzi swoją nazwę, którą poza łamaniem higieny może
ignorować; u mnie niejawnie).

> > Czyli fragmenty kodu wprowadzone przez jedno wywołanie makro osobnymi
> > cytatami kodu będą miały ten sam kolor? W ten sposób co prawda różne
> > makra pisze się łatwiej, ale nie jestem przekonany, że można taki system
> > w spójny sposób zaprojektować.
> 
> Tak i wydaje nam się, że widzimy to spójnie.

Ciekawe. Wygląda na to, że dla typowych makr jest wygodniejsze - ten
sam identyfikator wstawiony przez różne cytaty jest tym samym - za to
w skomplikowanych makrach rozbitych na kilka pomocniczych funkcji wymaga
ostrożności i takie pomocnicze funkcje powinny raczej używać NewSymbol
zamiast polegania na higienie. W ogóle to powoduje, że NewSymbol jako
funkcja staje się potrzebny, bo przy modelu kolorującym każdy cytat
osobno wystarczyłoby <[ x ]>.

> > będzie przekazywany z momentu rozwijania makra do wykonania cytatu kodu
> > w treści makra?
> 
> Przez statycznie dostępny i globalny stos kolorów gdzieś w kontekście 
> typowania. Tu wszystko jest ładne - makro i funkcje których używa tworzą 
> obiekty kodu w momencie ich uruchomienia, wtedy dostają aktualny kolor.

Komunikacja przez zmienne globalne ma być ładna? :-)
Ale może i przejdzie, zastanowię się nad tym dla swojego systemu.

Ciekawe, czy można uniknąć zmiennych globalnych. Skoro kolory zależą od
czasu rozwinięcia makra, a nie czasu użycia cytatu kodu, to może można
by kolorować argumenty makra, a potem całe wywołanie makra, przy czym
kolory się xorują, tzn. jeśli dany kawałek koloru już był to znika.
To by się obyło bez zmiennych globalnych, za to jest kosztowne, jeśli
argumenty makr są duże i makra przekazują je sobie kilka razy - być może
wymaga leniwego kolorowania.

> > BTW, trzeba uważać, żeby pomalowanie nowym kolorem nie ujednoliciło
> > nazw, które wcześniej przy tym samym symbolu miały różne kolory.
> 
> Kolor będzie zawsze się zwiększał, chyba nie ma takiej możliwości.

Sytuacja może mieć miejsce tylko jeśli cytat kodu został wygenerowany
przez makro, a nie wpisany ręcznie. Czyli na razie tego i tak nie
planujecie, ale zgaduję, że w przyszłości trzeba będzie sobie o tym
przypomnieć.

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