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.

> >>> 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.

> 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.