Dnia Wed, 16 May 2012 09:18:30 -0700, Andrzej Jarzabek napisal:

> On May 16, 10:58 am, Edek Pienkowski <e...@g...com>
> wrote:
>> Dnia Wed, 16 May 2012 01:07:12 +0100, Andrzej Jarzabek napisal:
>>
>> > On 16/05/2012 00:00, Edek Pienkowski wrote:
>> >> Dnia Tue, 15 May 2012 21:39:36 +0100, Andrzej Jarzabek napisal:
>>
>> >> Tak więc w językach znanych przez kolegę "pierwszeństwo i stronność... "
>> >> - no, mądre słowo - "są określane przez gramatykę". Ale kolega ma świadomość
>> >> istnienia języków funkcyjnych. Hmm.
>>
>> > I?
>>
>> >> A gdyby tak powiedzieć, że nie musi tego określać gramatyka i że to byt
>> >> określa świadomość?
>>
>> > Jeśli kolega ma do npisania coś konkretnego, to może kolega napisać, nie
>> > wykluczam nawet, że z ciekawości przeczytam.
>>
>> Jakiś konkret do którego można się odnieść by się przydał, nie wiem co
>> miałoby być konkretem.
>
> No proszę bardzo: chcę sobie zdefiniować operatory, powiedzmy, @ i #,
> powiedzmy w ten sposób, żeby (a @ b # c) parsowało się jako a @ (b #
> c), (a @ b @ c) jako (a @ b) @ c, a (a # b # c) jako a # (b # c).
> Oczywiście mam też szczegółowe wymagania co do tego, jak powinny się
> parsowac (a + b @ c), (a # b * c) i tak dalej. Niech kolega da
> konkretny przykład języka, w którym można to zrobić i napisze jak jest
> to rozwiązane w kwestii gramatyki języka i budowy kompilatora.

Przykładem takiego języka jest Ocaml, mozna tam defniować własne operatory
a pierwszeństwo zależy od pierwszej litery operatora a chyba w innej
wersji od deklaracji ze specjalną składnią. Ale to nie jest najlepszy
przykład; może lepsza byłaby Scala, ale nie pamiętam czy da się
definiować własne operatory right-associative.

Jakikolwiek język homoikoniczny pozwoliłby na to, o ile dałoby się
nie używać eval a mieć Listener przed wykonaniem, ale na etapie kompilacji
nie byłoby to rozwiązanie silnie typowane.

Teoretycznie:

powiedzmy że chcemy mieć język silnie typowany i mamy wyrażenie

a ble b ble c bli (d ble c)

Mamy też tablicę symboli a parser stworzy coś takiego
<expr>
/
[a,ble,b,ble,c,bli,<parenthised-expr>]
/
[d,ble,c]

gdzie [a,b,c] jest listą a to co pominąłem to fakt że wszystko w tych
listach jest akurat tutaj symbolami poza <parenthised-expr> potrzebną
do odrzuconej później ewentualności potraktowania bli jako funkcji
jednego argumentu.

Z tablicy symboli wiemy że a, b i c to dane typu BleInt, a ble i bli
(może po Koenig lookup) są czymś takiego rodzaju:

infix ble @right @prec(4) (BleInt a, BleInt b) -> BleInt = a * 2 + b;
infix bli @left @prec(3) (BleInt a, BleInt b) -> BleInt = a * 3 + b;

...gdzie wnioskując ze Scali słówko 'infix' można w ogóle pominąć
lub zastąpić jak w Scali przez 'def', czyli dowolną funkcję lub metodę.

Wtedy przekształca się drzewo, [d,ble,c] staje się
<call>(returns BleInt)
/ \
ble <params>
/ \
d c
i po przkształceniach drzewa wyrażenie staje się zwykłym:

ble(a, ble(b, bli(c, ble(d,c))))

na zupełnie jednoznaczych regułach, gdzie niższy @prec ma wyższy priorytet
i stosowane są reguły left i right. Mamy też silne typowanie.

Jakiś problem, tak konkretnie?

Zostają jeszcze bardziej skomplikowane reguły dot. promocji typów,
ale istnieją języki, gdzie można reguły promocji definiować wprost.

>
>> >>> Ze swobodnym definiowaniem operatorów problem jest taki, że ich
>> >>> pierwszeństwo i stronność są określone gramatyką języka. Zmienianie tego
>> >>> na bieżąco przy pomocy samego programu w tym języku wydaje się
>> >>> problematyczne - być może, że wręcz prowadzi do nierozwiązywalnych
>> >>> problemów, a na pewno standardowy model skaner-parser-translacja trafiłby
>> >>> szlag.
>>
>> Z OO ma to dwa rodzaje związku. Pierwszy: tak jest w większości popularnych
>> języków obiektowych, ale nie wynika to z niczego, jest szczegółem
>> implementacyjnym.
>
> Jest tak chyba również w większości popularnych języków
> nieobiektowych, przynajmniej tych, w których w ogóle są operatory
> infiksowe? Statystyki nie prowadziłem, ale na dzień dobry tak ma C,
> Pascal, Perl, PHP, SQL, Fortranie, Lua i czym tam jeszcze.

Nic nie wiem o tym, żeby w C czy SQL można było przeciążać operatory.

>
>> Parser gcc zamienia niektóre (x-x) na odpowiedniego typu
>> zero, ale to nie znaczy że musi to robić akurat parser, późniejsze stadia
>> mogą implementować taki folding. Podobnie jest z operatorami, można już po
>> parsowaniu przekształcić graf składni.
>
> Pewnie że można, pytanie - jak i na podstawie czego?
>
> BTW przypomniało mi się: W Groovym oprócz normalnego definiowania
> operatorów, można również wprowadzić lokalne i globalne transformacje
> drzew składniowych, które potencjalnie mogą właśnie przekształcić
> sparsowane drzewko. Teoretycznie możnaby się zastanawiać nad użyciem
> tego do zmiany pierwszeństwa i stronności operatorów, a nawet
> wprowadzania nowych, ale wydaje mi się, że byłoby to raczej trudne.

Transformacje drzewa - o ile drzewo jest wyrażeniem - można przeprowadzić
nawet w C++ podczas kompilacji, oczywiście używając programowania
generycznego. Również zamieniając pierwszeństwo operatorów i/lub
stronność, z tym że trywialne to to nie jest.

Edek