Korzystanie z Haskell dla dużych systemów czasu rzeczywistego: jak (jeśli?)?

Minie dużo czasu, zanim pojawi się system Haskell, który zmieści się w małej pamięci i może zagwarantować czasy pauzy poniżej milisekundy. Społeczność Haskell implementors po prostu nie wydaje się być zainteresowany tego rodzaju cel.

Istnieje zdrowe zainteresowanie używaniem Haskella lub czegoś podobnego do Haskella do kompilacji do czegoś bardzo wydajnego; na przykład, Bluespec kompiluje się na sprzęcie.

Myślę, że nie spełni Twoich potrzeb, ale jeśli jesteś zainteresowany Programowanie funkcyjne i systemy wbudowane powinieneś poznać Erlang .

Andrzej,

Tak, debugowanie problemów poprzez wygenerowany kod z powrotem do oryginalnego źródła może być trudne. Jedną z rzeczy, które Atom Zapewnia, jest środek do badania wyrażeń wewnętrznych, a następnie pozostawia, jeśli do Użytkownika, jak obsługiwać te sondy. Do testowania pojazdów budujemy nadajnik (w atomie) i przesyłamy sondy na magistralę CAN. Możemy następnie przechwycić te dane, sformatować je, a następnie wyświetlić je za pomocą narzędzi takich jak GTKWave, zarówno w post-processingu, jak i w czasie rzeczywistym. Do symulacji oprogramowania, sondy są traktowane inaczej. Zamiast pobierać dane sondy z protokołu CAN, do kodu C wykonuje się haki, aby bezpośrednio podnieść wartości sondy. Wartości sondy są następnie wykorzystywane w ramach testów jednostkowych (rozproszonych z Atom) w celu określenia, czy test przejdzie lub nie i obliczyć zasięg symulacji.

Nie wydaje mi się, aby Haskell, ani inne języki zbierane ze śmieci były bardzo dobrze dostosowane do systemów w czasie rzeczywistym, ponieważ GC mają tendencję do amortyzacji swoich czasów w krótkich przerwach.

Pisanie w atomie nie jest dokładnie programowaniem w Haskell, ponieważ Haskell tutaj może być postrzegany jako czysto preprocesor dla rzeczywistego programu, który piszesz.

Myślę, że Haskell jest awesome preprocesorem, a używanie DSEL ' ów jak Atom jest prawdopodobnie świetnym sposobem na stworzenie sporych systemów w czasie rzeczywistym, ale ja Nie wiem, czy Atom pasuje do ustawy, czy nie. Jeśli nie, jestem prawie pewien, że jest to możliwe (i zachęcam każdego, kto to robi!), aby zaimplementować DSEL, który to robi.

Posiadanie bardzo silnego pre-procesora jak Haskell dla języka niskopoziomowego otwiera ogromne okno możliwości implementacji abstrakcji poprzez generowanie kodu, które są znacznie bardziej niezgrabne, gdy są implementowane jako generatory tekstu kodu C.

Wygłupiałem się z atomem. Jest całkiem fajny, ale myślę, że jest najlepszy dla małych systemów. Tak działa w ciężarówkach i autobusach i wdraża rzeczywiste, krytyczne aplikacje, ale to nie znaczy, że aplikacje te są koniecznie duże lub złożone. To naprawdę jest dla trudnych aplikacji w czasie rzeczywistym i dokłada wszelkich starań, aby każda operacja trwała dokładnie tyle samo czasu. Na przykład, zamiast instrukcji if / else, która warunkowo wykonuje jedną z dwóch gałęzi kodu, które mogą różni się czasem działania, posiada instrukcję "mux", która zawsze wykonuje obie gałęzie przed warunkowym wyborem jednej z dwóch obliczonych wartości(więc całkowity czas wykonania jest taki sam, niezależnie od wybranej wartości). Nie ma żadnego znaczącego systemu typów innych niż wbudowane typy (porównywalne z C), które są wymuszane przez wartości GADT przekazywane przez Monad atomu. Autor pracuje nad statycznym narzędziem weryfikacji, które analizuje wyjściowy kod C, co jest całkiem fajne (wykorzystuje SMT solver), ale myślę, że Atom skorzystałby z większej liczby funkcji i kontroli na poziomie źródłowym. Nawet w mojej aplikacji wielkości zabawki (kontroler latarki LED), zrobiłem szereg błędów dla początkujących, że ktoś bardziej doświadczony z pakietu może uniknąć, ale to spowodowało błędny kod wyjściowy, że wolałbym zostać złapany przez kompilator zamiast przez testowanie. Z drugiej strony nadal jest w wersji 0.1.coś takiego niewątpliwie nadchodzi.