OberonCore https://forum.oberoncore.ru/ |
|
Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x86 https://forum.oberoncore.ru/viewtopic.php?f=30&t=6344 |
Страница 3 из 17 |
Автор: | Artyemov [ Воскресенье, 16 Июнь, 2019 16:55 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): Это будет беспрецендентно для Оберонов А какой предлагается синтаксис? Как-то так? Код: FOR i: INTEGER = 1 TO 10 DO ... END P.S. В Eberon'е сделано так: Код: FOR i <- 0 TO 10 DO ... END Ох, чую, доживу до криптосинтаксиса типа Цешного такими-то темпами... ("область видимости переменных" плавно дробится на " -"- параметра цикла ") |
Автор: | Oleg N. Cher [ Понедельник, 17 Июнь, 2019 02:30 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Artyemov писал(а): Ох, чую, доживу до криптосинтаксиса типа Цешного такими-то темпами... ("область видимости переменных" плавно дробится на " -"- параметра цикла ") Да, мне тоже нравится, что на Обероне ВСЕ переменные описываются в секции определения до блока кода. Так действительно проще воспринимается отделение кода от данных, чтобы не всё вперемешку. БОльшая структуризация. "Горячее" определение переменных в коде, хоть и из благих намерений, всё это ломает. Так что не перейдём ли мы какую-то грань здесь?
|
Автор: | Info21 [ Понедельник, 17 Июнь, 2019 05:40 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Перейдём. Не надо переходить. |
Автор: | Wlad [ Понедельник, 17 Июнь, 2019 12:13 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): Это будет беспрецендентно для Оберонов Почему?Oleg N. Cher писал(а): А какой предлагается синтаксис? Как-то так? Код: FOR i: INTEGER = 1 TO 10 DO ... END Зачем указание типа? В Обероне нет ничего стандартного, по чему можно "пробежаться", кроме, как по массивам. там индекс ВСЕГДА - ЦЕЛЫЙ. Потому, просто (как в Аде): Код: FOR i := 1 TO 10 DO Естественно, в компиляторе нужно выводить предупреждения или ошибки в случае перекрытия уже объявленных одноимённых переменных (ещё более естественно, что попытка использования "цикловолокальной" переменной после цикла должна приводить к ошибке компиляции. Нужен ещё синтаксис доступа к переменной, которую перекрыла переменная цикла... Типа OUTER.i := i или VAR.i := i ещё как...).... END Другой вопрос, что делать со ВТОРОЙ ГРАНИЦЕЙ диапазона цикла? В смысле - делать ли её ПЕРЕвычисляемой в процессе выполнения FOR цикла, или оно фиксируется константой при вхождении в цикл, а вариант с перевычислением оставляем на LOOP-, WHILE- и REPEAT- циклы? |
Автор: | Oleg N. Cher [ Понедельник, 17 Июнь, 2019 15:18 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Wlad писал(а): Oleg N. Cher писал(а): Это будет беспрецендентно для Оберонов Почему?Wlad писал(а): Зачем указание типа? В Обероне нет ничего стандартного, по чему можно "пробежаться", кроме, как по массивам. там индекс ВСЕГДА - ЦЕЛЫЙ. В Оберонах, не считая 07, для счётчика цикла может быть использован любой целочисленный тип от SHORTINT (BYTE в КП) до LONGINT. И вовсе необязательно счётчик цикла должен быть как-то связан с индексом массива.Влад Фольц не задаёт тип в Eberon'ском FOR потому, что у него даже BYTE, видимо, для счётчика не используется. А это может быть полезно на 8-битных процессорах. Хотя охотно признаю, что Оберон-07 приспособлен для не 32-битных процессоров плохо. Wlad писал(а): Другой вопрос, что делать со ВТОРОЙ ГРАНИЦЕЙ диапазона цикла? В смысле - делать ли её ПЕРЕвычисляемой в процессе выполнения FOR цикла, или оно фиксируется константой при вхождении в цикл, а вариант с перевычислением оставляем на LOOP-, WHILE- и REPEAT- циклы? Для FOR в такой перевычисляемости на каждой итерации обычно нет никакого практического смысла. Напротив, в сохранении конечного значения в скрытой переменной смысл есть.
|
Автор: | Oleg N. Cher [ Понедельник, 17 Июнь, 2019 23:14 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Олег Комлев решил поучаствовать в нашем обсуждении. Saferoll писал(а): На форуме Oberoncore обсуждается вопрос "Следует ли сделать переменную цикла FOR еще более локальной (ограничить локальность телом цикла)". Тогда будет больше похоже на FOR в Аде, что по смыслу цикла FOR - хорошо.
Технически это сделать можно, ведь создается же там временная скрытая переменная для граничного значения, почему бы не создать и видимую? Но, понятно, что реализация будет сложнее - надо вводить отдельную область видимости именно для тела цикла. Независимо от технической возможности, возникает вопрос "а верно ли это по духу Оберона"? Однако "дух"- понятие не формализуемое, поэтому каждый понимает (и имеет право понимать!) это по-своему. Конечно, счетчик цикла по смыслу является связанной переменной внутри тела цикла, поэтому самая правильная область его локализации - тело цикла. Это довод ЗА. Против - слишком большие отступления от привычных областей видимости. Со скрытой переменной таких проблем нет именно потому, что она скрытая! А тут получается, что кроме кроме блока процедур есть отдельные области еще и внутри тела процедуры (тело цикла FOR). То, что я ранее предлагал в реализации "правильного FOR", касалось семантики и механизма реализации, от синтаксиса и "основных принципов" отступлений не было (принципы "не менять переменную и не использовать ее значение после цикла" - нормальные "структурные" принципы, аналогичные паскалевским). Требование для счетчика быть локальным в пределах процедуры не затрагивает сами области видимости. А вот появление счетчика в заголовке FOR и пропадание его после цикла кажутся мне уж слишком большим "переломом традиций". Может быть, конечно, на мое мнение подсознательно влияет и лень в поиске механизма реализации "локальнофоровой" переменной , но я думаю, лучше ограничиться локальностью на уровне процедуры, как это сейчас сделано. Это некий компромисс между самой широкой локальностью (отсутствие требований локальности вообще) и "самой правильной по смыслу цикла FOR локальностью" (локальность ограничена телом цикла). Цикл FOR в Аде имеет свои плюсы, но с точки зрения "величины изменений основных принципов" минусы перевешивают. Аде - адово, Оберону - обероново. Кстати, в Паскале-подобном языке Modula-2 Revision 2010 цикл FOR по своим свойствам похож на аналогичный оператор в Аде: 1) Заголовок цикла является описанием переменной цикла, она существует пока цикл выполняется, но исчезает по окончании цикла. 2) Переменную цикла нельзя менять в теле цикла, она меняется автоматически - так, как задано в заголовке. По синтаксису в простейшем варианте тоже выглядит похоже на Аду Код: FOR n IN [1..10] OF INTEGER DO ... END но полный синтаксис FOR в Модуле-2 (rev.2010) сложнее (и, на мой взгляд, излишне наворочен и усложнен). |
Автор: | Wlad [ Вторник, 18 Июнь, 2019 00:51 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): Олег Комлев решил поучаствовать в нашем обсуждении. Хочу сделать небольшое "отсупление/замечание" о моей субъективности, когда я обсуждаю вопросы подобного рода... Понимаете, в подобных случаях у меня в голове начинают "проигрываться" синтаксис и семантика аналогичных вещей из кучи других языков. Как раз мне лично "упрятывание" (или - введение ещё одной, "вложенной" области видимости в циклах) кажется не "отступлением от принципов", а - прямым следованием им. Это мы в оберонах не выделяем конструкции цикла в "отдельный функционал". А, например, в Смолтоке (только не надо сразу "взбрыкивать", что мы речь не о смолтоках ведём! я предупредил, что сейчас знакомлю вас с демонами из моей головы! ) - вообще в ЯЗЫКЕ ни "циклы", ни "условные операторы" НЕ ОПРЕДЕЛЕНЫ. Там всё является объектами. И - ничего кроме них нет. С объектами можно общаться только через сообщения. Поэтому и циклические конструкции там также выражаются через посылку сообщения(например, в простейшем случае) целому числу. А - можно и (что более методически и идеологически правильно) - объекту коллекции. Например: Вычисления для определения суммы четных чисел в диапазоне 2..100 можно организовать "цикл" следующим образом: Код: sum <- 0 То, что в квадратных скобках - оператор блока (с параметрами). Слева от вертикальной черты в квадратных скобках объявлен формальный параметр. Перед его наименованием стоит двоеточие. Методы to:by:do: определяются в классе Smalllnteger. Значения управляющих переменных вычисляются последовательно по мере передачи их в качестве параметров оператору блока. Поскольку при этом сообщение, необходимое для вычисления, должно передать фактические параметры, используется сообщение value. Определение такого цикла имеет вид: 2 to:100 by:2 do:[ :each | sum <- sum+each ]. Код: TO:LIMIT BY:STEP DO:BLOCK Если внутри оператора блока имеется оператор возврата, то выполнение сообщения, определяемого этим оператором блока, заканчивается. С помощью оператора блока можно реализовывать также сопрограммы, исключительные состояния, процессы и т. д.Только не надо указывать на "неэффективность" такого цикла. Здесь показана иллюстрация принципа чистых объектов и посылки им сообщений. В реальных смолток-машинах всё решается намного эффективней.(SELF <= LIMIT) IFTRUE: [ BLOCK VALUE:SELF. (SELF+STEP) TO:LIMIT BY:STEP DO:BLOCK ] Кстати, интересно, что в лекции на вручении премии Тьюринга, Вирт всячески настаивал, что надо как можно сильнее ограждать программиста от подробностей реализации вычислительного механизма. И я с этим принципом согласен полностью. И в паскаль-языках это выполняется последовательней и аккуратней, чем в Си. Именно поэтому паскаль-языки более приятны в программировании для меня, чем Си. Паскаль-языки - всегда воспринимаются "более абстрактными и высокоуровневыми" изначально. И - тут же - Вирт, через решения в своих языках начинает противоречить себе. Я имею в виду - как раз перебор элементов в "коллекциях" (которые представлены в его языках только массивами). Одно то, что он может использовать в качестве "индексаторов" переменные разного целого - уже свидетельствует о незавершённости решения. Аргумент о "возможности выбора и настраиваемости под конкретные требования, задачу и эффективность" здесь не подходит. Потому, что само возникновение требования к типу "индексатора" - уже прямая отсылка к вычислительному механизму. Более того, уж если Вирт остановился на пол-пути к максимальной степени абстрагирования, то давайте облегчим участь программиста, хотя бы на уровне организации доступа к элементам массива. Я это к тому, что, по сути, код циклов - таки - ОРГАНИЗУЕТ новую, вложенную область видимости. Но, в отличие от Ады, в оберонах нельзя вписывать VAR. Да, часто, это и по организации кода не нужно, А вот иметь счётчик-переменную цикла - надо. И работать она должна на достаточно ограниченной "протяжённости маршрута". Да и ошибки можно обнаружить лучше и надёжнее, чем с локальной (относительно процедуры, содержащей цикл) переменной. |
Автор: | Info21 [ Вторник, 18 Июнь, 2019 03:33 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Да выкинуть этот FOR. |
Автор: | PSV100 [ Вторник, 18 Июнь, 2019 19:56 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Любопытное наблюдение. Если обратить внимание на материалы от Дмитрия Дагаева насчёт стандартов безопасности, то согласно требованиям этих стандартов необходимо наоборот -- выкинуть прочие формы циклов, кроме FOR (и, к слову, здешний раздел программирования "под доказательство" игнорирует этот факт). |
Автор: | PSV100 [ Вторник, 18 Июнь, 2019 19:57 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Цитата: но полный синтаксис FOR в Модуле-2 (rev.2010) сложнее (и, на мой взгляд, излишне наворочен и усложнен) В Модула-3, вроде бы, синтаксис FOR такой же, как и в Оберонах (тип переменной выводится автоматом). Однако, локальная область определения переменной цикла в данном случае вполне соответствует "духу" языка (поскольку возможны прочие локальные области в виде вложенных блоков "VAR ... BEGIN ... END" для поддержки "горячего определения переменных в коде", в т.ч. с возможностью вывода типа, но оставаясь в рамках "структуризации по-Паскалевски"). |
Автор: | Дмитрий Дагаев [ Вторник, 18 Июнь, 2019 20:14 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
PSV100 писал(а): Любопытное наблюдение. Если обратить внимание на материалы от Дмитрия Дагаева насчёт стандартов безопасности, то согласно требованиям этих стандартов необходимо наоборот -- выкинуть прочие формы циклов, кроме FOR (и, к слову, здешний раздел программирования "под доказательство" игнорирует этот факт). Если Оберон не сундук, а чемоданчик (а это так), то для выполнения специфических функций чемоданчику требуются специфические средства, различные в зависимости от контекста: - для того, чтобы гарантировать ограниченное число итераций цикла, нужно использовать FOR и исключить WHILE; - для того, чтобы на выходе получить инвариант цикла, нужно использовать WHILE и исключить FOR. |
Автор: | vvmtutby [ Среда, 19 Июнь, 2019 13:15 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
PSV100 писал(а): В Модула-3, вроде бы, синтаксис FOR такой же, как и в Оберонах (тип переменной выводится автоматом). Однако, локальная область определения переменной цикла в данном случае вполне соответствует "духу" языка (поскольку возможны прочие локальные области в виде вложенных блоков "VAR ... BEGIN ... END" для поддержки "горячего определения переменных в коде", в т.ч. с возможностью вывода типа, но оставаясь в рамках "структуризации по-Паскалевски"). Практика использования вышеупомянутого в Modula-3: caltech-parser\cit_util\src\SIsuffix.m3 Код: FOR i := FIRST(List) TO LAST(List) DO VAR x : BOOLEAN; BEGIN x := tbl.put(List[i].char, List[i]); <* ASSERT NOT x *> END END m3-libs\bitvector\test\src\TestBitVector.m3 Код: FOR i := 0 TO Max - 1 BY 7 DO
FOR j := 1 TO 6 DO VAR set := bv2.set(i+j); BEGIN <* ASSERT NOT set *> END END END; |
Автор: | PSV100 [ Четверг, 20 Июнь, 2019 19:43 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Дмитрий Дагаев писал(а): PSV100 писал(а): Любопытное наблюдение. Если обратить внимание на материалы от Дмитрия Дагаева насчёт стандартов безопасности, то согласно требованиям этих стандартов необходимо наоборот -- выкинуть прочие формы циклов, кроме FOR (и, к слову, здешний раздел программирования "под доказательство" игнорирует этот факт). Если Оберон не сундук, а чемоданчик (а это так), то для выполнения специфических функций чемоданчику требуются специфические средства, различные в зависимости от контекста: - для того, чтобы гарантировать ограниченное число итераций цикла, нужно использовать FOR и исключить WHILE; - для того, чтобы на выходе получить инвариант цикла, нужно использовать WHILE и исключить FOR. Вроде бы, в любом случае имеется единый контекст -- построить правильный алгоритм, и для любого цикла необходимо гарантировать и инвариант, и вариант (ограничивающую функцию). И в сундуке, то бишь в Адовском SPARK-е (как я понимаю, под "сундуком" скрывается Ada) их необходимо доказывать для всех форм циклов (используя при потребности специальные прагмы и атрибуты объектов), напр.: http://docs.adacore.com/spark2014-docs/html/lrm/statements.html#loop-invariants-variants-and-entry-values Код: procedure Loop_Var_Loop_Invar is
type Total is range 1 .. 100; subtype T is Total range 1 .. 10; I : T := 1; R : Total := 100; begin while I < 10 loop pragma Loop_Invariant (R >= 100 - 10 * I); pragma Loop_Variant (Increases => I, Decreases => R); R := R - I; I := I + 1; end loop; end Loop_Var_Loop_Invar; ... type Array_Of_Int is array (1 .. 10) of Integer; procedure Reverse_Order (A : in out Array_Of_Int) with Post => (for all J in A'Range => A (J) = A'Old (A'Last - J + 1) and A (A'Last - J + 1) = A'Old (J)) is Temp : Integer; begin for Index in A'First .. (A'Last + 1) / 2 loop Temp := A (Index); A (Index) := A (A'Last - Index + 1); A (A'Last - Index + 1) := Temp; pragma Loop_Invariant (-- Elements that have been visited so far are swapped (for all J in A'First .. Index => A (J) = A'Loop_Entry (A'Last - J + 1) and A (A'Last - J + 1) = A'Loop_Entry (J)) and then -- Elements not yet visited are unchanged (for all J in Index + 1 .. A'Last - Index => A (J) = A'Loop_Entry (J))); end loop; end Reverse_Order; |
Автор: | PSV100 [ Четверг, 20 Июнь, 2019 19:47 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Дмитрий Дагаев писал(а): - для того, чтобы гарантировать ограниченное число итераций цикла, нужно использовать FOR и исключить WHILE; Может быть для Вас тезис будет любопытным. Профиль Safety-Critical Java конкретику верификации не диктует. Напр., в JOP (Java Optimized Processor, некий академический вариант реализации профиля на FPGA) нет полной верификации, для границ циклов используется мета-аннотация вида @LoopBound(max = <значение>): https://github.com/jop-devel/jop/blob/master/java/target/src/test/wcet/mrtc/SimultaneousLinearEquations.java Код: public class SimultaneousLinearEquations { ... private static final int N = 5; private int[][] a; ... private void ludcmp(int nmax, int n) { int w; //@LoopBound(max=N) for (int i = 0; i < n; i++) // @WCA loop<=5 { //@LoopBound(max=N) // triangular loop vs. i for (int j = i + 1; j <= n; j++) // @WCA loop<=5 { w = a[j][i]; if (i != 0) { // sub-loop is conditional, done all iterations except first of the OUTER loop //@LoopBound(max=N) for (int k = 0; k < i; k++) // @WCA loop<=5 w -= a[j][k] * a[k][i]; } ... } ... Аннотация LoopBound нестандартная для Java, видимо, поэтому для совместимости декларируется в комментариях. Аннотация вида "@WCA loop<=5" мне по публикациям неизвестна (вероятно, что-то вроде Worst-case analysis). Кроме требований ограниченности итераций важна и непосредственно количественная оценка в каждом случае, поскольку в платформе применяется WCET (Worst-case execution time analysis) на основе байт-кода, а также и анализ WCMEM (Worst Case Memory consumption). Поэтому ввести некое универсальное неявное ограничение для всей платформы неприемлемо. Аннотация, вроде бы, для всех видов цикла. Для for в случае применения некоторых стандартных классов с известной анализатору семантикой их свойств возможно автоматическое определение предела (аннотация предполагает максимальное возможное количество итераций, условия в for задают границы для конкретного случая, а циклы могут исполняться многократно при повторных вызовов методов и т.п.), а-ля: Код: for (int j = 0; j < entries.length; j++)
|
Автор: | PSV100 [ Четверг, 20 Июнь, 2019 19:49 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Кстати, если FOR-цикл остаётся единственным управляющим средством с явными ограничениями итераций, то break/exit неизбежны в ряде случае. Для "чемоданчика" может быть окажется полезной полная форма for-цикла от Питона (здесь активно критикуемого) с секцией else, исполняемой, если не было break-выхода из "основного тела" цикла по его завершению. Что-то вроде а-ля: Код: FOR ... DO
... EXIT... ELSE ... END; |
Автор: | Oleg N. Cher [ Суббота, 17 Август, 2019 14:05 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
В Ofront'е+ сделан ещё один солидный шаг в сторону улучшения совместимости с Компонентным Паскалем: добавлена поддержка атрибутов NEW, ABSTRACT, LIMITED, EMPTY и EXTENSIBLE для записей и методов. Кода добавилось довольно много, но всё тщательно протестировано в меру моих скромных сил. Пожалуй, самое трудное, что осталось реализовать по КП — это поддержку двухбайтного символьного типа CHAR. Но может сподвигнусь и на эту большую работу. |
Автор: | Oleg N. Cher [ Воскресенье, 18 Август, 2019 09:50 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Здесь спрашивали про описание Оберона-3. Наконец-то дошли руки подготовить набросок, будет лежать здесь: У всех присутствующих есть реальная возможность повлиять на развитие Оберона-3 идеями и конструктивной критикой, на которую, впрочем, не обещаю реагировать. В любом случае, это экспериментальный диалект, так что мы оставляем за собой право изменять его в любую сторону. Поддержка совместимости с O7 и КП в Ofront'е+, напротив, будет только улучшаться. Напоминаю, что поддержка Ofront'а+ осуществляется в рокетчате и на форуме. Если будет больше двух желающих, можно создать группу в Телеграме. |
Автор: | Oleg N. Cher [ Четверг, 05 Сентябрь, 2019 02:41 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Сергей Оборотов успешно протестировал Ofront+ с Clang, в процессе чего мы внесли некоторые изменения в транслятор. Выражаю благодарность Сергею за его решение для лучшей поддержки приоритетов операций в Clang, более корректное, чем сделал Норайр Чилингарян в Vishap'е (код Норайра просто лепит лишние скобки, тогда как код Сергея ставит их действительно только там, где необходимо). У меня к вам вопрос, коллеги. Сам я хорошо воспринимаю ключевые слова Оберона в верхнем регистре, даже нахожу это очень выразительным. Но есть заинтересованные в использовании Оберона товарищи, которые очень хотят нижний регистр. Поскольку мы прорабатываем экспериментальный диалект, можно пойти навстречу людям, которые не хотят использовать Оберон только из-за верхнего регистра. Так вот. Ввести регистровую независимость как в Паскале или Аде видится шагом назад (просто не хочется мешанины, когда ident и — iDeNT одно и то же). Если же разрешить вместо верхнего регистра писать ключевые слова только в нижнем, то теряется совместимость, и вообще мы чего-то лишимся. Я слышал, что в Zonnon'е если модуль начинается с MODULE, то ключевые слова ожидаются в верхнем регистре, а если с module, то только в нижнем. Это очень интересное решение, но, к сожалению, не учитывает момент, когда программист, работая с ключевыми словами в нижнем регистре заведёт и экспортирует переменную с именем TYPE (или DO), а другой программист, работая с исходником в верхнем регистре, не сможет её использовать. Этого бы очень хотелось избежать. Как бы вы предложили поступить в этом случае? Можно так. Если модуль начинается не с MODULE, а с module, то ключевые слова можно писать и в нижнем регистре, и в верхнем. При этом BEGin или begIN мы, по-прежнему, не будем считать ключевым словом, а только идентификатором. Так уже неплохо, но ещё хотелось бы избежать смешивания ключевых слов в разных регистрах в одном модуле. Буду признателен за хорошие идеи. |
Автор: | Info21 [ Четверг, 05 Сентябрь, 2019 09:03 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Oleg N. Cher писал(а): есть заинтересованные в использовании Оберона товарищи, которые очень хотят нижний регистр. Не устаю удивляться.Правило №1 профилактики дурной сложности: По умолчанию DIVIDE. Отказ должен быть объективно обоснован. Наличие у товарищей таких идиосинкразий намекает на наличие и других особенностей. Сильно сомневаюсь, что ради таких товарищей следует отрывать ящик Пандорры. |
Автор: | Rifat [ Четверг, 05 Сентябрь, 2019 09:13 ] |
Заголовок сообщения: | Re: Ofront+: транслятор Оберон-языков в Си для ARM, x64 и x8 |
Info21 писал(а): ... Наличие у товарищей таких идиосинкразий намекает на наличие и других особенностей. Сильно сомневаюсь, что ради таких товарищей следует отрывать ящик Пандорры. Примерно тоже самое хотел написать: "дашь им палец, они и руку откусят". Сначала регистр ключевых слов, потом скобочки фигурные как в Си, потом макросы, темплейты, try catch, goto и пошло, поехало |
Страница 3 из 17 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |