🚀 go-pugleaf

RobertSzefler wrote:
> Tomasz Zielonka wrote:
>
>> W Haskella nie wpakowano takich srodkow, a jest calkiem, calkiem.
>> Zgadzam sie, ze wsparcie mogloby byc lepsze, ale np. jakosc kompilatorow
>> chyba i tak przebija to, co teraz mamy np. dla C++. No dobra, C++ to
>> zupelnie inna kategoria. Bjarne (prawie) wygral konkurs "Zaprojektuj
>> jezyk programowania, ktorego nikomu nie uda sie zaimplementowac".
>
> Nie da się zaimplementować = w praktyce nie da się napisać dobrego 
> parsera w rozsądnym czasie (ze względu na głęboko poj***** gramatykę). 
> Jak to się przebrnie, to dalej konstrukcja kompilatora jest typowa dla 
> języków imperatywnych 

Nie do konca. Jest gorzej, bo gramatyka C++ (a nawet C) jest
niejednoznaczna i kompilator wlasciwie musi robic jednoczesnie analize
skladniowa i sprawdzanie typow. Wez chocby taki przyklad:

    ...

    void f(void)
    {
        ...
        x * y; // co to za konstrukcja?
    }

To C. W C++ jest jeszcze gorzej, chocby ze skladowymi klas, np.
czy to wartosc, typ czy szablon:
    T<41234>::member

Do "nie da sie" dodalbym jeszcze nieslychanie skomplikowane reguly
semantyczne jezyka (widocznosc nazw, konkretyzacja szablonow,
rozwiazywanie wolan przeciazonych funkcji, ...), rozdzielna kompilacja
dla szablonow, itp.

> - sprawdzanie typów (duużo prostsze bądź co bądź niż w Haskellu),

W Haskellu jest to przynajmniej dobrze sformalizowane.

> Co więcej, istnieje spora ilość prac teoretycznych świadcząca o tym,
> że implementacja kompilatorów jęz.  funkc. to w istocie rzeczy to samo
> (np. odpowiedniość między SSA i CPS lub postacią A-normalną).

Mowisz o jezyku funkcyjnym z ewaluacja "non-strict"?

Best regards
Tomasz

-- 
I am searching for programmers who are good at least in
(Haskell || ML) && (Linux || FreeBSD || math)
for work in Warsaw, Poland