> > ... python:
> > #!/usr/bin/python
> > class i:
> > def __init__(self,w):
> > self.w=w
> > def __add__(self,x):
> > return self.w+x.w+1
> >
> >
> > a=i(2)
> > print a+a
> >
> > smtp:/home/adam>python klas.py
> > 5
>
> Ale to nie jest definicja nowego operatora, tylko przeciazanie starego.
>
> RW

co do takiego przeciazania (czyli defakto psucia bo zwykle
dodawanie chyba trudno zmienic nie psujac) zwyklego dodawania
na zwyklych liczbach to bym sie wlasnie raczej zastanowil

uzywanie nowych jest chyba mniej konfundujace niz podmienianie
starych


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

a tak wogole z ciekawostek to jak sie wczesniej zastanawialem
i tak nie da sie w ten sposob zrobic i++, mozna wywolac funkcje(i)
ktora zwroci albo stare i albo nowe, tu w tym postfiksie jest
robiona dodatkowa sztuczka i to ++ nie jest normalna funkcją
w odroznieniu od wiekszosci reszty zwyklych operatorow, ktore
raczej maja raczej odpowiedniki w zwyklych funkcjach intrinsic


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

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

w c dla zwyklych operatorow to robi sie ustalajac priorytety
(0-15 lub cos kolo tego) i kolejnosc przetwarzania (lewa/prawa)
mozna podac przy definici operatora

left priority 7 (int) (int a ) # (int b)
{
return a+b;
}


void main()
{
int a = 8;
int b = 8;

int c = a + 5 # b;
}

skladnie definicji moze moglaby byc lepsza ale raczej da sie zrobic

(wyjasnienie : odpowiadam na watek ale jestem zmuszony zaznaczyc
ze nie znaczy to ze jestem chetny do rozmawiania z niniejszym
grupowiczem (poniewaz swego czasu zarzucil mnie on stosem
takich bezsensow ze pamietam to do dzis) ;-)




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

> wprowadzania nowych, ale wydaje mi się, że byłoby to raczej trudne.

nie widze takiego problemu, na podobnej zasadzie na jakiej
kompilator buduje sobie liste rozpoznanych definicji funkcji
czy encji (zeby nie rzucic syntax error na nierozpoznanym elemencie)
moze zrobic z definicjami operatorow, zapisze sobie na stronie
ich priorytety i zgodnie z tym na koniec wygeneruje kod
mw tak samo jak dla zwyklych funkcji i operatorow

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

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

do góry

On Wed, 16 May 2012 09:18:30 -0700 (PDT), Andrzej Jarzabek
<a...@g...com> wrote:
[...]
> 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.

$ cat Foo.hs
infixl 6 @@
infixr 7 ##

x @@ y = (x,y)
x ## y = (x,y)

main = do
print $ 'a' @@ 'b' ## 'c'
print $ 'a' @@ 'b' @@ 'c'
print $ 'a' ## 'b' ## 'c'

$ runghc Foo.hs
('a',('b','c'))
(('a','b'),'c')
('a',('b','c'))

Pojedynczego @ się tu akurat nie da użyć jako operatora bo jest zarezerwowany.

--
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.

do góry

On 16/05/2012 21:10, Michał Politowski wrote:
> On Wed, 16 May 2012 09:18:30 -0700 (PDT), Andrzej
Jarzabek<a...@g...com> wrote:
> [...]
>> 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.
>
> $ cat Foo.hs
> infixl 6 @@
> infixr 7 ##
>
> x @@ y = (x,y)
> x ## y = (x,y)
[...]

Super, właśnie o to chodziło.

Pytanie w takim razie, jak to wygląda z punktu widzenia gramatyki
języka? Zgaduję, że parser jest dwuprzebiegowy: za pierwszym razem
parsuje grupy w nawiasach czy oddzielone innymi separatorami do list
symboli, a potem do każdej listy efektywnie składa sobie parser na
podstawie widocznych w danym zakresie deklaracji infix.

Miłe w każdym razie. Mental note: Kiedyś w końcu muszę sobie poczytać o
Haskellu.

do góry

On May 16, 6:09 pm, " M.M." <m...@g...pl> wrote:

> W Javie nie ma (chyba że jakoś niedawno dodali i nie zdążyłem
> uzupełnić informacji) i nie powoduje to problemów.

Co to znaczy "nie powoduje problemów"? To jest kwestia czytelności
kodu a nie tego, czy program zadziała.

W jezyku z prawdziwymi szablonami brak przeciążania operatorów byłby
realnym problemem. Czy możeby powiedzieć, że brak przeciążania
operatorów w Javie nie powoduje problemów ze względu na istniejący już
problem braku prawdziwych szablonów? :-p

Tak btw, to Java ma przeciążone operatory - np. operator + jest
przeciążony zarówno dla typu int jak i double (tak, to jest
przeciążony operator). Co ciekawe, jest on również przeciążony dla
typu String, który jest klasą, co by sugerowało, że można przeciążać
operatory dla klas. Ale nie cieszmy się, bo fakt, że operator + jest
przeciążony dla typu String wcale nie oznacza, że możemy mieć taki
operator również dla typu MyString. Ktoś mógłby powiedzieć, że klasa
String jest standardowa, więc ma specjalne prawa, ale jakoś klasy
Integer i spółka takich praw nie mają, jadąc na barana na przeciążonym
(tak!) operatorze typów podstawowych. Klasa BigDecimal też jest
standardowa, ale nie dość, że nie ma żadnych specjalnych praw, to na
żadnym baranie też nie pojedzie.
Co pies, to inaczej szczeka.

Poza tym, faktycznie, braki w Javie "nie powodują problemów".

> Wątpię
> aby w językach ogólnego(!) przeznaczenia był jakikolwiek
> sens intensywnego zastępowania wywołań funkcji operatorami,
> nie wspominając nawet o własnym definiowaniu.

Sens jest taki, żeby nie było takiego burdelu jak powyżej.

a = b + c;

i tyle. Tak to ma wyglądać (lub odpowiednio do ogólnych konwencji) w
języku ogólnego (właśnie!) przeznaczenia.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Thursday, May 17, 2012 8:35:02 AM UTC+1, Maciej Sobczak wrote:
> Sens jest taki, żeby nie było takiego burdelu jak powyżej.
>
> a = b + c;
>
> i tyle. Tak to ma wyglądać (lub odpowiednio do ogólnych konwencji) w
> języku ogólnego (właśnie!) przeznaczenia.

W Javie przeciazenie operatorow ograniczono OIDP zeby uniknac (wyimaginowanych?)
naduzyc typu: "a = b + c;" oznacza ze klient "c" otwiera polaczenie z baza danych "a"
na sockecie "b".

RW

do góry

On 2012-05-17, Roman W <b...@g...pl> wrote:
> On Thursday, May 17, 2012 8:35:02 AM UTC+1, Maciej Sobczak wrote:
>> Sens jest taki, żeby nie było takiego burdelu jak powyżej.
>>
>> a = b + c;
>>
>> i tyle. Tak to ma wyglądać (lub odpowiednio do ogólnych konwencji) w
>> języku ogólnego (właśnie!) przeznaczenia.
>
> W Javie przeciazenie operatorow ograniczono OIDP zeby uniknac (wyimaginowanych?)
> naduzyc typu: "a = b + c;" oznacza ze klient "c" otwiera polaczenie z baza danych
"a" na sockecie "b".

Przez co mamy niesamowicie czytelny kod.
#v+
_65535 = new BigInteger(65535);
result = new BigInteger(2).modPow(new BigInteger(1000), _65535).multiply(new
BigInteger(20)).remainder(_65535);
#v-

--
Secunia non olet.
Stanislaw Klekot

do góry