синтаксис просто ужасен и архаичен, особенно
VAR, BEGIN, END, присвоение :=
синтаксис просто ужасен и архаичен, особенно
VAR, BEGIN, END, присвоение :=
Что это за концепция?Цитата:
Сообщение от farewell
int a = 10; // фрейм 0
if (true) {
int b = 10; // фрейм 1
}
// здесь переменные фрейма 1 уже не видны.
Надеюсь, понятно объяснил. Не совсем по науке, но суть такая.
Как сейчас эту проблему обходите ?Цитата:
Сообщение от Oleg N. Cher
Ofront для linux поставил, работает из коммандной строки.
Тестовый исходник оберона-2 транслировал в Си, код довольно чист, видал я и по хуже трансляцию. ООП ещё не пробовал.
Здравствуй, Дима! Необычайно рад тебя здесь увидать.Цитата:
Сообщение от alone
Мой язык Coloss был допилен до известного состояния, что сделано, то можно увидеть здесь: http://colossoft.anarxi.st/?go=coloss. На нём (полностью без асма) была сделана игра Sea Fight, скриншоты можно увидеть здесь: http://colossoft.anarxi.st/?go=seafight. Я интересуюсь языками давно, знаю их даже не два десятка, а гораздо-гораздо больше, поэтому слушать про сравнение Оберона с Хаскеллем или про архаичность VAR туточки меня умиляет. Но, тем не менее, Оберон-технологии – это то, к чему в итоге я пришёл. О проблемах распределения памяти знаю, и согласен. Условная компиляция видится мне вцелом нежелательной. Но и эта задача решаема в разных Оберонах разными средствами. Ссылка по теме: http://forum.oberoncore.ru/viewtopic.php?f=29&t=2062 (возможно, понадобится регистрация).
Надо думать, Оберон-исходников в инете если не тонны, то хотя бы килограммы. Вобщем, есть что найти. А поучениями по Си и асму я вообще боюсь обидеть бывалого спектрумиста.Цитата:
Сообщение от jerri
Тут не помешала бы помощь, не насколько хорош мой английский.Цитата:
Сообщение от Raydac
А может буржуи ещё учатся, а наши уже всё знают? :mad:
Точно-точно. Сами не понимают своего счастья. А счастье-то совсем рядом, вот оно, в паре кликов мышкой.Цитата:
Сообщение от Raydac
На картинках красиво, а скачать где?Цитата:
Сообщение от Oleg N. Cher
Здесь видится несколько решений. В порядке повышения сложности где-то так.Цитата:
Сообщение от Valen
1. Не использовать присваивания вида:
Обойдясь таким поэлементным присваиванием:Код:TYPE
Card = RECORD suit*, rank*: INTEGER END;
VAR (* Do not use Oberon, it’s archaic! *)
a, b: Card;
BEGIN
a := b;
2. Использовать автоматическую обработку промежуточного Си-файла, заменив в нём подходящим инструментом указанные присваивания “a := b” на “a.suit := b.suit; a.rank := b.rank”Код:a.suit := b.suit; a.rank := b.rank;
Это решение не очень красивое, но его плюс в том, что Оберон-исходник остаётся красивым.
3. Ждать пока в SDCC добавят нужную нам рюху. Я посмотрел http://sourceforge.net/tracker/index...99&atid=350599 – ещё не добавили.
4. Наиболее правильным видится доработать Ofront, чтобы сам генерировал поэлементное присваивание записей (или что-то вроде) [опционально включаемое]. Это вполне возможно, правда, я не понял, разрешает ли лицензия его доработку. Надо уточнить у Джозефа Темпла.Код:memcpy(a, b, sizeof(Card))
Чудно. Наконец-то кто-то чего-то пробует сам, а не только кричит как ему Оберон не ндравица. А ООП в Обероне красивое.Цитата:
Сообщение от Valen
Примерно затем же, что и лопата в современном мире экскаваторов и бульдозеров.Цитата:
Сообщение от newart
Угу, интересно узнать который был первый, не РК-86 ли? Очень его известность, использование и уважение всё шире во всё более узких кругах. С молодёжью давно общались? Они не то что Exolon, R-Type и Elite, они не знают даже уже Аллоды, Quake-3 и StarCraft. А массы всё появляющегося нового софта и железа для столь известной марки? Вы не к словам придирайтесь, а между строк читайте.Цитата:
Сообщение от newart
jerri, а насколько, по Вашему опыту, целесообразно открыть здесь на форуме темы для разрешения возникших у меня в процессе портирования игр трудностей? Не погрязнет в обсуждениях типа “выкинь все свои игры нафиг и лучше сделай [подставить нужное]”? :v2_dizzy_tired2:Цитата:
Сообщение от jerri
А остальные, получается, результатам предпочитают старое доброе околоспектрумное чесание языков? :mad:Цитата:
Сообщение от jerri
Можно. Держите. Как раз на Обероне и как раз для Спека. Потрошка Дурачка-с.Цитата:
Сообщение от Eltaron
Ух ты, блин, как разрешение покорёжило. Не мелковато ли? Приложить оригинальные картинки в архиве?
Что, однако, не помешало на нём сделать ядро систем ETH Oberon и A2 (Active Oberon System), тако же, как и BlackBox Component Builder.Цитата:
Сообщение от bigral
Насчёт конфликтов между адептами языков. Это не стычки, по задумке это война. А ещё желание возводить вредные привычки в культ. Вы согласитесь, что популярность певицы или актёра в современном мире мало коррелирует с её/его талантом? Аналогию не продолжаю.
А это не прикол, это статья такая есть, заслуживающая ИМХО внимания, извольте полюбопытствовать:Цитата:
Что непонравилось, так это приколы типа - язык С умер :) и т.д.
http://primat.org/news/2010-11-06-352.
А действительно, где?Цитата:
Сообщение от newart
Выложил скриншоты процесса портирования игры Durak от CopperFeet на язык Оберон: http://zx.oberon2.ru/durak.htm
Это хобби такое. И чтобы взрастать как девелопер. И теперь я могу сказать, что уж в языках – разбираюсь. И перестаньте, пожалуйста, придираться.
Кажется где-то тут даже исходник сохранился: http://stef.anarxi.st/ru/portfolio.phpЦитата:
Сообщение от Rindex
А готовая игра была сделана с учётом модели памяти Орель БК-08 (Днепропетровский вариант Спектрум-совместимой машины), на оригинальном Спеке 48 кб оно конечно будет работать, но слегка не так как задумано. Кроме того, там турбозагрузчик с кассеты. Давнее было дело. Может в эмуле не пойтить.
Чтобы sdcc скомпилил Си файл (сгенеренный ofront) нужен SYSTEM.h для спектрума и вероятно ещё кое-какие системные функции. Это будет выложено ?
Ну, а где готовая игра-то? Эмулей много, может и пойдёт.Цитата:
Сообщение от Oleg N. Cher
Да.Цитата:
Сообщение от Valen
SYSTEM я получил из готового от Linux. Будьте готовы к тому, что его наверняка придётся дорабатывать.
Инструкция. Нужен режим 48 BASIC. Любуемся заставкой. Жмём Reset.Цитата:
Сообщение от Rindex
После вызова пункта "Инструкция" появятся цветные квадратики. Это экран был сохранён в доп.памяти "Орели" и "восстановлен". Жмите 2.Код:CLEAR 23999: LOAD ""CODE
RANDOMIZE USR 25e3
Посмотрел. Внятного решения там не предложено. Проблема остаётся. Любой более-менее сложный проект имеет условную компиляцию, и в ветках далеко не константы.Цитата:
Сообщение от Oleg N. Cher
alone, там же предлагают для разных версий держать наборы зависимых модулей - чем не вариант?
Тем, что разница обычно не в модулях, а в кусках процедур.
ну так разбросай процедуру по модулям :)Цитата:
Сообщение от alone
Оберон-2 тоже простой, я уверен, что проще Вашего PureBasic'а.Цитата:
Сообщение от jerri
Р.П.Богатырёв. Оберон как эсперанто программирования
http://www.computer-museum.ru/histsoft/ober_esp.htm
http://oberon2005.oberoncore.ru/paper/obe_esp.pdf
С.З.Свердлов. Арифметика синтаксиса
http://uni-vologda.ac.ru/cs/syntax/index.html
http://uni-vologda.ac.ru/cs/syntax/ariphm.htm
http://oberon2005.oberoncore.ru/paper/arith.pdf
Да, простота языка не только в синтаксисе, она в также минимально необходимой целесообразности. Считать Бейсик простым – можно, если это старый добрый Спектрум-Бейсик. Visual Basic уже не так-то прост. Pure – не знаю.
Давайте создадим такой способ, и будет. Или подождём пока кто-то создаст.Цитата:
если для оберона есть простой способ получения обьектного кода вида (оберон >> exe) а не как сейчас (оберон >> (cpp)о(asm) >> exe)
то его следует применить и для спека, а не городить огород из фронтэндов и sdcc, тогда да от оберона будет толк. тем более если он кроссплатформенный
Ага, значит “:=” это уродство, а “==” – признанная всеми и щедро во многих языках одобренная мэйнстримом эстетика.Цитата:
Сообщение от SpecialistMK87
Трудно считать иначе, когда десяток лет парил себе моск "достоинствами" Си++
Ну а Ваши public static extern __cdecl и всеми любимый #include не устарели нисколько и актуальны хоть даже сейчас?
А между тем всё давно разложено по полочкам, где, что и зачем. Ага, не встречали. Значит не там читаете.
Источник: http://citforum.ru/programming/digest/wirth/Цитата:
Стало модным относиться к нотации как ко вторичному аспекту, целиком зависящему от личных вкусов. Это отчасти верно, хотя выбор нотации не должен быть случайным. У этого выбора имеются последствия, обнаруживаемые в общем облике языка.
Общеизвестным плохим примером является выбор знака равенства для обозначения присваивания, восходящий к языку Fortran в 1957 г. и слепо повторяемый до сих пор массой разработчиков языков. Эта плохая идея низвергает вековую традицию использования знака "=" для обозначения сравнения на равенство, предиката, принимающего значения true или false. Но в Fortran этот символ стал обозначать присваивание, принуждение к равенству. В этом случае операнды находятся в неравном положении: левый операнд, переменная, должен быть сделан равным правому операнду, выражению. Поэтому x = y не означает то же самое, что y = x. В языке Algol эта ошибка была исправлена путем простого решения: присваивание обозначили через ":=".
Программистам, привыкшим к использованию знака равенства для обозначения присваивания, это может показаться придиркой. Но смешивание присваивания и сравнения действительно является плохой идеей, поскольку в этом случае требуется другой символ для того, что традиционно выражает знак равенства. Сравнение на равенство стали обозначать двумя символами "==" (впервые в языке C). Это является отвратительным последствием, приведшим к аналогичным плохим идеям использования "++", "--", "&&" и т.д.
В языках C, C++, Java и C# некоторые из этих операций вызывают побочные эффекты, известный источник ошибок программирования. Например, можно было бы принять "++" для обозначения увеличения значения на единицу, если бы то же самое не обозначало само увеличенное значение, что позволяет писать выражения с побочными эффектами. Неприятность состоит в удалении фундаментального различия между оператором и выражением. Оператор - это инструкция, подлежащая выполнению, выражение - это значение, которое надлежит вычислить.
Уродство конструкции обычно проявляется в комбинации с другими средствами языка. На языке C программист может написать конструкцию x+++++y, загадку, а не выражение, представляющую проблему даже для сложного синтаксического анализатора. Равняется ли значение этого "выражения" значению ++x+++y+1? Верны ли следующие соотношения?
x+++++y+1==++x+++y
x+++y++==x+++++y+1
Так можно было бы постулировать новую алгебру. Я нахожу совершенно удивительной невозмутимость, с которой мировое сообщество программистов приняло этого нотационного монстра. В 1962 г. установившиеся традиции аналогичным образом подорвало постулирование правой ассоциативности операций в языке APL. Тогда x+y+z неожиданно стало обозначать x+(y+z), а x-y-z - x-y+z.
У условного оператора языка Algol, представляющего пример неудачного синтаксиса, а не только плохого выбора символов, имелось две формы (S0 и S1 обозначают некоторые операторы):
if b then S0
if b then S0 else S1
Это определение порождает очевидную двусмысленность, получившую название проблемы "висящего else". Например, оператор
if b0 then if b1 then S0 else S1
можно интерпретировать двумя способами, а именно,
if b0 then (if b1 then S0 else S1) и
if b0 then (if b1 then S0) else S1,
возможно, приводящими к совершенно разным результатам. Следующий пример еще более серьезен:
if b0 then for i := 1 step 1 until 100 do if b1 then S0
else S1,
поскольку он может быть синтаксически разобран двумя способами, приводящими к совершенно разным вычислениям:
if b0 then [for i := 1 step 1 until 100 do if b1 then S0
else S1]
и
if b0 then [for i := 1 step 1 until 100 do if b1 then S0]
else S1
Однако выйти из положения здесь достаточно просто: нужно использовать явный символ end в каждой конструкции, являющейся рекурсивной, и начинать с явного стартового символа, такого как if, while, for или case:
if b then S0 end
if b then S0 else S1 end
P.S. Опять иду на флейм. У Вас имя Вирта, надеюсь, позывов не вызывает? Боже, как всё запущено. :mad:
Pure не сложнее ZX бейсика, сужу об этом написав десяток игр на том и другом.Цитата:
Сообщение от Oleg N. Cher
Pure просто чуток современнее, со всеми этими Case, структурами, локальными/глобальными переменными, списками, картами...
Но прелесть в том, что перелезая со спектрума, можно все это не юзать, а писать старинке с goto/gosub и забыв о навязчивых let/then.
Ты согласился бы со мной, что ifdef это частный случай if? :smile:Цитата:
Сообщение от alone
Господа.
Даже без наличия ifdef’ов в базовой поставке Оберона-2 “из коробки” мощности различных Оберон-диалектов хватает для написания ОС, компилятора, браузера (чему в инете много примеров, даже с исходниками), сетевых сервисов и динамических веб-сайтов, работы с БД, сяк-так GUI-приложений (хотя решений для традиционных ОС ощутимо меньше, чем для Оберон-ОС) и даже бортовой системы для управления безпилотным вертолётом. Я-то и занялся им чтобы понять пределы возможностей этой крохотульки. Но тут ещё невспаханное поле работы, есть к чему приложить усилия.
Мы пока ищем, исследуем. Как обходиться без препроцессора. Но заметьте, есть “Дубовые требования” для Oberon-2, в них предусматривается препроцессор и условная компиляция. Никто вобщем-то не мешает реализовать в нашем компиляторе Оберона даже столь любимый ifdef.
Я буду говорить о метасреде BlackBox Component Builder. В ней уже наблюдаются некоторые направления, позволяющие несколько отойти от чисто текстового представления программ. Вы наверное уже видели скриншоты процесса портирования Дурака на Спектрум? Там уже представление программы не чисто текстовое. И можно щас тут разтеять флейм, охаивая и поругивая недостатки такого подхода, но, как любое друге направление, облечающее софтостроение, оно имеет право на жизнь. Вообще тут наблюдается постепенное совершенствование подхода: сначала был просто текст программы, потом кто-то придумал его раскрасить. Не сразу придумал, но получилось красивше и более выразительно. Сейчас в моде фолдинг – сворачивание части кода внутри, так скажем, BEGIN и END. Тоже шаг. Далее, видимо, ещё что-нибудь придумают. Но в BlackBox кое-что уже есть. Но это сразу не видно, когда новоскачавший BlackBox Component Builder видит "Меню+лог". Это надо разбираться. Вникать. А зачем, если линукс всё равно мощнее. Примерно так думают.
Помимо механизма слотов, в которые могут включаться различные реализации одного модуля, есть механизм, называемый селекторы (DevSelector), это вкладки в тексте, куда можно помещать какой-либо другой текст (или внедряемые объекты, например, рисунки) с неограниченной вложенностью. Помимо этого, есть возможность пометить любую вкладку меткой, скажем, ZxSpec, Win32 или Linux, и открывать все нужные нам вкладки (или ветвь) с выбранной меткой одномоментно. Скажем, открыли вкладку ZxSpec и сделали реализацию процедуры для Спека, открыли Win32 – и сделали её же реализацию для Win32. В свете такого решения потребность в ifdef’ах значительно уменьшается, если не исчезает совсем. Но это мы коснулись только Оберон-системы BlackBox.
В далёких 90-х мне доставляло большое удовольствие писать на Hisoft Pascal. Компилятор, правда, занимал почти всю память, кодогенерация была ужасная, а строчный редактор – жутко неудобный. Но всё это затмевалось красотой языка. Чувствовалась мощь, солидность эдакая, уверенность что написанное заработает. И работало. Сегодня я уверенно утверждаю, что Оберон значительно красивее Паскаля, а уж если его усовершенствовать. Как сказал оберонщик Илья Ермаков: “Каркас идеального минимального императивного языка высокого уровня уже есть, можно спокойно сосредоточить все усилия на проблемах вышележащего уровня”. За точность цитаты не ручаюсь, но где-то так. C#-то чем берёт? Тем, что бухгалтерии клепать легко и быстро.
А почему Оберон такой минималистичный? Видите ли, мэтр Вирт считает, что добавить новые средства в язык всегда можно и никогда это не поздно, а вот добавленное изъять – нельзя уже никогда. Отсюда появление таких монстров как Delphi, Ada и C#. А куда движется вообще мэйнстрим? Ну не надо быть высоким профессионалом, чтобы узреть в Java кастрированный C++. А ведь сколькими эпитетами её восхваляли сие новейшее слово в девелоперском деле, да и продолжают это делать. А Java – это испоганенный Оберон с сишным синтаксисом.
Кстати, как правило, критики Си его как минимум использовали и хорошо знают, критики же Оберона все на одно лицо: “А, так в Обероне нельзя аггрегировать перегрузку шаблонов дружественного виртуального метода класса? Фтоппку! А ещё и нельзя написать a-=--(**c*(**a++)*--&b--)*(**c++)++ ? Фи, негибко получаецца. А ещё и ифдефов нет! Так это вообще капец! Так вы, наглецы, ещё и забыли, что такая серьёзная штука как ядро линукса написана не на вашем Обероне, так что выбросьте-ка его вы наффих и идите парить себе моск в универ и читать “Just for Fun”. Тьху, а тут ещё и устаревшие архаичные BEGIN и VAR? Это вообще плевок в лицо, ибо Паскаль умер миллион лет назад”. А вы разве не знали? Ага, мы тоже не знали. И умирал он долго и тяжело, и по сей день умирает. Сродни Спеку. А те, кто помогают его хоронить, могильщики от науки и искусства, сначала похоронив кроссплатформенное программирование (такого мощного разгула UNIX-подобных систем никакой майкрософт не предполагал), потом высчитывают сверхприбыли, не считая троллей, которые гнут ель, ибо тот, кто выбирает на чём и под что будут программировать, тот и имеет. Всех остальных. “Что у вас сегодня в меню, официант?” “Андроид, сэр!”
Ещё замечу чистого любопытства ради, что серьёзные разработчики, даже не зная Оберона, в отличии от неофитов вовсе не спешат его огульно хулить. “Этта сделано капустными академическими головами шобы парить моск и шобы было, а не шобы делать ядро линуха”. Примеры навскидку. Sam Lantinga, автор библиотеки libSDL. Andreas Schiffler, автор SDL_gfx, а также Philipp Klaus Krause, мэйнтенер SDCC-кодогенератора для Z80. Люди достаточно далёкие от Оберонов. Но они разрабатывали. Много и долго. Поэтому научились уважать чужие идеи и любые средства разработки. Ибо если их зачем-то разрабатывали, значит зачем-то они нужны. Это вопрос личностного и профессионального роста. Я не жду этого от всех, ибо наивно.
Если смущает факт разработки для Спека на чём-то ещё, кроме асма и Бейсика, то лично мне (как, надеюсь, и вам) никак не претит с удовольствием поиграть в ускоренного Дурака от CoppeFeet, Moggy или Phantomas Saga – Infinity или (вы удивитесь!) Cauldron. Мне кажется, отрицать пользу высокоуровневой разработки для Спека – это сознательно сужать область его применения. Для хорошо реализованных кросскомпиляторов с языков высокого уровня польза для Спека – для быстрого макетирования, в банальном облегчении трудоёмкости при создании утилит и кроссплатформенной (Спектрум в связи с другими платформами) разработки, создании обёрток с нижайшим оверхедом вокруг асм-библиотек, с последующей разработкой на них в качестве структурно-модульного клея. А может этот барьер умов в неприятии ЯВУ для Спектрум-разработки – хороший повод пойти покодить на асме, оставив высокоуровневое направление для тех, кому оно интересно? Всё же лучше, чем забить тем и другим на Спек вообще.Цитата:
Сообщение от newart
Ещё меня привлекает возможность, как и 15 лет назад (а помнишь, Alone, как ты меня упрекал в желании скрестить ПЦ и Спек? :smile:), разрабатывать на одном языке для Спектрума тако же, как и для других платформ. Уникальные алгоритмы, реализованные на Спеке, красивейшие по задумке и блестящие по реализации игры. Всё это можно и нужно использовать на других платформах. Но Бейсик и асм тут вряд ли годятся. А в эмуле кодить – это вы уж извольте. Да, на Си тоже можно, но Оберон лучше. Более высокий уровень. В связке Оберон + Си + асм, впрочем, можно получить лучшее от каждого из этих средств, то, в чём их сила. Асм – низкоуровневые подпрограммы для скорости и мощности, сама реализация, уровень “КАК это реализуется на Спеке”, Си – … гм, ну, применение найдётся. Например, в качестве связующего звена между Обероном и асмом. Ну и его величество – Оберон (уровень “ЧТО надо сделать”). Прошу любить и жаловать. Заметьте, уровень не подразумевает лишь только Спек. Мне удалось настолько хорошо абстрагировать Даш от платформы, что уши Спека из основного алгоритма, сердца и логики, не торчат аж вообще никак. Без ifdef'ов. Вот-с. Да вы можете это заметить хотя бы по исходнику процедуры Play.
Смущает необходимость изучать новый язык и среду разработки.Цитата:
Сообщение от Oleg N. Cher
Я на пц обхожусь PureBasic / PHP / JS / C, на спектруме Ассемблером.
Куда логичнее перенести на спектрум, что то из перечисленного чем изучать новое.
не хотелось бы вдаваться в палемику, но всё же:
не устарели и ещё долго не устареют, т.к. другого способа включить в собираемый проект какие то нужные части пока не придумали. если в оберне нельзя делать подгрузку таких кусоков, зачем он тогда нужен?Цитата:
#include не устарели нисколько и актуальны хоть даже сейчас?
нет не всеми. в том же пуре бесике или в том же blitz basic`е оператор сравнения не отличается от оператора присвоения. на си его отделили. теперь уже поздно говорить о том, что верно это было решение или нет.Цитата:
Ага, значит “:=” это уродство, а “==” – признанная всеми
не может. такие конструкции являются особенностями отдельных компиляторов.Цитата:
языке C программист может написать конструкцию x+++++y, загадку, а не выражение
ифдефы очень помогают, когда нужны условия компиляции или сделать макросы. очень жаль временами бывает, что в том же блице нет таких штук.Цитата:
А ещё и ифдефов нет!
какие плевки, вы о чём? товарищ кроме бегловго взгляда смотрел ещё на какие то языки? конструкции с участием бегинов и варов существует великое множество. причём не только в языках программирования, но и в отдельных скриптовых языках. например в том же lua, например в том же папирусе..да много где. загляните в игры, таже серия игр от бетезды - фаллауты (3 и нью вегас), обливион, скайрим. можно заглянуть в в язык mel который используется в autodesk maya.Цитата:
устаревшие архаичные BEGIN и VAR? Это вообще плевок в лицо
языков существует привеликое множество. мне вот например импонирует отдельно блиц за его простоту, си за возможности...ну пожалуй луа за унивирсальность. любой язык можно применить к спектруму и любой другой платформе. что, точнее чем так выделяется оберон, пока не понял. по виду типичный бейсик, судя по синтаксису,с примесью паскаля/дельфи.
Вряд ли Вам щас понравится, если я начну про засратые сями и явой мозги парить, правда? :wink: То-то же.Цитата:
Сообщение от farewell
Такие вещи в Виртовской линейке языков обычно решаются вложенными процедурами, что примерно то же, но Ваш "фрейм" штука анонимная, а процедура позволяет показать что Вы имели ввиду, решив построить код именно таким образом.Цитата:
Сообщение от farewell
Код:PROCEDURE A;
VAR
z, x: INTEGER; (* Это общие для "фреймов" переменные *);
PROCEDURE Frame1; VAR a, b (* Это личные переменные "фрейма" Frame1 *)
END Frame1;
PROCEDURE Frame2; VAR a, b (* Это личные переменные "фрейма" Frame2 *)
END Frame2;
BEGIN ...
END A;
Оберон-2:Цитата:
Сообщение от Valen
В Active Oberon малость посложнее, там есть милые сердцу OBJECT и SELF, но принцип в целом тот же.Код:TYPE
ElemType = INTEGER;
Stack = RECORD
a, b ... (* это внутренняя реализация, снаружи не видно – инкапсуляция *)
END;
PROCEDURE (VAR s: Stack) Push* (elem: ElemType);
...
PROCEDURE (VAR s: Stack) Pop* (): ElemType;
(* Здесь s – это поименованный self, снова не анонимный. Это удобно *)
...
VAR
stack1, stack2: Stack;
BEGIN
stack1.Push(123); stack2.Push(stack1.Pop());
А вот наследование:
http://forum.oberoncore.ru/viewtopic.php?f=8&t=2121Код:TYPE
ExtendedStack = RECORD (Stack)
(* Запись унаследована от расширяемой записи Stack *)
a, b, c: SomeType; (* Это дополнительные поля *)
END;
PROCEDURE (VAR es: ExtendedStack) SomeProc1 ...
PROCEDURE (VAR es: ExtendedStack) SomeProc2 ...
(* Это доп. методы *)
http://forum.oberoncore.ru/viewtopic.php?f=29&t=2125
Перенести на Спек PHP или JS? Ор-ригинально, батенька. Уже кажется Java переносили, тока 32-битность помешала. Но попробуйте, чего ж. А раз освоили PHP (и особенно JS), то Обероны пустячок, уверяю-с. :wink:Цитата:
Сообщение от newart
А Вы вот это видели?
ZX BASIC compiler v1.2.5, by Jose Rodriguez.
Allows you to write a BASIC program on your PC and convert it to TZX to run on your real Speccy/emulator. The compiler works in all of PC/Windows, Linux and Mac OS X.
http://www.boriel.com/software/the-z...piler/?lang=en
Z80 Advanced Forth Compiler build 8 (PC/Windows), by Dumitru Florin Gabriel.
http://www.worldofspectrum.org/utilities.html (оф.сайт не открылся)
The ccz80 language
CCZ80 v2.0.5 (PC/Windows), by Emilio Guerrero.
The ccz80 language has a syntax based on the C language and produces assembler code - an assembler is integrated in the compiler.
http://www.telefonica.net/web2/emili...z80/ccz80.html
Вобщем, осталось только Обероны освоить. И сделать компилер. Всё остальное для Z80 уже есть. :wink:
Цитата:
Сообщение от Kakos_nonos
Не подарочек, однако его достоинство в том, что он есть! И развивается.Цитата:
Сообщение от ZEK
Господа, прошу покорнейше в ветке http://zx.pk.ru/showthread.php?t=18387 раскрыть своё видение каким по-Вашему должен быть компилятор Оберона для ZX.
---------- Post added at 16:22 ---------- Previous post was at 16:11 ----------
Не хочется впадать в маразм, но всё таки… Вы про модульность когда-нибудь слышали? Хорошо, посмотрим на проблему по-иному. ЗАЧЕМ включать кусок текста программы в кусок текста программы?Цитата:
Сообщение от Sayman
Реальный пример из реальной жизни. У меня в проекте Дурак есть тип BOOLEAN, внутри SYSTEM.h, не то что мне так захотелось, так по задумке создателей Офронта назван стандартный тип. Теперь мне понадобилось при портировании под Win32/GCC подключить другой стандартный "модуль" windows.h, в нём тоже есть тип BOOLEAN. При инклюживании они оба накладываются друг на друга, #undef’ить один из них нельзя, так как это не #ifdef’ное определение, а тип. Вот Вам пагубность включения плоского куска текста в плоский кусок текста, без учёта накладок. Какая там к чёрту модульность. Но однако же вбилось в голову как шило, что никак иначе нельзя. Без этого сыр не настолько остр. Sayman, подобны же и Ваши другие претензии. Мы уже давно всё это обсосали на форуме OberonCore, я с Вами теряю время.
Сравнение и присваивание это всё-таки разные вещи? В классическом Бейсике они помечались одинаковым "=", но отличались LET или IF.Цитата:
в том же пуре бесике или в том же blitz basic`е оператор сравнения не отличается от оператора присвоения. на си его отделили. теперь уже поздно говорить о том, что верно это было решение или нет.
Плевок тут в том, что Вы сразу схватились за клавиатуру охаить малонравящуюся Вам Дельфи-подобную муть, малопохожую на ту муть, в которой варитесь Вы, и подобные Вам идут за Вами, попирая Ваш шаг; имя им легион.
я вижу что с языками вы слабо знакомы, особенно с языком си.
#ifndef __BOOLЦитата:
так как это не 3ifdef’ное определение
typedef unsigned int bool;
#define __BOOL
#endif
соответственно никто вам не мешает и инклуды в линухах подправить аналогичным образом. но только зачем, ведь проще обоSрать, чем понять.
вы даже не понимаете разницу между синонимом и макросом. почитайте внимательно мануал и тогда поймёте.
плевок тут в том, что человек купив книгу и прочитав 10 или 20 страниц понимает, что такое ему не асилить и начинает на одном и другом и т.д. форумах громогласно возмущаться сложностью и навороченностью того или иного языка.Цитата:
Плевок тут в том
я не противник дельфи, когда то пробовал понять и изучить и паскаля и дельфи. но понял что асилить не смогу. переехал на си. однако то что изучил, помогло в дальнейшем понимать чужие исходники на паскале.
кроме того, есть ещё один момент - если нельзя "ундефить" тип, значит можно использовать тот что уже есть на той платформе, под которую портируете свой проект. в крайнем случае, никто не мешает создать свой, например uboool. это плата за портируемость. если язык не позволяет делать кроссплатформенные программы (пусть даже с какими то переделками),то у такого языка мало шансов на выживание. если, например, у такого типа как int на пц разрядность 32 бита, то на спектруме у него 16 бит разрябность и при портировании это учитывается. очень сомневаюсь что в обероне такие детали учтены.
могу привести пример - я взял исходники программы mkfs под мсхдос и портировал под профи. пришлось поработать над библиотекой, избавиться от функционала мсх, однако сама прога собралась замечательно, даже фирменные баги перешли на профика. единственное, я там убрал одну единстенную функцию, которая делал обращение к мсхдос и вызывала низкоуровневое форматирование. а вот fsck вапще не меняя просто скомпилил и она сразу заработала. я лично сомневаюсь в том, что можно взять исзодники под оберона и собрать так же просто на нашем брате. но спорить не буду. удаляюсь...
для хобби синтаксис наверно и не важен :)
для серьезной работы важно:
время выполнение работ по разработке ПО;
надежность кода;
сопровождаемость кода ( уволился программист или в отпуск пошел ).
наличие излишеств вроде VAR, BEGIN, END и т.п. уже сами по себе
для большинства программистов снижают читаемость кода, ухудшают сопровождаемость, увеличают сроки разработки. А все это - стоимость... Более длинный код тяжелее проверить.
:= почему плохо?
большинство программистов уже привыкло ставить '=' и '=='. И уже неважно 'правильно' это или нет. Это уже есть. Применив в разработке язык с присвоением ':=' получишь сразу увеличение сроков и стоимости. Только за счет такой мелочи!
Правда, бывает другая крайность - например, Perl. Исходники совсем короткие, пишешь быстро, зато даже самому потом нелегко разобраться
На мой взляд, оптимум с точки зрения синтаксиса сейчас Python 2.x. Заодно заставляет программистов аккуратно исходник форматировать. И большие проекты на нем очень хорошо делать - быстрее в 2-3 раза чем аналогичный код на C/C++.
Порой деваться некуда и приходиться писать программы на том языке, который есть под конкретную аппаратуру. Но когда есть возможность выбора - зачем создавать себе ненужные проблемы?
Такое хобби как oberon-2 можно уважать, но БОЛЬШИНСТВУ программистов-профессионалов его синтаксис не понравится. Можно порассуждать и обосновать с 'научной' точки зрения почему они дураки, а Вирт умный но это будет уход от реальности
мое мнение - Вирт с самого начала разрабатывал языки, с удобным для него лично синтаксисом. Он ведь много их разработал (в том числе Algol W, Pascal, Modula, Oberon ), широко применялся только Pascal, причем его основное назначение - обучение студентов. Лично я вздохнул с облегчением, когда перешел с него на C. Уже за одни фигурные скобки спасибо Ричи можно сказать. И я не один такой. Т.е. Вирту удобно, мне нет. И большинству - нет.
PS ' ; ' - это тоже архаизм и излишество :v2_dizzy_snowball:
Ветка превратилась в очередное соревнование "язык, который я удосужился выучить, лучше, чем тот, который знаете вы" (фаллометрию). Мне приходилось по жизни писать на 36 разных языках (включая диалекты, правда). Язык что выучить, что использовать - это сущие пустяки. Основная трудность - набор библиотек к ним. Язык выбирается исходя из простоты решения задачи на нем. Мой любимый яхык - это тот, с помощью которого я зарабатываю деньги. В остальном все языки одинаковы. Не зависимо от == и :=, например. Я этого просто не замечаю, автоматичемки использую нужные конструкции где надо. Так что учите языки (это, повторюсь, пустячная задача), используйте их на практике, и переставайте наезжать на VAR, ';' или #define - это смешно.
Я вижу, Вы слабо вникли в высказанную мною проблему. Я ещё раз повторюсь: оба "модуля" – стандартные, править их крайне дурной тон. Я просто хотел бы воспользоваться ими одномоментно, включить их в один свой модуль сразу оба, как библиотечные, но они мешают друг другу, потому что не знают ничего друг о друге. Тут же умники придумали затычку – пространства имён. И тут же возвели её в культ. А другие умники потихоньку к ней привыкли и разучились видеть какие-то другие решения.Цитата:
Сообщение от Sayman
Эхехе. Меня кажется не слышали. Эгей, товарищ! Оба "модуля" стандартные!!!Цитата:
никто не мешает создать свой, например uboool.
Наверное Вы просто больших программ не писали, и привыкли пользоваться затычками. Это очень плохо.
О, представьте себе, в Обероне сделано ещё лучше, в нём при написании одних модулей разрядность платформы можно учитывать, а при написании других – игнорировать.Цитата:
если язык не позволяет делать кросскак int на пц разрядность 32 бита, то на спектруме у него 16 бит разрябность и при портировании это учитывается. очень сомневаюсь что в обероне такие детали учтены.
Всё же мне кажется, на Обероны Вам не хватит терпения.
Ладно, продолжаем ликбез.
В Оберонах уже довольно давно вместо тупого включения куска текста в кусок текста программы, порождающего массу проблем зависимости между разными частями программы, предусмотрена модульность, и даже не только статическая, но и динамическая. Ближайший аналог этой концепции – механизм .SO/DLL в Linux/Windows.
Осмелюсь утверждать, что Оберон-концепт более совершенен, ибо динамические Оберон-модули не зависят от базовой платформы и хост-системы, оставаясь Оберон-модулями, они – возможность языковая, не имеющая аналога на уровне языка ни в Си, ни в Паскале, кроме того, в отличии от .SO/DLL модули могут включать, помимо процедур, ещё и типы, константы и переменные.
Особенности поддержки концепции модуля
в языках Delphi (Object Pascal), Modula-2 и Оберон
http://www.oberon2005.oberoncore.ru/qa261005.html
Динамическая модульность в BlackBox - OberonCore
http://oberoncore.ru/wiki/динамическая_модульность
Модульное программирование: Terra Incognita
http://oberon2005.oberoncore.ru/qa191005.html
Вероятно, готовые программы, содержащие ошибки проектирования, будет переносить так же непросто, как и программы на Си, если модули очень плотно к платформе приклеены, буквально в каждой процедуре подразумевается, что платформа именно такая. Обероны же могут помочь в получении более чисто спроектированной программы. Кстати, выработать кроссплатформенную логику библиотек, достаточно экономичную для разворачивания как на Спеке, так и на других платформах, ИМХО достойная задача. Можно поработать в этом направлении.Цитата:
могу привести пример - я взял исходники программы mkfs под мсхдос и портировал под профи. пришлось поработать над библиотекой, избавиться от функционала мсх, однако сама прога собралась замечательно, даже фирменные баги перешли на профика. единственное, я там убрал одну единстенную функцию, которая делал обращение к мсхдос и вызывала низкоуровневое форматирование. а вот fsck вапще не меняя просто скомпилил и она сразу заработала. я лично сомневаюсь в том, что можно взять исзодники под оберона и собрать так же просто на нашем брате. но спорить не буду. удаляюсь...
Я бы предпочёл более осмысленно вести диалог, помогая желающим научиться писать проги на Обероне для Спека. И только это. Но увы. Обсуждение вылилось в то, во что оно вылилось.
Если возник вопрос – зачем программировать на Обероне для Спека, если можно на Си? Си популярен. Оберон малоизвестен. Си опробован. Оберон наверняка содержит подводные камни. Когда-нибудь я опишу, возможно, здесь на форуме, как я пришёл к Оберонам, однако пока могу только попросить желающих программировать на Си вместо Оберона не уподобляться господину, который Толстого не читал, но произведения оного ему определённо не нравятся.
Если сомневаетесь в моей квалификации, надо вспомнить, что моя первая игра для Спека – Tiny Tetri$ на Бейсике и асме – разработана в 1995 году. Это, наверное, должно значить, что Бейсик и асм для меня давно не являются чем-то новым, а раз так, то, наверное, если я говорю о преимуществах Оберона перед Бейсиком, то есть смысл прислушаться, тако же когда я буду говорить об Оберон-разработке для Спека. Хотя я не собираюсь ничего никому навязывать. Бейсик был хорош тем, что его интерпретатор влез в ПЗУ. Это от бедности. Форт там тоже бы красиво смотрелся. Наверно.
А ещё – есть люди-создатели и люди-потребители. И спектрумисты, как никто, должны понимать между ними разницу. При этом создатель создаёт и делает что-либо доступным, включая идеи, а потребитель обливает всё *****м и кричит ”давай ещё, и побольше”, угнетая и без того хрупкие и чувствительные натуры создателей.
Действительно. Да и на Си не зачем. Потому что язык должен быть эфективным. Я вот в первом своем посте в этой ветке запамятовал сказать, что не только язык, но и среда разработки должна быть эффективной. Для Спека пишут на всяких Бэйсиках и ассемблерах по причине того, что это отлаживать хоть как-то можно. Вроде как, Форт еще позволяет отлаживаться хоть как-то. А на Си и Паскале не пишут, а балуются. Потому что вот ну никак вот не получается отладить по шагам написанный код, посмотреть значения переменных на рантайме, глянуть, что нарисовалось на экране, что несерьезно в больших проектах. А связку Оберон - Си - ассемблер вообще не понятно как отлаживать на целевой платформе.Цитата:
Сообщение от Oleg N. Cher
Очень весело слышать это, в особенности от Вас, уважаемый.Цитата:
Сообщение от Sayman
Хорошо. Ладно. Допустим даже, что Ваш макрос “помог”. Мы влезли в оба заголовочных "модуля", Офронта и винды, и вставили туда наше рулезное дополнение. Ибо одним "модулем" тут правка, видимо, ограничиться не может. Если может, блесните умом.
Но ещё и представим себе довольно вероятную возможность, что тип BOOLEAN внутри SYSTEM.h у нас является типом signed char, а тип BOOLEAN внутри windows.h – типом usnigned int.
Итак. Внутри windows.h мы имеем нечто такое:
Внутри SYSTEM.h же мы имеем нечто такое:Код:#ifndef __BOOL
typedef unsigned int BOOLEAN;
#define __BOOL
#endif
Наш весёлый "модуль" SYSTEM.c, думая, что тип BOOLEAN является однобайтовым, хотя его подленько уже могли подменить инклюдом windows.h перед инклюдом SYSTEM.h (а Си-прога, которая так сделает, может строиться Офронтом автоматически) на четырёхбайтовый, начинает юзать его во всю его однобайтовую душу. И – понесла нелёгкая, перекорёжив разрядность типов.Код:#ifndef __BOOL
typedef signed char BOOLEAN;
#define __BOOL
#endif
А наша весёлая программа могла бы конечно учесть, что BOOLEAN в таком разе – штука непростая, и надо выкурить много бамбуку, чтобы получить хоть какую-то осмысленную пользу от его использования, а ещё оно сильно вообще зависит от порядка инклюдирования "модулей" SYSTEM.h и windows.h, что ещё полбеды, а основная беда начнётся когда "модулям", берущим тип из SYSTEМ.h и windows.h, неявно подпихнут другой тип, их это должно здорово взбодрить.
Хорошо если программа сразу вылетит, а если не заметишь, и вылеты с порчей памяти и загадочным залезанием в чужие области и желанием выслать отчёт к какой-то матери регулярно будут у заказчика через месяц после сдачи?
Я как раз – об ощутимой помощи от использования Оберон-технологий в как можно более скорейшем выявлении такого рода узких мест. И чтобы влияние как закрытой реализации, так и открытой интерфейсной части одного модуля на другой сводилось к минимуму.
насчет препроцессоров, уже прошли те времена когда препроцессор надо было иметь именно встроенном в языке, можно просто взять и заюзать внешний, например мой http://code.google.com/p/java-comment-preprocessor/
А это вообще народная программерская забава такая - намешать в одном коде исходников несовместимых от разных комплектов библиотек, и объявить язык убогим за то, что он это позволил.Цитата:
Сообщение от Oleg N. Cher
Вопрос действительно очень интересный и не имеющий одного простого решения. С одной, впрочем, стороны поймём, что масштаб Оберон-проектов для ZX пока что ограничен 48кб памяти, поэтому говорить о реально больших проектах не приходится. С другой – взгляды Оберон-сообщества на отладку Вам вряд ли понравится.Цитата:
Сообщение от Alex Rider
Я использую для отладки ASSERT'ы, и debug-вставки с отладочной распечаткой.
Код:MODULE Sets; (* portable *)
CONST
Debug* = TRUE;
END Sets.
Для профилирования использую эмулятор Fuse. В качестве пошагового отладчика – эмулятор Владимира Кладова EmuZWin. Так и баги в кодогенераторе SDCC искал, так и свои проги дебажил. С третьей стороны, если создать Оберон-обвязку в стиле ZX, то появляется интересная возможность отлаживать кроссплатформенные Оберон-модули, подходящие и для ZX, внутри хост-Оберон-среды типа A2 или BlackBox. Это возможно. Надо разрабатывать инструментарий.Код:MODULE Grx; (* portable *)
IMPORT Sets, Debug;
...
PROCEDURE PutSprite* (x, y: SpriteCoords; spr: Sprite);
BEGIN
IF Sets.Debug THEN (* Это прямой аналог ifdef'а, однако если Debug = FALSE, то никакого лишнего кода в прогу не вставится *)
CASE x OF 0..MaxX: CASE y OF 0..MaxY: ELSE Debug.Stop("Bad sprite coords!") END END;
END;
...
END PutSprite;
END Grx.
Я также не против иметь готовый пошаговый отладчик Оберон-программ чисто для Z80. Осталось его написать.
А ещё Вы удивитесь и не поверите, но на самом деле потребность в отладке в Оберон-программах не такая большая, значительно меньше, чем на Си. Помогает и охрана типов, и автоматическое управление памятью. Но это не про связку Ofront/SDCC.
Угу, а кто их объявил несовместимыми друг с другом? Это же "модули"! :v2_dizzy_mutant:Цитата:
Сообщение от Alex Rider
Именно!Цитата:
Сообщение от Raydac
Вот. Игорю тоже пришлось. :)
Raider, Raydac, можете поспособствовать регистрации на данном форуме ещё одного оберонщика и спектрумиста? Ибо он пробовал зарегистрироваться, но регистрация отключена администрацией. Типа намёк: не любят здесь неофитов. А я припёрся весь такой красивый. :)
prisekar - Регистрация: 07.03.2012Цитата:
Сообщение от Oleg N. Cher
Здравый смысл. Использование модулей из разных библиотек черевато неприятностями. Ты встретил такую неприятность.Цитата:
Сообщение от Oleg N. Cher
Сказано сильно. А в Оберонах модули и библиотеки – это одно и то же.Цитата:
Сообщение от Alex Rider
Sayman, мы с Вами говорим не только о разных языках, но и на разных языках. Я Вам про узкие места Си и про саму ущербность принятых там идеологических решений, с примерами, а Вы вроде даже не поняли примера. Начали мне тыкать костыль – эмулятор модульности ”#ifndef ___VARY_BAD #define ___VARY_BAD , надеясь меня этим удивить. Вы полагаете, что я не видел эдакого построения? Да нет же, и видел, и пользую. Даже выкладывал где-то тут SYSTEM.h, в котором применяется онная хрень. Однако Вы даже не предложили нормального способа решить обозначенную мною проблему, а просто послали меня учить матчасть. А я Вам – про идеологию, в которой таких проблем быть в принципе не может. В целях повышения образованности, как говаривал почтальон Печкин.Цитата:
Сообщение от Sayman
---------- Post added at 21:39 ---------- Previous post was at 21:30 ----------
Я только что попробовал, и правда отключена.Цитата:
Сообщение от newart
CityAceE, агов! И где он бегает...
на другой стороне Земли во Владике, в будущем на девять часов :) , так что учитывайте разность времени, когда стучитесь :)Цитата:
Сообщение от Oleg N. Cher
Круто. Вот в Delphi можно сказать, что есть модуль Forms.pas библиотеки VCL. В Visual C++ есть библиотеки ATL, MFC с модулями внутри. А в Обероне не принято группировать модули (библиотеки?) по принципу разработки для совместного использования что ли? Каждый кусок кода в отдельном файле, разработанный кем-либо - он сам по себе, и все вместе попарно они всегда совместимы?Цитата:
Сообщение от Oleg N. Cher