Błąd #1448
Dodatkowy pośredni poziom dopasowań jednak istnieje
Status: | Zamknięty | Start date: | 21 Apr 2011 | |
---|---|---|---|---|
Priority: | Normalny | Due date: | ||
Assignee: | Adam Radziszewski | % Done: | 100% | |
Category: | - | |||
Target version: | - |
Description
Przy odwołaniu się do M odwołujemy się do zmiennej $m:_M, która jest wektorowym opakowaniem na rezultaty działania matcha w apply (i w zamierzeniu apply_ahead, który miałby dwa matche a nie jednego).
Oznacza to jednak, że dla normalnego apply, faktyczne całe dopasowanie operatora match jest pod M->1, i dopiero dalej trzeba by się zagnieżdżać, aby dobrać się do kolejnych poziomów w tym właściwym dopasowaniu.
Czyli coś, z czego nie zdaliśmy sobie sprawy, że dodanie M to dodało "korzeń" odwołań, ale nadal pozostała kwestia tego, że cały match siedzi pod numerem 1 w tym korzeniu, a w apply_ahead by było, że byłby numer 1 na jednego matcha i numer 2 na drugiego. Czyli tak jak nieco wcześniej myśleliśmy zanim jeszcze ":" zmieniło się na "->" - dodanie M tak naprawdę nie zmieniło kwestii pisania 1:1, tylko spowodowało pisanie M:1:1 (tyle że teraz mamy -> zamiast średnika). Rozwiązuje to problem braku korzenia, czyli zmiennej _M, bo teraz jest podana wprost, jednak efekt być może nie jest do końca tym, co nam się wydawało, że będzie
Mam nadzieję, że wytłumaczyłem kwestię jasno.
Pytanie zatem, co z tym fantem zrobimy (abstrahując na razie od tego, że chwilowo zagnieżdżenie operatora -> się nie parsuje). Teraz jestem już zbyt zmęczony, by o tym myśleć, otwieram tylko to issue pod rozwagę.
Bo może to się tak naprawdę zachowuje jak powinno tylko się sami w tym trochę pogubiliśmy. Na pewno ja w chwili obecnej czuję się zagubiony =] Ale wstępnie jak o tym myślę, to ma to zachowanie sens, tylko nie jestem pewien, czy chcemy tak to zostawić.
History
#1 Updated by Adam Wardyński over 12 years ago
BTW naprawiłem kwestię zagnieżdżanych ->, czyli już działa M->1->2
#2 Updated by Adam Wardyński over 12 years ago
Tak myślę, że można by na przykład odrzucić M i wrócić do 1 czy 2 jako korzenia. Nawet samo "->1" mogłoby działać jako skrót do "1->1". "M" jest o tyle fajne, że pokazuje, że to "1" czy "2" nie bierze się z powietrza, tylko z matcha, ale teraz jak już wiem, jak to może wyglądać w gramatyce, wiem, że nie byłoby problemu z całkowitym pominięciem tego pierwszego poziomu "M->"
Bo to co zrobiliśmy to daliśmy "M" myśląc, że zastąpi to "1", a to tylko dodało (na chwilę obecną) korzeń tej "1" czy "2".
Czyli widzę następujące opcje:
1) zastąpienie $m:_M bezpośrednio wynikiem matcha w apply (komplikuje ewentualne apply_ahead)
2) całe "M->" jednak można olać i traktować jako domyślne (jest to w zasadzie dokładnie to, o czym myślałeś wcześniej, tylko ze strzałką a nie dwukropkiem)
3) zostawić, jak jest
#3 Updated by Adam Radziszewski over 12 years ago
Trochę dziwne jest to, że mimo wszystko wywalało się też wywołanie M->1, które teoretycznie powinno było działać nawet w przypadku podwójnego zagnieżdżenia (ale może to inny błąd).
W każdym razie proponuję przyjąć rozwiązanie pierwsze, tj. niech apply generuje od razu wektor zawierający kolejne wyniki matcha. W razie potrzeby dodania apply_ahead
doda się jeszcze jeden poziom tu i tam i zmieni się semantykę składni skróconej, by wszystko wyglądało tak samo.
A zatem:
1. apply przypisuje do zmiennej $m:_M wektor zawierający kolejne nadrzędne elementy matcha,
2. odwołanie M wskazuje na wektor $m:_M,
3. odwołanie M->1 wskazuje na pierwszy element matcha (np. pierwszy token w match(equal(orth[0], "nie"), equal(orth[0], "jest"))
),
4. odwołanie M->1->1 oznaczać będzie teraz wyłuskanie pierwszego elementu z pierwszego podwektora (np. gdyby był match(repeat...)
).
Jeszcze pytanie: czy da się przejść na zapis skrócony, gdzie można napisać ->1
zamiast M->1
? Jeśli tak, to może lepiej byłoby wrócić do dwukropka zamiast strzałki, bo strzałka wisząca w powietrzu wygląda dziwnie.
#4 Updated by Adam Radziszewski over 12 years ago
Właśnie mnie olśniło, mam jeszcze jeden pomysł:
1. niech dalej $m:_M zawiera opakowanie na jeden element (w przypadku apply)
2. niech skrót składniowy M oznacza $m:_M->1 (w razie wprowadzenia apply_ahead, można zrobić np. A na ten ahead, czyli $m:_M->2)
3. by odwołać się do kolejnych części dopasowania piszemy M->2, M->3->2, co jest równoważne $m:_M->1->2, $m:_M->1->3->2.
Co o tym myślisz? czy to byłoby trudne do zrobienia? (zakładając, że kod teraz działa tak, że zwracane jest opakowanie, to może to byłoby nawet prostsze?)
#5 Updated by Adam Wardyński over 12 years ago
No ten pomysł ze zmianą obecnego "M->1->X" na "M->X", a dla ew. apply_ahead dodanie np. "MA->Y", które by zastąpiło obecne "M->2->Y", mi się podoba.
Natomiast tak, zapis skrócony "->X" oznaczający "M->X" da się zrobić, jeśli chcemy, a oczywiście wtedy zmiana "->" na ":" to już banał. Pytanie, czy chcemy.
To, że wywalało się wtedy M->1 to tak, to był inny błąd, naprawiony w tym orignalnym issue, które otwarłeś. Na sprawę, o której dyskutujemy tutaj, otwarłem właśnie osobne issue.
#6 Updated by Adam Radziszewski over 12 years ago
Ale rozumiem, że na tę dyskusję jest właśnie ten issue, a tamten zamknięty to był błąd operatora wyłuskania, nie?
Jeśli da się pisać :1 w sensie M:1, czyli $m:_M : 1 : 1, to przejdźmy na dwukropek. Taką składnię już widział Michał i podał przykładową regułę, poza tym sama strzałka z przodu będzie myląca. Jeśli natomiast trudno będzie zrobić sam dwukropek/strzałkę z przodu przy zachowaniu tej semantyki, to zostańmy przy strzałkach (M->1).
Chodzi mi o takie zachowanie:
1. M:1 da się skrócić do :1 (podobnie M:1:2:3 do :1:2:3)
2. M oznacza zawsze $m:_M:1
3. Ewentualny apply_ahead wymaga pisania MA:1, skrót :1 dotyczy tylko M (czyli zawsze tego pierwszego elementu).
#7 Updated by Adam Wardyński over 12 years ago
- Assignee changed from Adam Radziszewski to Adam Wardyński
Sądzę, że się da zrobić tak, jak opisane.
#8 Updated by Adam Wardyński over 12 years ago
- Status changed from Nowy to Rozwiązany
- Assignee changed from Adam Wardyński to Adam Radziszewski
- % Done changed from 0 to 100
Jest tak, jak pisałeś na końcu.
Zmiana w git 30f1eae86cc28da025e6445e042a8e587c27145b
#9 Updated by Adam Radziszewski over 12 years ago
- Status changed from Rozwiązany to Zamknięty