On 2019-01-14 09:36, Maciej Sobczak wrote:
> [kolejność ewaluacji]
> Nie chce mi się sprawdzać dla innych języków, ale nieustalona kolejność ewaluacji
podwyrażeń jest czymś, co akceptuję jako naturalne,

A ja nie.
Ani to naturalne, a (co najgorsze) wprowadza niejednoznacznosc wynikow.
Wcale tez nie wplywa w zauwazalny sposob na optymalnosc ewaluacji.

> ale nadal różne od tego:
>
> a+b-c
>
> vs:
>
> a-c+b
>
> W pozyższym chcę wiedzieć, że kolejność wykonania jest od lewej do prawej, bo to
sprawia, że te wyrażenia są jednak różne i mają różną dziedzinę.

No wiec zeby to wiedziec/byc pewnym w C/C++ zamiast naturalnego:

d = fun(a) - fun(c) + fun(b);

musisz to napisac tak:

typ tmp_a = fun(a);
typ tmp_c = fun(c);
typ tmp_b = fun(b);
d = tmp_a - tmp_c + tmp_b;

Zadne nawiasowanie (czyli zLispienie C/C++:) typu:
d = ((fun(a)) - fun(c)) + fun(b);
Nie pomoze.
Gorzej! Czasami w niektorych starych kompilatorach
pomagalo/dzialalo (o ile pamietam w starym MC C++ < 6.0),
a to dopiero czynilo pasztet, po przeniesieniu takiego kodu
do nowego czy innego kompilatora :)


> Niemniej - jedna z rzeczy, które mi się podobają w Adzie to właśnie podział
podprogramów na procedury i funkcje. Procedur nie da się użyć w wyrażeniu a funkcje
muszą być w wyrażeniu.

W Algolu i Simuli bylo podobnie (tyle ze tam w ogole nie uzywano
nazwy 'funkcja').
Po prostu funkcje w dzisiejszych jezykach progr. (z wylaczeniem
funkcyjnych) to nie zadne funkcje, ale wlasnie procedury (zbior/grupa
akcji/statementow).
Moze wiec moze to 'stare' 'mocherowe' podejscie bylo lepsze i
logiczniejsze od dzisiejszej 'Nowoczesnosci' ?

AK

do góry

> W Haskellu jest (z grubsza) podobnie.
> Tzn. tam wszystko jest funkcją, ale procedury są emulowane za pomocą typu IO, który
ma inne reguły kompozycji, niż zwykłe funkcje.

Obrzydliwość. "Procedury są emulowane" - fuj. Ani odrobinę nie jest to lepsze od
funkcji, która zwraca obrzydliwy pół-typ void, który tu i ówdzie też ma inne reguły.
To również pokazuje, że funkcjonalność jest paradygmatem sztucznym i nie
odzwierciedla potrzeb i szkodzi zdrowiu. Skoro krytykujesz C i C++ za to, że nadużyły
pojęcia funkcji do niewłaściwych celów, to konsekwentnie powinieneś też krytykować
Haskella za to samo. :-)

> > Język tego nie wymusza, ale naturalnie łatwiej wtedy o konwencję, że funkcje robi
się "czyste" a procedury zostawia się na te okazje, kiedy efekty uboczne są celowe.
>
> A dlaczego to jest dobre? ;]

Efekty uboczne? Bo świat ma efekty uboczne, już o tym pisaliśmy. A ponieważ Ada
została stworzona do programowania systemów wbudowanych, które zwykle służą właśnie
do współistnienia z procesami fizycznymi, to ten ficzer w języku pozwala bardzo
czytelnie wpisać się w modelowane problemy. Funkcje zawsze będą potrzebne do
obliczeń, ale procedury są przydatne do popychania stanów i do robienia zmian w
środowisku.

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

do góry

> > Znaczy - nie masz racji co do Pascala,
>
> Mam. Pisalem w (standardowym) Pascalu jeszce na Odrze i wiem co mowie.

Widzę, że dzielnie walczysz dalej.

https://books.google.pl/books?id=NvHjBwAAQBAJ&pg=PA1
66

To jest z Pascal User Manual and Report: ISO Pascal Standard. Strona 166, od
pierwszego do drugiego wcięcia. Nie działa mi Ctrl-C. Fajny przykład w drugiej
połowie tego paragrafu, gdzie nie tylko kolejność, ale w ogóle wykonanie części
wyrażenia nie jest gwarantowane. Tego to nawet w C nie ma.

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

do góry

> No wiec zeby to wiedziec/byc pewnym w C/C++ zamiast naturalnego:
>
> d = fun(a) - fun(c) + fun(b);

Nie zrozumiałeś problemu. Nie chodzi o kolejność wywołania funkcji w podwyrażeniach
(to nie jest gwarantowane i dla mnie OK), tylko o kolejność wyliczenia sum i różnic.
Funkcje mogą być wywołane dowolnie, ale ja w tak napisanym wyrażeniu chcę mieć
gwarancję, że odejmowanie ich wyników będzie zrobione wcześniej, niż dodawanie. Bo
nawet przy czystych funkcjach od tego może zależeć poprawność programu.
Wiesz, dlaczego?

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

do góry

W dniu wtorek, 15 stycznia 2019 08:03:18 UTC+1 użytkownik Maciej Sobczak napisał:
> > W Haskellu jest (z grubsza) podobnie.
> > Tzn. tam wszystko jest funkcją, ale procedury są emulowane za pomocą typu IO,
który ma inne reguły kompozycji, niż zwykłe funkcje.
>
> Obrzydliwość. "Procedury są emulowane" - fuj. Ani odrobinę nie jest to lepsze od
funkcji, która zwraca obrzydliwy pół-typ void, który tu i ówdzie też ma inne reguły.

Nie wiem. Być może pod jakimiś względami jest lepsze.
Choćby pod takim, że jeżeli funkcja może potencjalnie mieć efekt uboczny, to
informacja o tym musi być zawarta w jej typie.
Albo pod takim, że stosunkowo łatwo wyabstrahować od konkretnego świata i dostarczyć
mockową implementację zachowania skutków ubocznych na potrzeby testów.
Albo pod takim, że owe "inne reguły" są mimo wszystko podporządkowane pewnemu
prostemu matematycznemu rygorowi.

> To również pokazuje, że funkcjonalność jest paradygmatem sztucznym i nie
odzwierciedla potrzeb i szkodzi zdrowiu. Skoro krytykujesz C i C++ za to, że nadużyły
pojęcia funkcji do niewłaściwych celów, to konsekwentnie powinieneś też krytykować
Haskella za to samo. :-)

Robię to. Tzn. mnie haskellowe rozwiązanie nie przekonuje, i traktuję je najwyżej
jako ciekawostkę akademicką.
Chciałem jedynie zwrócić uwagę, że zarówno Haskell jak i Ada uważa ten podział za
istotny i oferuje jakieś środki do wyrażania go.
Rozwiązanie z Ady uważam za naturalniejsze - tym bardziej, że nawet sami twórcy
Haskella używają na określenie działania typu IO słowa "magic".

(Tym niemniej, spotykam czasem ludzi, którzy uważają, że imperatywny program napisany
w Haskellu jest lepszy, bo... no bo tak)

> > > Język tego nie wymusza, ale naturalnie łatwiej wtedy o konwencję, że funkcje
robi się "czyste" a procedury zostawia się na te okazje, kiedy efekty uboczne są
celowe.
> >
> > A dlaczego to jest dobre? ;]
>
> Efekty uboczne? Bo świat ma efekty uboczne, już o tym pisaliśmy.

Nie o to pytam. Pytam dlaczego podział na czyste funkcje i dokonujące efektów
procedury jest dobry.

do góry

On 2019-01-15 08:03, Maciej Sobczak wrote:

> To również pokazuje, że funkcjonalność

Naucz sie wreszcie normalnej/prawidlowej nomenklatury,
bo troche wstyd...
Jak juz to _funkcyjnosc_, a nie funcjonalnosc.

AK

do góry

On 2019-01-15 08:12, Maciej Sobczak wrote:
>>> Znaczy - nie masz racji co do Pascala,
>>
>> Mam. Pisalem w (standardowym) Pascalu jeszce na Odrze i wiem co mowie.
>
> Widzę, że dzielnie walczysz dalej.
>
> https://books.google.pl/books?id=NvHjBwAAQBAJ&pg=PA1
66
>
> To jest z Pascal User Manual and Report: ISO Pascal Standard. Strona 166, od
pierwszego do drugiego wcięcia. Nie działa mi Ctrl-C. Fajny przykład w drugiej
połowie tego paragrafu, gdzie nie tylko kolejność, ale w ogóle wykonanie części
wyrażenia nie jest gwarantowane. Tego to nawet w C nie ma.
>

Proste:
No to w takim razie ISO Pascal tez jest spieprzony (poszli w slady
C/C++?) i nie ma nic wspolnego z Pascalami w ktorych pisalem.

AK

do góry

On 2019-01-15 08:16, Maciej Sobczak wrote:
>> No wiec zeby to wiedziec/byc pewnym w C/C++ zamiast naturalnego:
>>
>> d = fun(a) - fun(c) + fun(b);
>
> Nie zrozumiałeś problemu. Nie chodzi o kolejność wywołania funkcji w podwyrażeniach
(to nie jest gwarantowane i dla mnie OK),

To Ty nie zrozumiales.
O to chodzi jak najbardziej (i nie jest to OK ! bo wprowadza
niedeterminizm).
Pisze wyraznie z rapocie: kolejnosc _ewaluacji podwyrazen_ jest w C/C++
dowolna.

> tylko o kolejność wyliczenia sum i różnic. Funkcje mogą być wywołane dowolnie, ale
ja w tak napisanym >wyrażeniu chcę mieć gwarancję, że odejmowanie ich wyników będzie
zrobione wcześniej, niż dodawanie.

To tez i owszem.

Bo nawet przy czystych funkcjach od tego może zależeć poprawność programu.
> Wiesz, dlaczego?

Numerykowi (fakt ze bylemu:) chcesz mowic dlaczego? Heh

Dlatego numeryczne jezyki (Algol, Fortran) _gwarantowaly_ kolejnosc
obliczen od lewej do prawej, jak rowniez mozna ja bylo wymusic/zmienic
nawiasami (wczesniej byly wykonywane dzialania w nawiasach
nawet przy rownorzednych priorytetowo operatorach).
W C/C++ czy Free/ISO Pasalu (co jest dla mnie zaskoczeniem - dobrze
ze sobie dalej spokoj z innymi Pascalami poza Turbo) _sie nie da_
(bez kilku zmiennych tymczasowych).

AK

do góry

> Naucz sie wreszcie normalnej/prawidlowej nomenklatury,
> bo troche wstyd...
> Jak juz to _funkcyjnosc_, a nie funcjonalnosc.

Ale o analizie funkcjonalnej pewnie słyszałeś, co?

Functional Analysis == Analiza funkcjonalna
Functional Programming == Programowanie funkcjonalne

I tak żadne z tych słów nie jest polskie, ale przynajmniej jest konsekwentnie.

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

do góry

W dniu środa, 16 stycznia 2019 11:13:43 UTC+1 użytkownik Maciej Sobczak napisał:
> > Naucz sie wreszcie normalnej/prawidlowej nomenklatury,
> > bo troche wstyd...
> > Jak juz to _funkcyjnosc_, a nie funcjonalnosc.
>
> Ale o analizie funkcjonalnej pewnie słyszałeś, co?
>
> Functional Analysis == Analiza funkcjonalna

Słowo funkcjonał pochodzi z rachunku wariacyjnego, gdzie oznacza funkcję, której
argument jest funkcją (ale wartość jest liczbą). Prawdopodobnie, od słowa
"funkcjonał" pochodzi nazwa "analiza funkcjonalna"[...].
[https://pl.wikipedia.org/wiki/Analiza_funkcjonalna]

> Functional Programming == Programowanie funkcjonalne

Programowanie funkcyjne - filozofia i metodyka programowania będąca odmianą
programowania deklaratywnego, w której funkcje należą do wartości podstawowych, a
nacisk kładzie się na wartościowanie (często rekurencyjnych) funkcji, a nie na
wykonywanie poleceń.
[https://pl.wikipedia.org/wiki/Programowanie_funkcyj
ne]

> I tak żadne z tych słów nie jest polskie, ale przynajmniej jest konsekwentnie.

Raczej nie posiłkowałbym się w tych sprawach terminologią angielską, zważywszy na
wkład, jaki Polacy mieli w rozwój analizy funkcjonalnej.

Jak byłem mały, to kiedyś tata zabrał mnie do Warszawy, gdzie kupił mi hot-doga w
budzie o nazwie "Dania Fast Food".
Przez długi czas naprawdę myślałem, że to był duński hot-dog.

Żeby była jasność, jak dla mnie możesz pisać "programowanie funkcyjne" albo
"programowanie funkcjonalne". Mnie to bez różnicy, i szkoda mi czasu na takie kłótnie
(Ja wolę myśleć "funkcja -> funkcyjne", "funkcjonał -> funkcjonalne")

Bardziej interesuje mnie, dlaczego według Ciebie podział na czyste funkcje i
dokonujące efektów procedury jest dobry.

do góry