[speagram] Re: podsystemy

[Lukasz K. <luk...@gm...>]

Hej.

Odpowiedz nalezy do cyklu rozmow autystycznych.

> Ostatnio mi sie wydaje, ze jesli dac mozliwosc dodawania do kazdej funkcji
> i typu jakiegos opisu (zwyklego stringa) ...

Ja napisze troche wiecej jak to widze i czemu podsystemy takie jak sa nie wydaja
mi sie najlepsze. Po pierwsze jak to widze:
1) kazda definicja funkcji, typu, danych oraz regula parsowania w
systemie ma liste tagow
2) tag to para (key : string = value : string)
3) po starcie speagramu aktywne sa jedynie reguly z tagiem core=true,
inne reguly
    parsowania trzeba aktywowac podajac jako argument liste tagow ktore powinny
    byc ustawione na zadane wartosci
4) problem identycznych nazw: moglo by sie zdarzyc, ze jakas funkcja
nie jest aktywna
    i zostanie zdefiniowana funkcja o identycznej nazwie; moglibysmy
chciec miec dwie
    identycznie nazywajace sie funkcje o roznych tagach - jak to zrobic ?
    Mysle, ze w taki sposob:
    Po pierwsze do kodowanej nazwy definiowanej funkcji / typu powinno byc
    dodawane jednoznaczne id - to pozwala trzymac w systemie funkcje o
identycznych
    nazwach i roznych tagach.
    Po drugie aby korzystac z dwoch takich funkcji rownolegle trzeba
dac mozliwosc
    aktywacji ktora dodaje wartosc zadanego tagu.
    Wyobrazam to sobie tak, ze jesli mam dwie funkcje fib, jedna ma
tak module = foo,
    druga ma tag module = bar, to system powinien zachowywac sie w taki sposob:
    - jesli zrobie activate nil to powinien probowac aktywowac
wszystkie dostepne reguly
      parsowania i wykryc, ze dwie sa identyczne i zglosic blad nie
aktywujac nic
    - jesli zrobie za to activate nil with tag module, to rowniez
powinien probowac
      aktywowac wszystkie, ale te ktore posiadaja tag module powinny
go uwzgledniac,
      tzn. nie bedzie mozna napisac fib 3, tylko fib 3 with module =
foo albo bar.

Mam nadzieje, ze to wystarcza jako krotki opis mojego spojrzenia na sprawe.
Sa oczywiscie rozne potencjalne wady i zalety. Oczywiscie wszystko zaczyna sie
od tego, ze uzywanie podsystemow tak jak namespace w innych jezykach nie pasuje
do speagramu bo wywolania funkcji nie sa standardowe. Powinno byc tez jasne, ze
majac tagi da sie zrobic wszystko to na co pozwalaja podsystemy a
nawet wiecej, bo
mozna otagowac funkcje roznymi tagami co czasem moze byc przydatne.

Jest kwestia zlozonosci, ale ja uwazam ze i tak jesli chodzi o
wyszukiwanie regul
parsowania, definicji typow i funkcji i danych to bedziemy musieli
zmienic obecne
listy na tablice hashujace, bo inaczej to nigdy nie bedzie wydajne. Jak to juz
zmienimy to trzymanie wszystkiego na jednym poziomie nie powinno byc problemem,
byc moze trzeba bedzie uwazniej algorytmicznie dobrac struktury danych do
slownikow, zeby moc wyszukiwac po tym co potrzeba.

Dla mnie tagi moga tez pomoc zrobic nasz kod czytelniejszym. Jesli to bedziemy
robili to chcialbym przerzucic ciezar obecnego "named ..." na tagi,
tzn. odpowiedni
tag mowiacy o nazwie. Obecny system kodowania i robienia "named" nie
jest niestety
rzecza, ktora bedzie sie skalowac, bo ma problemy z taka sama nazwa pare razy
oraz powoduje klopoty z koniecznoscia nadawania nazw wczesnie zeby mozna ich
uzywac. Ogolnie to jest dziwne, ze coding jest kompilowane jeszcze zanim jest
w ogole definicja systemu, potem trzeba podmieniac te dummy names na prawdziwe
i myslec, zeby o niczym nie zapomniec - to nie jest ladnie a z tagami
byloby ladniej.
Dodatkowo okreslanie ktora regula definiuje zmienna a ktora nie (co
jest wazne, bo
te ze zmiennymi sa usuwane przy finalize) tez jest teraz nieco poza
kontrola i daloby
sie to kontrolowac tagiem. Trzeba tez bedzie kiedys umozliwic usuwanie z systemu
typow i funkcji a razem z nimi trzeba wyrzucac dotyczace ich reguly
parsowania. Zeby
pamietac ktora regula dotyczy ktorej funkcji / typu moznaby probowac
jakos to odczytac
z definicji i nazw tych typow / funkcji, ale to moze nie byc takie
proste i uzywanie tagow
zamiast tego (no i dostosowanie struktury slownika zeby uzyskac dobra wydajnosc)
wydaje sie lepszym rozwiazaniem. Rowniez sam zbior aktywych regul moze byc po
prostu wyrozniony tagiem i pobierany gdy trzeba jesli typ danych
slownika bedzie wystarczajaco dobrze zaprojektowany i efektywny
algorytmicznie.

Po przedstawieniu tych rzeczy jeszcze jedna uwaga praktyczna - to jest
oczywiscie
bardzo duzo roboty i nie zrobimy tego na 0.1. Ale ja bym chcial,
zebysmy do tego czasu
sie zdecydowali czy robimy to w ten sposob i spisali dosc porzadny
design. Wyjasniam,
dlaczego to jest potrzebne. Otoz musimy w miare ustabilizowac typ
wiadomosci wysylanych do systemu zeby mozna oddzielic rzeczy ze
speagram core i oddzielic je
zupelnie od biblioteki. Biblioteke trzeba zaczac chociaz szkicowac,
glownie po to zeby ludzie mogli swoje rzeczy tam wrzucac i nie musieli
ich przepisywac potem od nowa ani nie kolidowali z naszymi i to jest
zupelnie konieczne na 0.1, bo chociaz to nie bedzie wiele osob, ale
ktos moze zaczac cos w tym pisac (!!!) i bedzie potem na nas bardzo
zly
jak sie tego nie bedzie dalo w zaden prosty sposob przelozyc na nastepna wersje.
Oczywiscie wtedy na wersje 0.1 wyrzucilibysmy w ogole support dla podsystemow,
pewnie i tak zostaniemy z jednym bo czasu jest malo a zeby to zrobic
dobrze to jest
jeszcze duzo pracy. Ale trzeba miec chociaz pojecie co bedziemy robic
zeby przynajmniej typ wiadomosci wysylanych byl w wiekszej czesci
ustalony. Napiszcie prosze, co myslicie i jak wy byscie to zrobili, no
i prosze napiszcie w miare szybko.

- lk