[nem-pl] Uwagi różne

[Marcin 'Qrczak' Kowalczyk]

W liście z sob, 21-02-2004, godz. 13:26, Kamil Skalski pisze:

> > 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.
> 
> Przyznasz, że jest to dość zaawansowane zastosowanie makr.

Nie. Do samego odroczenia wykonywania wyrażeń albo wykonywania wyrażeń
kilka razy wystarczają anonimowe funkcje. Tutaj makra pozwalają tylko
pomijać jakieś "fun" i nawiasy, to niewiele.

Dziedzina, w której makra zaczynają mieć duży sens, to własne
konstrukcje wiążące nazwy i dopasowujące wzorce, bo tego się już łatwo
funkcją nie obejmie.

Co gorsza, takie makro można u Was zapisać i będzie działać, dopóki ktoś
nie zechce go użyć w rozwinięciu innego makra. To jest głupie, system po
prostu jest zepsuty. Ograniczenia są sztuczne, wynikają tylko z
niedopracowania rozwijacza makr.

> Jestem pewien że długo utrzymywałbym argumentację, że programista nie chciałby 
> aby jego 'bar()' (Foo.A.bar () w jego intencji!) został nagle złapany przez 
> jakiś "obcy" bar wprowadzony jako definicja przez makro.

Ależ chciałby - w końcu po to wstawił definicję bar, żeby w jej zakresie
bar oznaczał zdefiniowaną rzecz. Nie musi nawet pamiętać, które
konstrukcje definicyjne są wbudowane, a które są makrami.

> Jest tu pewien konflikt w interpretacji zasady lexical scoping.

Nieprawda, konflikt jest w Nemerle. To, że definicja jest zrealizowana
przez makro, a nie jest wbudowana w kompilator, nie ma prawa psuć
wiązania nazw.

> To że uważasz to za normalne, nie jest dostatecznym argumentem. Chodzi mi o 
> przykład, który w systemie sterylnych makr jest łatwiej / jaśniej zrobić niż 
> w prostym systemie.

Robimy jakiekolwiek makro wprowadzające definicję, np. makro którego
używa się tak:
   lazy v = expr;
i które wprowadza leniwą zmienną: pobranie jej wartości za pierwszym
razem oblicza expr, za następnymi razami od razu zwraca wcześniej
obliczoną i zapamiętaną wartość.

Sprawdzamy w jakiejś funkcji - makro działa. Próbujemy użyć tego makra
wraz z wprowadzaną przez niego nazwą w rozwinięciu innego makra - nie
działa, kompilator protestuje o nieznany identyfikator albo wstawia
zupełnie inną wartość, która akurat była dostępna pod taką nazwą na
zewnątrz drugiego makra.

Inny przykład. Robimy jakiekolwiek makro, któremu przekazujemy wzorzec
i wyrażenie do umieszczenia w zakresie tego wzorca. Na przykład
produkcję gramatyki bezkontekstowej, która ma podaną listę symboli
terminalnych i nieterminalnych wraz ze wzorcami (które zwykle są
identyfikatorami), na które zostaną podstawione atrybuty odpowiednich
poddrzew, oraz akcję do wykonania, która używa tych identyfikatorów.
Makro działa. Próbujemy wygenerować gramatykę innym makrem, która
pozwala pisać zsczególne przypadki gramatyki w uproszczony sposób -
przestaje działać, identyfikatory się nie wiążą.

> Nie zgadzam się. Proste podejście jest bardzo spójne (śmiem nawet sądzić że 
> bardziej niż sterylne)

Nieprawda, właśnie jest niespójne. Ten sam fragment kodu inaczej wiąże
nazwy w głównym programie, a inaczej w rozwinięciu makra. Definicje
zrealizowane makrami nie są w stanie symulować takiego wiązania nazw,
jak wbudowane definicji.

> no i można wyrazić w nim wszystko co w tamtym

Nieprawda, nie da się zrobić makra wprowadzającego definicję, które jest
używalne nie tylko w głównym programie, ale i w rozwinięciach innych
makr.

> jeśli coś jest nie takie jak uważasz, to używaj $(..) + NewSymbol, co nawiasem 
> mówiąc jest nadal higieniczne.

Nie nadal, tylko właśnie zaczyna być niehigieniczne. Nie pozwalasz
zapisać higienicznego użycia makra, naturalny zapis nie jest nawet
interpretowany niehigienicznie, tylko po prostu nie działa i trzeba
wymyślać jakieś obejścia.

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