Widziałem kilka wątków, które dotykają programowania GUI w OCaml, ale nie uważam, że jasno prowadzą do jednoznacznego rozwiązania, gdy potrzebny jest interfejs GUI.OCaml: Skuteczna ścieżka do programowania GUI?
Moje pytanie brzmi bardziej szczegółowo: Jaka jest najbardziej efektywna (i łatwa do odbioru) metoda programowania GUI dla oprogramowania OCaml? Czy ktokolwiek miał styczność z prostymi i efektywnymi modułami GUI w samym OCaml lub znalazł skuteczny pakiet językowy lub darmowy program, w którym można to zrobić i który dobrze komunikuje się z OCaml?
Napisałem interpretera w OCaml, więc mój lexer, parser, podstawowe funkcje interpretera, itp. Są modułami OCaml. Obecnie mam rozwiązanie z linii poleceń ("main.ml"), które pozwala użytkownikowi na interakcję z interpreterem poprzez wpisanie wyrażeń w linii poleceń i odbiór wydrukowanego wyjścia terminalowego, które pokazuje sparsowane i zredukowane wyrażenie itd. Jednakże, rozwiązanie z wiersza poleceń służy tylko do testowania. Chcę, aby użytkownicy interweniowali za pośrednictwem GUI, może to być proste (ramki Java przychodzą do głowy od eonów wcześniej), ale muszą w jakiś sposób współpracować z modułami OCaml, które zakodowałem. Jest jedna biblioteka w OCaml, którą znalazłem do tej pory: http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual042.html. Czy ktoś wie, czy jest to skuteczne i użyteczne? (Myślę, że złapałem negatywne komentarze na temat tej biblioteki)
Jeśli zdecyduję się zaprogramować GUI w bardziej optymalnym języku, czy interakcja z oprogramowaniem będzie: napisać GUI w odpowiednim języku (być może C++, Python itp.) , następnie skompiluj napisany interpreter OCaml do pliku wykonywalnego, a następnie podłącz GUI do pliku wykonywalnego? Nie interesuje mnie luźno powiązane lub dziwne rozwiązanie, za pośrednictwem potoków (ciągle myślę o komunikacji międzyprocesowej dla tych, co dotyczy projektowania systemu operacyjnego) lub gniazd (staram się o nich myśleć w przypadku programowania sieciowego), Wyobrażam sobie, że musi być jakiś sposób na "domknięcie" mojego kodowanego przez OCaml interpretera w kodzie GUI innego języka, jeśli nie sam OCaml. Wszelkie myśli, wskazówki lub sugestie?
EDYCJA: Byłbym szczęśliwy, gdybym mógł uzyskać GUI dla systemu operacyjnego podobnego do Linuksa (np. Linux RedHat). Gdybym mógł sprawić, by GUI działało na Windowsie, byłoby wspaniale, ale przynajmniej dążyłem do Linuksa.
EDIT 2: Właśnie znalazłem to, czy ktoś ma myśli na temat "OCaml-Java"? http://ocamljava.x9c.fr/ Brzmi całkiem interesująco, ponieważ ma "... zdolność do uruchamiania źródeł Objective Caml, które zostały skompilowane przy użyciu ocamlc, po drugie, zdolność do kompilowania źródeł Objective Caml do plików wykonywalnych JAR." Obawiam się, że nigdy nie przyszło mi do głowy, że Java to najlepszy sposób na szybkie, ale użyteczne GUI ...
AKTUALNE ROZWIĄZANIE: Po zbadaniu różnych opcji w rozwiązaniu, umieść @Jeffrey Scofield poniżej , Zdecydowałem się teraz zagłębić w LablGtk (co pozwoliłoby mi pozostać w OCaml). Następną obiecującą opcją dla osób zajmujących się tym postem byłoby przyjrzenie się obcemu językowi z C, ponieważ C i OCaml mają już na początku związek. Wydaje się, że istnieją sposoby wywoływania kodu C w OCaml i OCaml w C (chociaż może to być naprawdę trudne, ponieważ w zasadzie kończy się zawijanie wywołań funkcji OCaml z nieco złożonymi funkcjami opakowania, które będą bardziej specyficzne dla typu funkcji, które wywołujesz z w ramach OCaml -> tzn. będziesz musiał zająć się "mapowaniem" każdej funkcji OCaml i jej argumentami w C). Spójrz na: http://www.mega-nerd.com/erikd/Blog/CodeHacking/Ocaml/calling_ocaml.html, aby uzyskać więcej informacji. OCaml-Java pierwotnie uważał się za świetny pomysł, biorąc pod uwagę, że czułem się komfortowo z programowaniem w języku Java, ale interakcja między tymi dwoma językami nie była tak bezpośrednia jak w przypadku C i OCaml, a także, że dokumentacja tego wydawała się być cienka (i używanie OCaml -Java nie była czymś, co po prostu podnosisz i dostajesz się do rzeczy z GUI Java ...). OCaml-JavaScript wyglądał interesująco, ale pamiętaj, że jeśli wybierzesz tę ścieżkę, najprawdopodobniej będziesz musiał zainwestować czas w dobrą konfigurację kodowania HTML 5. Alternatywnie, istnieje tu kilka wpisów w SO, które mówią o rurach i gniazdach, które są prawidłowymi metodami tworzenia systemu zaplecza GUI.Jest to jednak dobry pomysł, jeśli nie masz nic przeciwko temu, że twój system/produkt będzie "luźno powiązany". Będę aktualizować to rozwiązanie, gdy tylko wymyślę LablGtk i upewnię się, że zapewnia on akceptowalny interfejs GUI dla mojego kodu backgradu OCaml.
Pomoże to poznać platformę lub platformy docelowe. O ile warto, całkowicie rozsądne jest korzystanie z gniazd w ramach jednego hosta. Jeśli używasz systemu podobnego do systemu Unix, istnieją "gniazda domeny Unix". –
Właśnie zaktualizowałem swój post o informacje dotyczące platformy docelowej zgodnie z Twoim komentarzem! Co więcej, @JeffreyScofield, jeśli masz rację, że gniazda mogą nie być czymś, co można wykluczyć, byłbym bardzo zainteresowany, gdyby istniało jakieś rozwiązanie, w którym mógłbym spakować GUI i interpretator (napisany w OCaml) w jednym rodzaju program/plik wykonywalny, ale jeśli to nie jest możliwa ścieżka, to gniazda mogą być drogą do przejścia ... ale to jest luźno sprzężony system, jak sądzę, gdybym mógł zachować rzeczy ściślej powiązane, to byłoby idealne! – 9codeMan9