[nem-pl] Dalej o składni rozszerzeń

[Kamil Skalski]

Hej!

Na początek proponuję zmianę [< >] na <[ ]>, bo ładniej i czytelniej wygląda 
(a i tak jest tymczasowe, może wymyślimy coś lepszego).

> Propozycja jest taka, zeby zmienic gramatyke w taki sposob, zeby mozna
> bylo we wzorcach pisac nie tylko to co jest, ale tez
> [<[typ]: kod >], tzn. do jakiejs reguly (jakiejs, bo nie znam aktualnej
> wersji) pattern := .... doszloby

Taki sposób określania typu trzyma się kupy. Ale rzeczywiście będzie pewnie 
potrzebnych kilka kolejnych typów, chyba że np. definicje funkcji, klasy 
podpiąć pod wyrazenie.

> Jesli chodzi o branchedX to reguly bylyby identyczne jak w zwyklej
> gramatyce, tylko dodatkowo doszloby wyrazenie $(expr: Expr) (lub tez
> jakies inne) dajace mozliwosc wklejania zwyklych wyrazen Nemerle.

Nie rozumiem co chcesz z tym $ robić. Ja myślałem o nim jako metodzie 
wyłuskania informacji z atomowych wyrażeń/typów. Można np. napisać
<[ x $(name, type) <- val ]>
albo może nawet wprowadzić konstruktory do środka
<[ x $(Var(name), type) <- val $(Const(value), type) ]>
gdzie
x - matchuje się do poddrzewa, w tym wypadku zawierającego zmienną
name - do nazwy zmiennej
type - do drzewa typu
value - do wartosci (o ile 'val' nie jest wyrazeniem ani zmienna) o typie 
'type'. Problem jeśli ten typ to coś skomplikowanego, zdefiniowanego gdzie 
indziej... to wymagałoby znajomości tej definicji i otypowania wyrażenia, 
chyba żeby te typy tutaj traktować jak w języku skryptowym tudzież w Prologu, 
to znaczy jako parę t = 'nazwa konstruktora' * list t.

> Nie ma głównej trudności. Po prostu trzeba dopisać odpowiednie reguły.
> I nie spowodować konflików s/r.

Oczywiście to moje zadanie i zajmę się nim, kiedy już wymyślimy w miarę 
dokładnie składnię tego wszystkiego.

> Mysle, ze tak by bylo najlepiej. Type jest potrzebny zeby moc wchodzic do
> klas, nie wiem co jeszcze, bo jak to bedzie wywolywane rekurencyjnie na

No i właśnie tutaj napotkałem na kilka wątpliwości:
wywołania rekurencyjne oczywiście chcemy, są dwie propozycje
-  ext f (a : syntax_tree ) : syntax_tree =
    match a with [
      | <[ x <- y + z ]> -> <[ x <- $f(y) - $f(z) ]>
      ...
     lub inna wersja takiego zmieszania metajęzyka z językiem
-  ext f (a : syntax_tree ) : syntax_tree =
    match a with [
      | <[ x <- y + z ]> -> def (ny, nz) = (f y, f z);
                                    <[ x <- ny - nz ]>
    
Druga oczywiście ładniej wygląda i w ogóle jest przejrzysta, ale jest 
przydługawa i nieco uciążliwa.

Kolejna sprawa to matchowanie list wyrażeń/typów. 
<[ class x { contents } ]> -> ... tutaj 'contents' zmatchuje się z listą 
pól/metod. Pytanie czy dopuszczamy konstrukcję bezpośretnio operujace w 
środku:
<[ class x { var1 : string; contentsrest } ]> -> ... niby bez sensu bo i tak 
musimy tą resztę przerobić osobno, ale kto wie.

No i potem te listy będzie się składać z powrotem
<[ var1: int ]> :: rest -> <[ var1 : float ]> :: (f rest)
lub
... -> def ncontents = g contents;
        <[ class x { costam; costam1; ncontents } ]>

W sumie myślę, że oba sposoby są dobre i nie kłócą się, więc niech zostaną, a 
w razie czego to komentujcie.

> wiekszych czesciach kodu to cos jeszcze moze byc potrzebne. Moze tydecl,
> zeby tworzyc typy gdy sa potrzebne (chociaz raczej tak nie bedzie) ?

Chyba nie będą potrzebne, jeśli zrobimy tak jak pisałem, żeby typy były 
jakimiś stringami czy coś w tym stylu.

Chciałbym zauważyć, że dla mnie parsowanie tych rozszerzeń wcala nie jest 
jeszcze proste. Nie ma ustalonej składni/semantyki $. Nie wiem jakiej postaci 
będą funkcje i pola obiektów:
<[ class _ { $(Var(name), type) }
czy może
<[ class _ { $(Field(name)) : type }
i
<[ class _ { 'a $(Fun(name)) (params) : type } - tu szczególnie wątpliwa jest 
zmienna typowa, bo ona wpływa mocno na parametry... a my byśmy tu rozwalili 
to połączenie.

Następnym razem przejrzę całą składnie języka i spróbuję określić jakąś spójną 
składnie do jej rozbioru. Napiszcie jednak co myślicie dokładnie o $ i jak 
głęboko on powinien się wgłabiać.

Kamil