🚀 go-pugleaf

Artur Siekielski wrote:
> Jest to projekt akademicki, robiony w Instytucie Podstaw Informatyki PAN w
> Sopocie. Kod źródłowy nie jest w tej chwili udostępniany, ale myślę, że nie
> byłoby z tym problemu.

Chetnie bym sobie obejrzal.

> Sam model matematyczny to hipersieci Petriego. Ma on tę zaletę nad podobnymi
> formalizmami, że można stosować model checking.

Slyszalem termin "model checking" wczesniej, ale dopiero teraz
sprawdzilem, co to jest, i nie jestem pewien, czy rozumiem. Moglbys
napisac, dlaczego to jest fajne, np. w Waszym zastosowaniu? ;-) Ostatnio
w mojej pracy coraz czesciej przydaja mi sie takie "akademickie"
techniki jak np. "partial evaluation", czy "abstract interpretation"
(jesli dobrze zidentyfikowalem ;-) - moze warto byloby sie i z ta
zapoznac.

> Pierwsza wersja naiwnego model checkera została stworzona w Haskellu,
> jednak w tym wypadku sprawa wydajności okazała się kluczowa, a ciężko
> robić optymalizacje w leniwym Haskellu czy choćby wnioskować, co się
> aktualnie oblicza. Sprawa jest dziwna, bo szacując matematycznie ilość
> potrzebnych obliczeń w pewnym przykładzie nie wychodzi ich dużo, a
> Haskell oblicza to długo.

Moze mieliscie space-leak? Najczestsze objawy to duze zuzycie pamieci i
czas GC dominujacy w czasie dzialania programu.

> Problemem jest zapewne wielokrotne wykonywanie tych samych obliczeń
> (dlaczego nie ma prostego sposobu na "function memoization"?!), ale
> mimo użycia profilera nie udało mi się znaleźć tych kluczowych
> miejsc...

Moze poproscie o pomoc na haskell-cafe@haskell.org?

> Ostatecznie ma być użyty lepszy algorytm modelcheckujący (co nie jest
> trywialne, bo logika modelu jest niestandardowa), a model checker ma być
> przepisany na coś imperatywnego (Java...).

Au! Moze da sie temu jakos zapobiec? ;-)

> Symulator jest skonstruowany następująco: model jest zaimplementowany w
> Haskellu, wyświetlanie modelu jest realizowane przez program uDrawGraph,
> służący do wyświetlania i edytowania grafów, a połączenie pomiędzy Haskellem a
> uDrawGraphem jest napisane w Javie. Niestety połączenie Haskella z Javą jest
> robione przez stdout/stdin, ponieważ nie udało mi się znaleźć działającego
> sposobu na wywoływanie Haskella z Javy (w drugą stronę o dziwo się da).

stdin/stdout nie jest takie zle - moze zwiekszyc modularnosc, ale
kosztem wydajnosci.

> Gdybym dzisiaj miał decydować o języku implementacji, byłbym za jakimś MLem,
> bo miałbym tę samą ekspresywność, a język jest bardziej praktyczny (i chyba
> nawet są jakieś MLe kompilowane do bajtkodu JVM...). Aha, pisząc w Haskellu
> dosięgła nas następująca zmora: okazało się, że żeby zrobić "coś", trzeba
> wprowadzić monadę, co wymagałoby przepisania praktycznie całego programu
> (oczywiście ze zmianą wszystkich typów funkcji włącznie)...

No coz, zdaza sie. Nigdy nie mialem az tak bolesnego przypadku - moze
dlatego, ze dosyc szybko zaczynam uzywac monad, tzn. kiedy widze, ze to
moze ulatwic, a nie dopiero wtedy, kiedy jest juz konieczne.

PS. Duze masz/macie doswiadczenie w uzywaniu Haskella? Przyznaje,
    ze mi osiagniecie stanu pozwalajacego wygodnie rozwiazywac
    typowe praktyczne problemy zajelo chyba ze dwa lata, ale
    wiem, ze niektorym przychodzi to szybciej.

Pozdrawiam
Tomasz

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