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

Kamil Skalski nazgul at omega.pl
Wed Feb 25 23:07:35 CET 2004


Tuesday 24 of February 2004 21:27, Kamil Skalski wrote:

Oto aktualny pomysł (upraszcza się na szczęście a nie odwrotnie
>
> 1. każde makro musi przechowywać w sobie środowisko otwarte w miejscu jego
> definicji (namespacey, moduł w jakim się ono znajduje)

Nie musi, z użyciem zmiennych quotowanych będzie związana interperacja danej 
zmiennej jako symbolu widocznego globalnie w miejscu definicji quotowania

> 2. przed ekspansją dowolnego makra, jego parametry zostają opakowane w
> specjalną strukturę, definiującą nowy, unikalny numerek - w zamierzeniu
> jest to leniwa wersja dodawania tego numerku do wszystkich identyfikatorów
> występujących w tych wyrażeniach), stos numerków jest też zapamiętywany w
> kontekście typowania

Nie - nowy numerek będzie rzeczywiście generowany podczas uruchomienia każdego 
kolejnego makra, ale będzie on sobie siedział statycznie w kontekście 
typowania i każde stworzenie obiektu zmiennych będzie go sobie pobierało i 
zapisywało. W ten sposób zmienne wprowadzane przez aktualnie uruchamiane 
makro automatycznie będą miały przypisywany bieżący numerek (są tworzone w 
trakcie jego uruchomienia). Zatem zarówno parametry wywołania makra, jak i to 
co ono zwraca są już ponumerowane, żadnej leniwości, żadnych kłopotów.

> 5. napotkane w typowaniu identyfikatory są typowane z uwzględnieniem
> numerków, gdy są różne, to id nawet o tej samej nazwie są różne

Dokładnie - to wymaga tylko niewielkiej modyfikacji w typowaniu + możliwość 
wprowadzania "lepkich" niehigienicznych symboli i żeby się odpowiednio 
znajdowały... chyba banał

> 6. nazwy wprowadzane niehigieniczne przez $("bla" : var) są "lepkie" - to
> znaczy jeśli jest użyciem zmiennej to wiąże się z najpóźniej zdefiniowanym
> identyfikatorem o tej samej nazwie (ignorując swój brak numerka), jeśli
> jest deklaracją, to dodawany jest na razie bez numerka i pierwsze użycie
> zmiennej o tej nazwie da mu swojego (alternatywą jest przydzielenie mu
> numerka aktualnej ekspansji, może to jest lepszy pomysł) - w tym punkcie
> można sobie zrobić krzywdę, dlatego niezalecane jest używanie
> niehigienicznych makr 

Umożliwiamy brudne wstawianie właśnie wg tej semantyki, ale generalnie chyba 
nie będzie zbyt użyteczne i może się kiedyś to wywali.

> 7. pomysł od Marcina, żeby dostępna była funkcja, 
> która tworzy identyfikator tak, jakby był on użyty w miejscu użycia
> aktualnie ekspandowanego makra - pozwala to w kontrolowanie niehigieniczny
> sposób złapać zmienne użyte piętro wyżej, w szczególności w otrzymanych
> parametrach dla makra

Będzie do tego specjalna funkcja, która wygeneruje zmienną z numerkiem wziętym 
z wyrażenia będącego wywołaniem bieżącego makra (musi być zapisywany w 
kontekście typowania)

> 8. dostępna jest też stara dobra funkcja NewSymbol, dzięki której można
> sobie używać zmiennych przenaszalnych między quotowaniami, makrami,
> ekspansjami 

Będzie potrzebna tylko gdy nie chcemy sami nawadać zmiennej żadnej nazwy, a 
jak chcemy to piszemy
def y = <[ x ]> i mamy coś w stylu NewSymbol ("x") tak jak kiedyś Marcin pisał

> 9. standardowo z makr nie wycieka żadna deklaracja, choć 
> teoretycznie gdyby algorytm okazał się odporny na to, to można z tego
> zrezygnować

To nadal pozostaje zasadą, choć jak się przekonamy że z naszym systemem działa 
dobrze to pewnie jednak pozwolimy. Z kontrolowaną niehigieną (definiowanie 
zmiennych z poziomu wyżej) to może mieć sens :)

Kamil





More information about the devel-pl mailing list