W dniu środa, 16 maja 2012 13:12:55 UTC+1 użytkownik napisał:

> a czemu & przed rest, pewnie i rest i dolist i defun sa sowami
> kluczowymi wiec po co & przed rest?

Nie. &rest (w przybliżeniu) jest "słowem kluczowym". (Tak dokładniej to jest zwykłym
symbolem, który ma specjalne znaczenie w pewnych kontekstach w języku, zwanych
lambda-listami (lambda-lists).)

http://www.gigamonkeys.com/book/functions.html#rest-
parameters
http://www.lispworks.com/documentation/HyperSpec/Bod
y/26_glo_l.htm#lambda_list

do góry

ok, akurat lispa to nie mam czasu sie teraz uczyc,
pytam jedynie przy okazji bez tendencji do czytania
o lispie ;-)


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

do góry

W dniu 2012-05-16 14:12, f...@N...gazeta.pl pisze:
> Piotr Chamera<p...@p...onet.pl> napisał(a):
>
>> W dniu 2012-05-16 13:32, f...@N...gazeta.pl pisze:
>>>> albo można je łatwo zdefiniować:
>>>
>>>> (defun printall (&rest all)
>>>> (dolist (x all) (princ x)))
>>>
>>>> CL-USER> (printall "ala" "ma" "kota")
>>>> alamakota
>>>> NIL
>>>
>>> no nawet w miare w tej linijce (printall "ala" "ma" "kota")
>>> bo krotko, ale w c mogloby byc czesto mniej o nawias,
>>>
>>> a co to jest "&rest" i "(x doall)" ?
>>
>> (&rest all) oznacza mniej więcej tyle, że wszystkie pozostałe argumenty
>> przekazane do funkcji zostaną zebrane w listę i będzie ona w ciele
>> funkcji dostępna pod podaną nazwą (w tym przypadku nazwałem ją „all”)
>> A to (dolist (x all) (princ x)) po prostu iteruje po liście i na każdym
>> elemencie „x” na liście „all” wykonuje funkcję „princ”.
>
> a czemu& przed rest, pewnie i rest i dolist i defun sa sowami
> kluczowymi wiec po co& przed rest?

Tak to zdefiniowano w języku, że przy definiowaniu sygnatury funkcji
można użyć symboli ,,&rest", ,,&optional", ,,&key", ,,&aux" (i innych)
i mają one w tym kontekście jakieś określone znaczenie dla kompilatora.
Poza tym można zdefiniować funkcję lub makro o takiej nazwie i niczemu
to nie przeszkadza:

CL-USER> (defun &rest (x) x)
&REST

CL-USER> (&rest 1)
1

CL-USER> (defun printall (&rest all) (map nil #'princ all))
PRINTALL

CL-USER> (printall "ala" "ma" "kota" 123)
alamakota123
NIL

CL-USER> (&rest "abc1")
"abc1"

,,Dolist" i ,,defun" są zwykłymi symbolami, do których standardowo
,,przypisane" są makra odpowiednio: iterujące po liście i definiujące
funkcję, ale można im przypisać inne operacje. W Common Lispie nie ma
słów kluczowych w takim znaczeniu jak w C, kompilator (lub interpreter)
operuje na listach symboli. Pierwszy symbol na liście jest
,,operatorem", reszta ,,argumentami". To jak ta reszta jest traktowana,
zależy od tego do czego ewaluuje się ,,operator" - makra, funkcji, czy
czegoś jeszcze innego.

do góry

<f...@g...pl> napisał(a):

> M.M. <m...@g...pl> napisał(a):
>
> > fir <f...@g...pl> napisał(a):
> >
> > > czy wystepuja jezyki z definiowaniem
> > > operatorow (inne niz c++, gdzie zresztą
> > > to definiowanie jest bardzo ograniczone -
> > > mozna sobie wyobrazic jezyk ze tak swobodnym
> > > definiowaniem operatorow jak funkcji, moze
> > > to skrociloby listingi choc trudno powiedziec)
> >
> > Czy ja wiem, czy to może istotnie skrócić listingi?
> > W moim odczuciu, poza nielicznymi wyjątkami, przeładowanie
> > operatorów tylko utrudnia parsowanie kodu w oczach. Wyjątki o
> > których mowa to np. zdefiniowanie operatora w standardowej/popularnej
> > bibliotece co powoduje że oczy każdego programisty dobrze
> > przywykły do ich używania.
> >
>
> trudno powiedziec, w sumie taki operator (jak z przykladow
> wczesniej) to tylko troche inny sposob wywolania funkcji
W Javie nie ma (chyba że jakoś niedawno dodali i nie zdążyłem
uzupełnić informacji) i nie powoduje to 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. W językach
specjalistycznych oczywiście jest inaczej, warto konstrukcjom
używanym najczęściej zaprojektować zwartą syntaktykę - czyli
nie tylko operatory.

> - jest to oszczedniejsze w znaki w stosunku do wywolan funkcji
> ale tez o ilestam trudniejsze w czytaniu - z tym ze c w pewnym
> sensie jest pomyslane dla zaawansowanych, ludzi ktorzy nawykli,
Niby racja. Ale np. ja co nabiorę wprawy w dziwolągach
danego języka a potem przez kilka miesięcy nie mam okazji ani
zawodowo ani hobbystycznie używać/trenować to zapominam. Czas
który poświęcam na naukę/przypomnienie składni mógłbym lepiej
spożytkować.

Zadajmy w prośbie o szczerą odpowiedź choćby takie pytanie:
Ile osób mówiących o sobie że zna dobrze C++ była świadoma
problemu operatora >> (przesunięcie bitowe) przy szablonach?


Pozdrawiam


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

do góry

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.

do góry

On Wednesday, May 16, 2012 5:09:45 PM UTC+1, M.M. wrote:
> W Javie nie ma (chyba że jakoś niedawno dodali i nie zdążyłem
> uzupełnić informacji) i nie powoduje to problemów. Wątpię

Obliczenia z algebry liniowej w Javie wygladaja ohydnie. Zamiast

A = B*C;

masz

A = B.multiply(C);

itd. Java rowniez nie ma szablonow, w ktorych przeciazanie operatorow
umozliwialoby traktowanie typow prymitywnych i klas na rownych (more or less)
prawach.

> Zadajmy w prośbie o szczerą odpowiedź choćby takie pytanie:
> Ile osób mówiących o sobie że zna dobrze C++ była świadoma
> problemu operatora >> (przesunięcie bitowe) przy szablonach?

Moi.

RW

do góry

fir <f...@g...pl> wrote:
> czy wystepuja jezyki z definiowaniem
> operatorow (inne niz c++, gdzie zresztą
> to definiowanie jest bardzo ograniczone -
> mozna sobie wyobrazic jezyk ze tak swobodnym
> definiowaniem operatorow jak funkcji, moze
> to skrociloby listingi choc trudno powiedziec)
>
> czy sa takie jezyki i jak to wyglada?
... 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
smtp:/home/adam>
Z powazaniem
Adam Przybyla

do góry

M.M. <m...@g...pl> napisał(a):

> <f...@g...pl> napisał(a):
>
> > M.M. <m...@g...pl> napisał(a):
> >
> > > fir <f...@g...pl> napisał(a):
> > >
> > > > czy wystepuja jezyki z definiowaniem
> > > > operatorow (inne niz c++, gdzie zresztą
> > > > to definiowanie jest bardzo ograniczone -
> > > > mozna sobie wyobrazic jezyk ze tak swobodnym
> > > > definiowaniem operatorow jak funkcji, moze
> > > > to skrociloby listingi choc trudno powiedziec)
> > >
> > > Czy ja wiem, czy to może istotnie skrócić listingi?
> > > W moim odczuciu, poza nielicznymi wyjątkami, przeładowanie
> > > operatorów tylko utrudnia parsowanie kodu w oczach. Wyjątki o
> > > których mowa to np. zdefiniowanie operatora w standardowej/popularnej
> > > bibliotece co powoduje że oczy każdego programisty dobrze
> > > przywykły do ich używania.
> > >
> >
> > trudno powiedziec, w sumie taki operator (jak z przykladow
> > wczesniej) to tylko troche inny sposob wywolania funkcji
> W Javie nie ma (chyba że jakoś niedawno dodali i nie zdążyłem
> uzupełnić informacji) i nie powoduje to 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. W językach

trudno powiedziec na ile to by bylo uzyteczne, ale jest to
w syntaktycznym sensie ogolniejsze nic wywolania funkcji i
daje pewne nowe mozliwosci i o tyle jestem w pewnym stopniu za

niesie tez problemy, dla mnie glowny jaki widze polega na tym
ze takie operatorowe pisanie odziela w jakims stopniu od
fizycznej warstwy c, (mniej 'widac' te poszczegolne wywolania,
np jakos latwo napisac przy pomocy operatorow to co w normalnej
wersji by bylo odrzucone np

z = a cat b cat c cat d cat e;
(vel
z = a + b + c + d + e; )


dla scalanis stringow (normalnie jakos takich rzeczy nie
pisze bo pisze to wogole jakos inaczej (na nizszym poziomie)
(i w sumie zapewne lepiej - choc ten przyklad moze jest nieco
fikcyjny)


o samym jezyku w jego przeswitujacej na asma wersji w wydaniu
operatorowym gorzej by sie pewnie myslalo; pewnie tez czesciej
by sie popelnialo bledy np nazwy operatorow i zmiennych nie
moglyby kolidowac itd

zdaje sie jednak ze moglyby byc jednak jakies bonusy, poza
mniejsza liczba nawiasow np 'generyczny' sposob traktowania
funkcji (operator mozna nazwac funkcja) np moznaoczekiwac
ze takie operatory jak init draw print itp bedą traktowane
bardziej generycznie i bedzie np oczekiwane ze dla wszystkich
encjo zdolnych do narysowania sie draw bedzie dostarczone
i tak dalej (to w sumie zachacza o moj stary pomysc 'nctx'
z wieloczlonowymi nazwami jak

draw (Costam* c) at (int x, int y)
{

}

bo to jedno i to samo mniej wiecej z tym ze tu draw at
jest traktowane jako trojargumentowy dwuskładnikowy operator




> specjalistycznych oczywiście jest inaczej, warto konstrukcjom
> używanym najczęściej zaprojektować zwartą syntaktykę - czyli
> nie tylko operatory.
>
> > - jest to oszczedniejsze w znaki w stosunku do wywolan funkcji
> > ale tez o ilestam trudniejsze w czytaniu - z tym ze c w pewnym
> > sensie jest pomyslane dla zaawansowanych, ludzi ktorzy nawykli,
> Niby racja. Ale np. ja co nabiorę wprawy w dziwolągach
> danego języka a potem przez kilka miesięcy nie mam okazji ani
> zawodowo ani hobbystycznie używać/trenować to zapominam. Czas
> który poświęcam na naukę/przypomnienie składni mógłbym lepiej
> spożytkować.
>
> Zadajmy w prośbie o szczerą odpowiedź choćby takie pytanie:
> Ile osób mówiących o sobie że zna dobrze C++ była świadoma
> problemu operatora >> (przesunięcie bitowe) przy szablonach?
>
>
> Pozdrawiam
>
>


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

do góry

On Wednesday, May 16, 2012 5:41:12 PM UTC+1, Adam Przybyla wrote:
> fir <f...@g...pl> wrote:
> > czy wystepuja jezyki z definiowaniem
> > operatorow (inne niz c++, gdzie zresztą
> > to definiowanie jest bardzo ograniczone -
> > mozna sobie wyobrazic jezyk ze tak swobodnym
> > definiowaniem operatorow jak funkcji, moze
> > to skrociloby listingi choc trudno powiedziec)
> >
> > czy sa takie jezyki i jak to wyglada?
> ... 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
> smtp:/home/adam>
> Z powazaniem
> Adam Przybyla

Ale to nie jest definicja nowego operatora, tylko przeciazanie starego.

RW

do góry

Roman W <b...@g...pl> napisał(a):

> Obliczenia z algebry liniowej w Javie wygladaja ohydnie. Zamiast
> A = B*C;
> masz
> A = B.multiply(C);
Jest kilka wyjątków w których i ja lubię przeciążanie operatorów. Ten
który podałeś akurat popieram.

> itd. Java rowniez nie ma szablonow, w ktorych przeciazanie operatorow
> umozliwialoby traktowanie typow prymitywnych i klas na rownych (more or
> less) prawach.
Ale nie doskwiera to jakoś mocno. Co za problem pisać owe
A = B.multiply(C) ? Dla mnie dużo gorsze jest przedzieranie
się wzrokiem (zwłaszcza gdy to jest nadwątlony wzrok) przez
zawiłą składnię.

>> Zadajmy w prośbie o szczerą odpowiedź choćby takie pytanie:
>> Ile osób mówiących o sobie że zna dobrze C++ była świadoma
>> problemu operatora >> (przesunięcie bitowe) przy szablonach?

> Moi.
To trzeba pogratulować.

Pozdrawiam



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

do góry