Вот смотрите: SML был вполне бодрячком. Причем язык довольно маленький, простой и энергичный, его бы и в микронтроллеры можно было бы. Но врезал дуба, а вместо него загадочный OCaml, который сходу и не скажешь, чем лучше. Неисповедимы пути в IT.
расскажу вкратце, чем ocaml лучше sml: 1. активно поддерживается и развивается 2. умеет в подтипизацию на индуктивных типах данных и на записях (они почему-то называются объектами) 3. модули являются first-class values 4. gadts 5. rank-2 полиморфизм на уровне полей записей и методов объектов 6. умеет компилировать код, который экстрактит coq 7. куча разного, касающегося модулей и функторов над модулями (все они важны как средство абстракции и декомпозиции) 8. private data types (как abstract, но не скрывают представление) 9. манипуляции с ast посредством ppx (extension points) Остальное, несущественное -- получше инфраструктура, больше библиотек, норм сообщество.
там не interpreter, но вопрос понятен. Ответ: да, не только планы, но и реализация. Тем не менее, ещё пилят её. Но занимаются этим серьёзные люди, скорее всего доделают успешно.
Тем не менее, это не мешает в большинстве случаев: для параллельного ввода-вывода есть lwt, для спасения от shared global mutable state есть message passing, ну и fork работает. Не такая уж и проблема, вообще.
Про сложение -- ну бля... Семантика ведь разная, зачем путать мозг, рассуждающий о программе, одинаковыми обозначениями разных по смыслу операций?
А так -- есть pa_do, старый и рабочий.
В относительно новом окамле можно передавать модуль с операциями (типа х-евых тайпклассов):
# let add (type n) (module N : NUM with type t = n) a b = let open N in a + b;; val add : (module NUM with type t = 'a) -> 'a -> 'a -> 'a = Ну и далее "add m_int 1 2", где "m_int = (module Int : NUM with type t = int
( ... )
Comments 21
1. активно поддерживается и развивается
2. умеет в подтипизацию на индуктивных типах данных и на записях (они почему-то называются объектами)
3. модули являются first-class values
4. gadts
5. rank-2 полиморфизм на уровне полей записей и методов объектов
6. умеет компилировать код, который экстрактит coq
7. куча разного, касающегося модулей и функторов над модулями (все они важны как средство абстракции и декомпозиции)
8. private data types (как abstract, но не скрывают представление)
9. манипуляции с ast посредством ppx (extension points)
Остальное, несущественное -- получше инфраструктура, больше библиотек, норм сообщество.
Reply
есть ли ближайшие планы в сообществе ocaml убрать global interpreter lock?
и, я где-то слышал, есть способ убрать разные операторы сложения для разных типов чисел, и использовать один (если да, как это можно сделать?)
Reply
там не interpreter, но вопрос понятен. Ответ: да, не только планы, но и реализация. Тем не менее, ещё пилят её. Но занимаются этим серьёзные люди, скорее всего доделают успешно.
Тем не менее, это не мешает в большинстве случаев: для параллельного ввода-вывода есть lwt, для спасения от shared global mutable state есть message passing, ну и fork работает. Не такая уж и проблема, вообще.
Про сложение -- ну бля... Семантика ведь разная, зачем путать мозг, рассуждающий о программе, одинаковыми обозначениями разных по смыслу операций?
А так -- есть pa_do, старый и рабочий.
В относительно новом окамле можно передавать модуль с операциями (типа х-евых тайпклассов):
# let add (type n) (module N : NUM with type t = n) a b =
let open N
in a + b;;
val add : (module NUM with type t = 'a) -> 'a -> 'a -> 'a =
Ну и далее "add m_int 1 2", где "m_int = (module Int : NUM with type t = int ( ... )
Reply
Reply
Reply
развиваться.
Reply
Leave a comment