> > Bez przesady. Nawet nie podałeś definicji, tylko przykład, z którym ja się nie
zgodziłem. To mi się nie kwalifikuje jako "ustaliliśmy".
>
> Pozwolę sobie wkleić:

> Miałoby znaczyć tyle, że dla danego wejścia daje zawsze to samo wyjście.
>
> (koniec cytatu)

I bez wklejania, powtórzę: każdy program tak ma.

> > Ogólnie, oodwoływanie się do takich pojęć jak "istota czegoś" jest trochę...
nieinżynierskie.
>
> Owszem. Ale dlaczego miałoby to być problemem?

Bo jest nieprecyzyjne i niedookreślone. A stąd prosta droga do nieporozumień.

> Stwierdzenie, że kompilator jest w istocie programem czysto funkcyjnym
> oznacza tyle, że kompilacja jest rodzajem transformacji (przekształcenia).

Każde przetwarzanie czegokolwiek takie jest.

> Piszesz błędnie.
>
> Jeżeli mamy np. program
>
> int square(int x) {
> return x*x;
> }
>
> void main(int argc, char *argv[]) {
> assert(argc > 1);
> int n = atoi(argv[1]);
> printf("kwadrat liczby %d wynosi %d\n", n, square(n));
> }
>
> to square jest czystą funkcją.

I w tym przykładzie kontekst jest ciekawszy, bo obszar użycia tego pojęcia jest
dobrze określony. Pojęcie czystej funkcji (pure function) jest znane:

https://en.wikipedia.org/wiki/Pure_function

Co ciekawe, jest nawet użyteczne, nie tylko z powodów, o których pisałeś, ale również
np. przy analizie poprawności albo optymalizacji programów wielowątkowych.

Natomiast pojęcie *programu* czysto funkcyjnego jest słabe, bo właśnie granica
pojęcia programu jest na jego efektach ubocznych, więc nie ma jak tej czystości
zdefiniować. A podpieranie się hasłami typu "istota programu" prowadzi do kolejnych
niedopowiedzeń, bo "istotą" Twojego ostatniego przykładu może nie być liczenie, tylko
dialog z użytkownikiem albo formatowanie tesktu a programista użył square
przypadkiem, bo akurat nie umiał napisać pierwiastkowania.

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

do góry

W dniu piątek, 6 października 2017 14:01:22 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Bez przesady. Nawet nie podałeś definicji, tylko przykład, z którym ja się nie
zgodziłem. To mi się nie kwalifikuje jako "ustaliliśmy".
> >
> > Pozwolę sobie wkleić:
>
> > Miałoby znaczyć tyle, że dla danego wejścia daje zawsze to samo wyjście.
> >
> > (koniec cytatu)
>
> I bez wklejania, powtórzę: każdy program tak ma.

Widzę, że masz wielką ochotę kręcić się w kółko.
Otóż nie każdy. Jeżeli chcesz jeszcze inną garść przykładów,
to na przykład programy na maszyny niedeterministyczne
tak nie mają.
Tutaj masz przykłady:
https://en.wikipedia.org/wiki/Nondeterministic_finit
e_automaton
https://en.wikipedia.org/wiki/Non-deterministic_Turi
ng_machine


> > > Ogólnie, oodwoływanie się do takich pojęć jak "istota czegoś" jest trochę...
nieinżynierskie.
> >
> > Owszem. Ale dlaczego miałoby to być problemem?
>
> Bo jest nieprecyzyjne i niedookreślone. A stąd prosta droga do nieporozumień.

"Nieinżynierskie" nie znaczy ani "nieprecyzyjne" ani "nieokreślone".
Pojęcie istoty też ma swój wpis na wikipedii:

https://en.wikipedia.org/wiki/Essence

> > Stwierdzenie, że kompilator jest w istocie programem czysto funkcyjnym
> > oznacza tyle, że kompilacja jest rodzajem transformacji (przekształcenia).
>
> Każde przetwarzanie czegokolwiek takie jest.

Nie każde. Istnieją przetwarzania niedeterministyczne, stochastyczne
itd.

> > Piszesz błędnie.
> >
> > Jeżeli mamy np. program
> >
> > int square(int x) {
> > return x*x;
> > }
> >
> > void main(int argc, char *argv[]) {
> > assert(argc > 1);
> > int n = atoi(argv[1]);
> > printf("kwadrat liczby %d wynosi %d\n", n, square(n));
> > }
> >
> > to square jest czystą funkcją.
>
> I w tym przykładzie kontekst jest ciekawszy, bo obszar użycia tego pojęcia jest
dobrze określony. Pojęcie czystej funkcji (pure function) jest znane:
>
> https://en.wikipedia.org/wiki/Pure_function
>
> Co ciekawe, jest nawet użyteczne, nie tylko z powodów, o których pisałeś, ale
również np. przy analizie poprawności albo optymalizacji programów wielowątkowych.
>
> Natomiast pojęcie *programu* czysto funkcyjnego jest słabe, bo właśnie granica
pojęcia programu jest na jego efektach ubocznych, więc nie ma jak tej czystości
zdefiniować. A podpieranie się hasłami typu "istota programu" prowadzi do kolejnych
niedopowiedzeń, bo "istotą" Twojego ostatniego przykładu może nie być liczenie, tylko
dialog z użytkownikiem albo formatowanie tesktu a programista użył square
przypadkiem, bo akurat nie umiał napisać pierwiastkowania.

Akurat w tym przypadku łatwo jest stwierdzić, że istotą tego
programu jest podanie kontrprzykładu dla Twojego wcześniejszego twierdzenia.
Natomiast nie ma nic kontrowersyjnego w tym, że np. istotą programu
do dowodzenia twierdzeń jest dowodzenie twierdzeń, istotą kompilacji
jest przekształcanie programów w języku zrozumiałym dla człowieka
w równoważne programy w języku wykonywalnym przez maszynę, albo że
istotą gry komputerowej jest dostarczanie interaktywnej rozrywki.
Wynika to z samych definicji pojęć i nie potrzeba niczego więcej.

do góry

> Widzę, że masz wielką ochotę kręcić się w kółko.

Wręcz przeciwnie. Staram się zmusić Ciebie do wyjścia z tego kołka.

> Otóż nie każdy. Jeżeli chcesz jeszcze inną garść przykładów,
> to na przykład programy na maszyny niedeterministyczne
> tak nie mają.
> Tutaj masz przykłady:
> https://en.wikipedia.org/wiki/Nondeterministic_finit
e_automaton
> https://en.wikipedia.org/wiki/Non-deterministic_Turi
ng_machine

Słabe. Oba pojęcia to twory czysto teoretyczne, których nie ma nawet jak
zaimplementować. W szczególności w pierwszym linku jest sekcja Implementation, która
podaje kilka metod *deterministycznych*, polegających w szczególności na tym: "Create
multiple copies". Czyli zamiast niedeterministycznegp przejścia do jednego z N
stanów, robimy te wszystkie N stanów i udajemy, że możemy być w dowolnym z nich.
Przykład z okolic obliczeń kwantowych byłby bardziej interesujący, ale jednocześnie
bardziej odległy od Twojego początkowego wątku z kompilacją jako obliczeniem czysto
funkcyjnym. Więc skupmy się: obecne komputery są deterministyczne a wszystkie
działające na nich programy spełniają Twoje kryteria bycia "czysto funkcyjnymi" (jak
również nie bycia nimi - co już omówiliśmy). Albo zły kontekst albo zła definicja.

> "Nieinżynierskie" nie znaczy ani "nieprecyzyjne" ani "nieokreślone".
> Pojęcie istoty też ma swój wpis na wikipedii:
>
> https://en.wikipedia.org/wiki/Essence

Słowo "program" nie występuje na tej stronie. Podawanie linków nie na temat jest
jeszcze bardziej nieinżynierskie. :-)

> Istnieją przetwarzania niedeterministyczne, stochastyczne
> itd.

No pewnie. Ale nie na naszych komputerach, co oznacza, że usiłując udowodnić swoją
rację coraz bardziej oddalasz się od początkowego wątku.

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

do góry

W dniu sobota, 7 października 2017 23:22:55 UTC+2 użytkownik Maciej Sobczak napisał:

> > Otóż nie każdy. Jeżeli chcesz jeszcze inną garść przykładów,
> > to na przykład programy na maszyny niedeterministyczne
> > tak nie mają.
> > Tutaj masz przykłady:
> > https://en.wikipedia.org/wiki/Nondeterministic_finit
e_automaton
> > https://en.wikipedia.org/wiki/Non-deterministic_Turi
ng_machine
>
> Słabe. Oba pojęcia to twory czysto teoretyczne, których nie ma nawet jak
zaimplementować.

Masz jakąś szerszą wiedzę na ten temat?
Podobno owo rozstrzygnięcie jest największym otwartym problemem
w informatyce, więc gdybyś wiedział coś więcej, koniecznie daj znać ;]

Z punktu widzenia dyskusji istotna jest kwestia, czy pojęcie
jest dobrze zdefiniowane.

W przytaczanym przeze mnie przykładzie frameworku do optymalizacji
genetycznej nie ma znaczenia, czy operator "random" jest zaimplementowany
jako procedura pseudolosowa, czy jako odczyt z urządzenia generującego
prawdziwie losowe liczby, czy też w taki sposób, że osoba, która interpretuje
program, rzuca kością przy podstawieniu. Albo czy może wie skądinąd,
jakie liczby najszybciej doprowadzą do znalezienia optymalnego rozwiązania.

> > Istnieją przetwarzania niedeterministyczne, stochastyczne
> > itd.
>
> No pewnie. Ale nie na naszych komputerach, co oznacza, że usiłując udowodnić swoją
rację coraz bardziej oddalasz się od początkowego wątku.

Czy pisząc "początkowy wątek" masz na myśli Twoją niezgodę
na moje stwierdzenie, że "kompilator jest w istocie programem
czysto funkcyjnym"?
Jeśli tak, to nie oddalam się ani o jotę, bo w owym stwierdzeniu
nie ma ABSOLUTNIE NIC o "naszych komputerach".
Stwierdzenie owo jest równoważne powiedzeniu, że kompilator
jest zasadniczo rodzajem deterministycznego przekształcenia,
i nie wydaje mi się przesadnie kontrowersyjne.
Tobie się ono nie spodobało -- jak zrozumiałem -- z tego wględu,
że według Ciebie każdy program jest rodzajem deterministycznego
przekształcenia, i że stwierdzenie, że "x jest w istocie
programem czysto funkcyjnym" nie dodaje nic do stwierdzenia
"x jest programem", na co ja wypunktowałem, że można też mówić
z jednej strony o programach niedeterministycznych (które nie
są czysto funkcyjne ze względu na swój niedeterminizm), a z drugiej
o systemach interaktywnych, których istota nie wyczerpuje się
w deterministycznym przekształceniu wejścia w wyjście (bo -- jak
pozwolę sobie dopowiedzieć -- ISTOTNĄ rolę przy naszej konceptualizacji
takich systemów odgrywa pojęcie "bieżącego stanu").

do góry

> > Słabe. Oba pojęcia to twory czysto teoretyczne, których nie ma nawet jak
zaimplementować.
>
> Masz jakąś szerszą wiedzę na ten temat?

Podałeś linka a tam jest to opisane. Następnym razem podaj takiego linka, z którym
będziesz się zgadzał.

> Z punktu widzenia dyskusji istotna jest kwestia, czy pojęcie
> jest dobrze zdefiniowane.

Bingo. Właśnie tego się od początku czepiam. :-)

> Czy pisząc "początkowy wątek" masz na myśli Twoją niezgodę
> na moje stwierdzenie, że "kompilator jest w istocie programem
> czysto funkcyjnym"?

Tak.

> Jeśli tak, to nie oddalam się ani o jotę, bo w owym stwierdzeniu
> nie ma ABSOLUTNIE NIC o "naszych komputerach".

I teraz jesteśmy bliżej, bo mamy dokładniej zdefiniowany kontekst.

> Stwierdzenie owo jest równoważne powiedzeniu, że kompilator
> jest zasadniczo rodzajem deterministycznego przekształcenia,
> i nie wydaje mi się przesadnie kontrowersyjne.

Ale dlaczego ma nie być kontrowersyjne? Przecież może być wiele sposobów na
kompilację (sam fakt, że jest wiele kompilatorów popularnych języków już na to
wskazuje, nie mówiąc o ich różnych opcjach), więc nie ma powodu twierdzić, że
kompilacja musi być deterministyczna.
Problem jest tutaj w kryterium poprawności. O ile funkcja square ma dosyć dobrze
określone takie kryterium i w zasadzie to kryterium powoduje, że funkcja square
będzie deterministyczna (bo inny wynik dla tego samego argumentu będzie uznany za
niepoprawny), to poprawność kompilatora nie jest tak dobrze określona. Stąd też
mnogość kompilatorów. Stąd też brak wymagania na to, żeby kompilator był
deterministyczny. A skoro nie musi być deterministyczny, to nie ma powodu przypisywać
mu cechy bycia "czysto funkcyjnym".

Ot, takie zabawy z definicjami. :-)

> Tobie się ono nie spodobało -- jak zrozumiałem -- z tego wględu,
> że według Ciebie każdy program jest rodzajem deterministycznego
> przekształcenia

Tak. Na domniemanych współczesnych komputerach. Możemy od nich odejść, ale jeśli mamy
przy nich pozostać, to trzymam się determinizmu.

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

do góry

W dniu niedziela, 8 października 2017 23:30:19 UTC+2 użytkownik Maciej Sobczak
napisał:
> > > Słabe. Oba pojęcia to twory czysto teoretyczne, których nie ma nawet jak
zaimplementować.
> >
> > Masz jakąś szerszą wiedzę na ten temat?
>
> Podałeś linka a tam jest to opisane. Następnym razem podaj takiego linka, z którym
będziesz się zgadzał.

W artykule jest napisane:

"How does the NTM "know" which of these actions it should take? There are two ways of
looking at it. One is to say that the machine is the "luckiest possible guesser"; it
always picks a transition that eventually leads to an accepting state, if there is
such a transition. The other is to imagine that the machine "branches" into many
copies, each of which follows one of the possible transitions."

O ile wiem, nikt do tej pory nie udowodnił, że nie można
sensownie zaimplementować wariantu "luckiest possible guesser"

> > Z punktu widzenia dyskusji istotna jest kwestia, czy pojęcie
> > jest dobrze zdefiniowane.
>
> Bingo. Właśnie tego się od początku czepiam. :-)

No nie. Podałem przykład programu, który w istotny
sposób bazuje na losowości -- i jego działanie jako
takie nie jest w istocie deterministyczne, natomiast
Ty stwierdziłeś, że jest deterministyczne, bo owa losowość
w faktycznej implementacji będzie albo pseudo-losowością,
i wówczas będzie deterministyczna, albo będzie dodatkowym
wejściem do programu, przez co program jako taki również
będzie deterministyczny.
Czyli Twoja argumentacja NIE ODNOSIŁA się do istoty
pojęcia, tylko do (chyba niezbyt dobrze zdefiniowanej?)
koncepcji "implementowalności pojęcia"

> > Czy pisząc "początkowy wątek" masz na myśli Twoją niezgodę
> > na moje stwierdzenie, że "kompilator jest w istocie programem
> > czysto funkcyjnym"?
>
> Tak.
>
> > Jeśli tak, to nie oddalam się ani o jotę, bo w owym stwierdzeniu
> > nie ma ABSOLUTNIE NIC o "naszych komputerach".
>
> I teraz jesteśmy bliżej, bo mamy dokładniej zdefiniowany kontekst.

Wcześniej w tym stwierdzeniu również nie było nic o "naszych komputerach" ;p

> > Stwierdzenie owo jest równoważne powiedzeniu, że kompilator
> > jest zasadniczo rodzajem deterministycznego przekształcenia,
> > i nie wydaje mi się przesadnie kontrowersyjne.
>
> Ale dlaczego ma nie być kontrowersyjne? Przecież może być wiele sposobów na
kompilację (sam fakt, że jest wiele kompilatorów popularnych języków już na to
wskazuje, nie mówiąc o ich różnych opcjach), więc nie ma powodu twierdzić, że
kompilacja musi być deterministyczna.

My, jako ludzie, chcemy, żeby kompilacja była deterministyczna,
bo chcemy wiedzieć, czego możemy się spodziewać po kompilatorach.

> Problem jest tutaj w kryterium poprawności. O ile funkcja square ma dosyć dobrze
określone takie kryterium i w zasadzie to kryterium powoduje, że funkcja square
będzie deterministyczna (bo inny wynik dla tego samego argumentu będzie uznany za
niepoprawny), to poprawność kompilatora nie jest tak dobrze określona. Stąd też
mnogość kompilatorów. Stąd też brak wymagania na to, żeby kompilator był
deterministyczny. A skoro nie musi być deterministyczny, to nie ma powodu przypisywać
mu cechy bycia "czysto funkcyjnym".

Wydaje mi się, że jednak poprawność kompilatora jest dość dobrze
określona. Zaś o ile być może z perspektywy tego czy innego użytkownika
wymaganie, żeby kompilator był deterministyczny, może nie wydawać się
istotne, to z perspektywy osób, które tworzą kompilatory, takie wymaganie
jest jak najbardziej na miejscu. (Pominę tu kwestię ekwiwokacji, związanej
z tym, że raz słowo "kompilator" jest użyte w istotnym sensie, tzn.
odnosi się do programu realizującego przekształcenie, a innym razem
w sensie metonimicznym -- do pakietu oprogramowania, który daje użytkownikowi
różne "opcje")

> > Tobie się ono nie spodobało -- jak zrozumiałem -- z tego wględu,
> > że według Ciebie każdy program jest rodzajem deterministycznego
> > przekształcenia
>
> Tak. Na domniemanych współczesnych komputerach. Możemy od nich odejść, ale jeśli
mamy przy nich pozostać, to trzymam się determinizmu.

Tzn. na domniemanych przez Ciebie współczesnych komputerach.
Ja ze swojej strony w ogóle nie wypowiadałem się o komputerach,
tylko o programach.

do góry

> W artykule jest napisane:
[...]

Nadal mamy deterministyczne strategie. Zwłaszcza ta z tworzeniem wielu kopii i
udawaniem, że jesteśmy w jednej z nich. Strategia ze zgadywaniem nie opisuje, na czym
ma zgadywanie polegać. Na domniemanym współczesnym komputerze to zgadywanie będzie
deterministyczne. Czyli wracamy do początku - a wynika to z tego, że kredą na tablicy
można sobie różne rzeczy napisać, ale krzem nie wszystko przyjmie tak samo łatwo.

> No nie. Podałem przykład programu, który w istotny
> sposób bazuje na losowości -- i jego działanie jako
> takie nie jest w istocie deterministyczne

Bo sobie włączyłeś tą losowość w ramy działania programu. Dla mnie to jest zewnętrzne
I/O.

> Czyli Twoja argumentacja NIE ODNOSIŁA się do istoty
> pojęcia,

Co to jest "istota pojęcia"? Czy "istota programu" już nie wystarcza?

> tylko do (chyba niezbyt dobrze zdefiniowanej?)
> koncepcji "implementowalności pojęcia"

Domniemując implementowalność na współczesnym komputerze, tak, pewne pojęcia mogą
mieć lub nie mieć sensu.

> My, jako ludzie, chcemy, żeby kompilacja była deterministyczna,
> bo chcemy wiedzieć, czego możemy się spodziewać po kompilatorach.

Chcemy, żeby efekty uboczne były takie, jak mówi definicja języka. Reszta nas zwykle
nie interesuje i często nawet celowo jej nie dookreślamy. Np. mało kogo interesuje
stan swapa na dysku po wykonaniu programu - ta niedookreśloność pozwala kompilatorom
(czy ogólniej: systemowi uruchomieniowemu) na własną rękę podejmować różne decyzje.
Kompilator nie musi być deterministyczny, żeby zapewnić użytkownikowi zgodność na
poziomie sekwencji udokumentowanych efektów ubocznych.

> Wydaje mi się, że jednak poprawność kompilatora jest dość dobrze
> określona.

Zwykle jest celowo niedookreślona.

> to z perspektywy osób, które tworzą kompilatory, takie wymaganie
> jest jak najbardziej na miejscu.

Właśnie dla tych osób jest ważne, żeby użytkownicy pozostawili im swobodę w różnych
obszarach. Dzięki temu te osoby mogą między sobą konkurować.

> Ja ze swojej strony w ogóle nie wypowiadałem się o komputerach,
> tylko o programach.

Interesujące. Ale po co takiemu bezkomputerowemu programowi kompilator? Czy
rozważania o deterministycznych kompilatorach dla programów bez komputerów nie są
trochę... przeteoretyzowaniem problemu?

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

do góry

nie czytam tego watku ale moge powiedziec pewna uwage ktora mnie naszla (a ktora moze
byc troche apropos tematu jezykow funkcyjnych):

spotkalem dzis na ulicy pewnego znajomego i mowie mu ze cos niewyraznie sie czuje bo
naszla mnie jakas faza wspolczucia dla biednych, bezdomych (naszlo mnie tio poniekad
po obejrzemniu wywiadu z ikonowiczem, fajnym gosciem ) - ten mowi "zwykle ludzkie
odczucia", ja mo mowie dla mnie ne takie zwykle bo ja na codzien bujam w
programistycznych oblokach, ten "no tak, w cyfrowej chmurze" ja na to "dokladnie"

koles urzyl dobrego pojecia bo cyfrowa chmura dosyc dobrze oddaje to co ja lubie w
programowaniu - oldschoolowe programowanie jakie ja bym lubil wydaje sie powinno
wlasnie opierac sie o ta cyfrowosc - tymczasem gdy wspolczesne kojarzace mi sie
bardziewiascie raczej trendy powoduja ze programisci nie siedzą w tych chmurach
cyfrowych tylko raczej leksykalnych - juz nawet c jest w sporym procencie leksykalny
(mataforycznie powiedzialbym ze o ile javaskrypt moglbym nazwac leksykalnym w 60% to
c pewnie tak w 20-30, takie jezyki jak lisp wyobrazaja mi sie ;c (zapewne blednie)
jako cos dązacego do 95% lekykalnosci - a dla mnei takie leksykalne programowanie to
nie jest fun
(oczywiscie moze sie myle bo patrzac na rzeczy z dystansu mozna sie myli (jest prawie
100^ gwarancja mylnosci tak naprawde)) ale tak to widze i dlatego nie ciagnie mnie do
lispa bo nie ciagnie mnie do takich leksykalnych klimatow (raczej uwazam je za zmore,
regexpy przykladem)

do góry

W dniu poniedziałek, 9 października 2017 14:25:28 UTC+2 użytkownik Maciej Sobczak
napisał:
> > W artykule jest napisane:
> [...]
>
> Nadal mamy deterministyczne strategie. Zwłaszcza ta z tworzeniem wielu kopii i
udawaniem, że jesteśmy w jednej z nich. Strategia ze zgadywaniem nie opisuje, na czym
ma zgadywanie polegać. Na domniemanym współczesnym komputerze to zgadywanie będzie
deterministyczne. Czyli wracamy do początku - a wynika to z tego, że kredą na tablicy
można sobie różne rzeczy napisać, ale krzem nie wszystko przyjmie tak samo łatwo.

Tak. Przy czym nie ma wymagania, żeby dyskutować tylko o rzeczach,
które można implementować na "domniemanym współczesnym komputerze"

> > No nie. Podałem przykład programu, który w istotny
> > sposób bazuje na losowości -- i jego działanie jako
> > takie nie jest w istocie deterministyczne
>
> Bo sobie włączyłeś tą losowość w ramy działania programu. Dla mnie to jest
zewnętrzne I/O.

Zewnętrzne I/O to jest coś zasadniczo innego od losowości.

> > Czyli Twoja argumentacja NIE ODNOSIŁA się do istoty
> > pojęcia,
>
> Co to jest "istota pojęcia"? Czy "istota programu" już nie wystarcza?

Możesz sobie poczytać np. tutaj
http://ebuw.uw.edu.pl/dlibra/docmetadata?id=122191

> > tylko do (chyba niezbyt dobrze zdefiniowanej?)
> > koncepcji "implementowalności pojęcia"
>
> Domniemując implementowalność na współczesnym komputerze, tak, pewne pojęcia mogą
mieć lub nie mieć sensu.

To, czy pojęcie ma sens, jest zagadnieniem różnym od tego,
czy da się je zaimplementować na współczesnym komputerze.

> > My, jako ludzie, chcemy, żeby kompilacja była deterministyczna,
> > bo chcemy wiedzieć, czego możemy się spodziewać po kompilatorach.
>
> Chcemy, żeby efekty uboczne były takie, jak mówi definicja języka. Reszta nas
zwykle nie interesuje i często nawet celowo jej nie dookreślamy. Np. mało kogo
interesuje stan swapa na dysku po wykonaniu programu - ta niedookreśloność pozwala
kompilatorom (czy ogólniej: systemowi uruchomieniowemu) na własną rękę podejmować
różne decyzje.

Tak. Bo stan swapa na dysku przed wykonaniem programu nie należy
w żadnej mierze do istoty kompilacji.

> > Wydaje mi się, że jednak poprawność kompilatora jest dość dobrze
> > określona.
>
> Zwykle jest celowo niedookreślona.

Poprawność kompilatora jest zazwyczaj określona przez semantykę języka
programowania (najczęściej semantykę operacyjną). Można oczywiście
stosować różne kryteria, np. obserwowalną równoważność zachowania
programu wyprodukowanego przez kompilator z tym samym programem
wykonanym przez interpreter języka. Kwestia dowodzenia poprawności
kompilatora jest interesująca i rozległa, ale samo pojęcie poprawności
kompilatora jest zupełnie jasne. Jasne jest np., że jeżeli rozważymy
wcześniej przytaczany przeze mnie program do wypisywania kwadratów liczb,
a ten program będzie po skompilowaniu wypisywał obraźliwe komunikaty
i podnosił liczby do sześcianu, to kompilator skompilował go niepoprawnie
(w świetle specyfikacji języka C).

> > to z perspektywy osób, które tworzą kompilatory, takie wymaganie
> > jest jak najbardziej na miejscu.
>
> Właśnie dla tych osób jest ważne, żeby użytkownicy pozostawili im swobodę w różnych
obszarach. Dzięki temu te osoby mogą między sobą konkurować.

Tzn. mówisz o tym, że dany fragment programu źródłowego można przekształcić
do różnych, ale równoważnych sobie (w sensie zachowania) programów. Owszem,
to jest prawda. Ale każdy kompilator jest deterministyczny (w takim sensie,
że jak kilka razy skompilujesz ten sam program źródłowy, to dostaniesz
ten sam program wynikowy)

> > Ja ze swojej strony w ogóle nie wypowiadałem się o komputerach,
> > tylko o programach.
>
> Interesujące. Ale po co takiemu bezkomputerowemu programowi kompilator? Czy
rozważania o deterministycznych kompilatorach dla programów bez komputerów nie są
trochę... przeteoretyzowaniem problemu?

Jak wspominałem, w swojej pracy proponuję model maszyny wirtualnej, który
co prawda jest działającym programem w języku Scheme, ale który można studiować
bez uruchamiania komputera -- tak naprawdę, jego wykonywalność
i implementowalność służą przede wszystkim temu, żeby zapewnić, że
w pracy nie ma błędów, i że używane w niej pojęcia są sensowne. Podobnie
kompilator nie ma znamion praktycznych, tylko ma wyjaśniać pewne ogólne
zasady, w oparciu o które funkcjonują kompilatory. Innymi słowy,
programy, które napisałem w swojej pracy, mają raczej charakter poznawczo
-dydaktyczny, niż praktyczny.

do góry