Oberon space
General Category => Общий раздел => Тема начата: valexey от Февраль 19, 2012, 09:18:07 pm
-
Вот такой концептуальный вопрос возник: как лучше делать в Обероне взаимодействие с внешним миром? То есть с функционалом писанным на других языках.
Тут, как я понимаю, есть два пути:
- Вшиваем в язык какую-нибудь прагму, или иной языковый расширизм, для деклараций внешних сущностей. Плюсы такого подхода - при программировании не нужно выходить за пределы уютненького Оберона. Минусы - в случае разного внешнего мира эти языковые расширизмы будут совсем-совсем разные. Теряется портабельность. Ну, например сравним: если мы живем в posix/native среде, то внешний мир для нас это скорее всего Си и его соглашения о вызовах и терминах (указатели, память, структуры, регистры...). А вот если мы живем в браузере, в мире js, то у нас уже нет никаких регистров, у нас уже вся прелесть прототипного ООП, функций высших порядков и так далее. Общий механизм для обоих случаев как-то затруднительно придумать.
- Не вшиваем в язык ничего. У нас обычный "стандартный" Оберон. Вместо этого снабжаем программиста информацией и инструментарием для того, чтобы он мог соорудить оберонов модуль на чуждом языке. То есть в случае posix/native, берем сишечку и прилагающийся инструментарий/либу, и оформляем сишный код-переходник таким образом чтобы он с точки зрения Оберона был обычным обероновским модулем. С js аналогично - на js пишем код-переходник который с точки зрения Оберона будет обычным обероновским модулем. Минусы подхода очевидны - в случае чего, придется вылезти из уютненького мира Оберона, и окунуться в жуткий мир Сей или вообще жабаскрипта. Ну и для полноценной разработки придется таки на компе иметь инструментарий (компиляторы, либы и так далее) врага, то есть си. Ну, или там того же js. Плюсы такого подхода в том, что сам язык остается чистым, и вся грязь, энтропия, выносится вовне.
Как думаете, что лучше?
-
Как думаете, что лучше?
Второй вариант слишком идеальный, поэтому неживой :) Так что я бы выбрал языковой раширизм. Можно в рамках конкретного модуля. Типа "IMPORT WindowsAPI" и вперед описывать/вызывать виндовые функции.
-
Вот такой концептуальный вопрос возник: как лучше делать в Обероне взаимодействие с внешним миром? То есть с функционалом писанным на других языках.
...
Как думаете, что лучше?
Конечно второй вариант предпочтительнее. Если нужно скрещивать исходный язык с одним целевым языком/протоколом, то можно использовать первый подход. С появлением новых целевых языков, при первом подходе, исходный язык сильно разрастётся, в директивах компилятору будет трудно разобраться, исчезнет простота и наглядность.
Второй подход предпочтительнее и тем, что его сложность не зависит от количества целевых языков, а простота и наглядность программного кода не утрачивается. Сама библиотека-преобразователь может быть написана на третьем языке, отличном от исходного и целевого языка. Генерацией таких библиотек может заниматься отдельное программное обеспечение, которое нацелено на то, чтобы вызовы, протоколы, константы, типы из исходного языка преобразовывать в вызовы, протоколы, константы, типы целевого языка для данной исполнительской платформы (ОС).
-
Как думаете, что лучше?
Второй вариант слишком идеальный, поэтому неживой :) Так что я бы выбрал языковой раширизм. Можно в рамках конкретного модуля. Типа "IMPORT WindowsAPI" и вперед описывать/вызывать виндовые функции.
Ну почему не живой? Именно так сделано например в erlang'e.
-
Тут, как я понимаю, есть два пути:...Как думаете, что лучше?
Видимо, зависит от того что внутрь чего будет в конце-концов встроено (embedded):
1) Процесс написанный на Обероне будет загружать библиотеку написанную на чужом языке (embedded Js), или
2) Процесс написанный на чужом языке будет загружать библиотеку написанную на Обероне (embedded Oberon).
Вон у нас на работе есть программа написанная на C#, которая загружает библиотеку *.so написанную на С++. Но плюсовики жаждут реванша, хотят наоборот, чтобы программа написанная на С++ ембедила Mono и запускала в ней модуль написанный на C#. Я заниматься ембедингом моны отказываюсь, а у них самих руки (пока) не доходят, так и живём :)
Пока проблема курицы и яйца не решена интерфейс сделали универсально узким: подмножество-пересечение обоих языков. Типа такого: процедура в которую передаётся массив байтов с сериализованным сообщением и аналогичная процедура обратного вызова. С массивами байтов все языки работать умеют.
-
Кстати в Питоне реализован второй вариант. Модули Питона можно писать как на самом Питоне, так и на Си в том смысле что модуль написанный на Си (с использованием соответствующего API) будет виден из Питона так как будто он написан на Питоне.
-
Кстати в Питоне реализован второй вариант. Модули Питона можно писать как на самом Питоне, так и на Си в том смысле что модуль написанный на Си (с использованием соответствующего API) будет виден из Питона так как будто он написан на Питоне.
Такой вариант вообще характерен для интерпретируемых (не обязательно скриптовых) языков. Ну и для других языков которые живут в сильно чуждой для них среде.
-
Ну почему не живой? Именно так сделано например в erlang'e.
И где тот эрланг? :) Вобщем ты прав, для сильно чужеродных сред - второй подход лучше. Тот же жабаскрипт как пример...
-
С js аналогично - на js пишем код-переходник который с точки зрения Оберона будет обычным обероновским модулем.
Как-то я слабо представляю себе такую операцию.
-
С js аналогично - на js пишем код-переходник который с точки зрения Оберона будет обычным обероновским модулем.
Как-то я слабо представляю себе такую операцию.
Это для случая когда Оберон-программа интерпретируется браузером, js для которого более нативный.