OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 01 Октябрь, 2020 04:24

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 80 ]  На страницу Пред.  1, 2, 3, 4
Автор Сообщение
СообщениеДобавлено: Воскресенье, 06 Сентябрь, 2020 07:41 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8371
Откуда: Троицк, Москва
Название ETH Oberon на этом 86-страничном документе есть разновидность обмана, называемая "мимикрия".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Сентябрь, 2020 14:49 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 957
Ого, я вижу, что случайно задел за святое :shock:

В таком случае мотороллер не мой, поэтому в заголовке будет пока что написано что-то вроде


"Описание языка ETH Oberon (2019)"

Называть ли это Обероном или нет - дело совести авторов, а наше дело - перевести то, что есть.

В нашем документе, кстати, есть ряд небольших отличий от оригинала. Во-первых, пресловутая инициализация нулём (не помню, чем дело кончилось, но кажется, я написал, что она есть, хотя в оригинале её нет и она на самом деле присутствует только на Интелах, в ARM её можно выключить). Во-вторых, поддержка кириллицы в идентификаторах. В остальном мы старались перевести тот документ, который был, и намерения вводить кого-либо в заблуждение о содержании языка у нас не было, так что я надеюсь, что Фёдор Васильевич обвиняет в обмане не нас, а авторов документа.

Притом нужно отметить, что ЯОС отпочковался до того, как шаблоны модулей заработали, поэтому их придётся выпилить в качестве одного из действий. Тем не менее, перевести то, что есть, как оно есть, должно иметь смысл.

Как только в язык будет внесено существенное изменение (например, русские ключевые слова), название языка будет изменено на не содержащее слова "Оберон".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Сентябрь, 2020 17:19 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2831
Раз планируется менять язык, то здорово, что планируется его немного упростить ближе к парадигме Оберона :)
А так упрощать технически проще, чем расширять. Но придется делать рефакторинг каких-то мест в А2, наверное. Зато надёжность возрастёт.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Сентябрь, 2020 18:05 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 311
Там, конечно, есть, чего можно пубирать...

А вы не думали сделать "откат" к активным объектам Гуткнехта/Реали/Дистелли? Это 97 год, если мне не изменяет память. Оно было гораздо ближе к Оберону, гораздо проще, и, полагаю, доказуемей для безопасности и надежности. Вот взять бы концепцию активности объектов и трансформировать ее в духе КП:
* выкинуть понятие объекта как дублирующее понятие переменной-записи, записного типа вполне достаточно (или наборного, как вы предлагали);
* выкинуть Object scope как существенно усложняющий понимание написанных программ и не добавляющий ничего по существу;
* и сохранить понятие активного Object body, но синтаксически оформить его как атрибут типовой процедуры, слово body тоже на что-то заменить (при чем здесь тело?)

И будет минималистично, элегантно, и можно претендовать на новизну: проанализировали опыт, лишнее выкинули, оставшееся трансформировали для единообразия подходов. И все по-русски.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Сентябрь, 2020 20:00 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 483
Откуда: Москва
adimetrius писал(а):
Там, конечно, есть, чего можно пубирать...

А вы не думали сделать "откат" к активным объектам Гуткнехта/Реали/Дистелли? Это 97 год, если мне не изменяет память. Оно было гораздо ближе к Оберону, гораздо проще, и, полагаю, доказуемей для безопасности и надежности. Вот взять бы концепцию активности объектов и трансформировать ее в духе КП:
* выкинуть понятие объекта как дублирующее понятие переменной-записи, записного типа вполне достаточно (или наборного, как вы предлагали);
* выкинуть Object scope как существенно усложняющий понимание написанных программ и не добавляющий ничего по существу;
* и сохранить понятие активного Object body, но синтаксически оформить его как атрибут типовой процедуры, слово body тоже на что-то заменить (при чем здесь тело?)

И будет минималистично, элегантно, и можно претендовать на новизну: проанализировали опыт, лишнее выкинули, оставшееся трансформировали для единообразия подходов. И все по-русски.

Вот и я в точно таком же ключе думал.

В А2 ещё конструктор есть с параметрами, при этом об'ект после new регистрируется и начинает работать в системе как активный. И записи там не может быть, только указатель.

А вообще, в отдельную тему такие вещи надо переносить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 06 Сентябрь, 2020 22:46 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 957
Я за отдельную тему, единственное, что я не особо вникал в то, чем объект отличается от записи, поэтому у меня просто нет пока что точки зрения на это. В целом действительно кажется лишним выделять объект в отдельную сущность только из-за активности, а сделать тело процедурой - тоже кажется осмысленной идеей.

Насчёт области объекта я не совсем понял - предлагается методы писать отдельно, а не внутри скобок "OBJECT .. END"? ПМЛМ разница невелика и удобство/неудобство скорее зависит от IDE, чем от языка. Мне скорее кажется удобным размещение методов внутри OBJECT .. END, за той оговоркой, что вообще понятие о том, что "метод принадлежит объекту" - не единственная возможность. В CLOS отдельно существуют объекты, а отдельно - родовые функции, которые никому не принадлежат. Функционал определяется на пересечении родовой функции и типа объекта, т.е. нельзя сказать, что метод организационно вложен в объект. Самое главное, что этот метод может объявляться в совершенно другом месте, чем то место, где объект был определён. Правда, в CLOS нет и ограничения доступа к полям объекта, для которого, в общем-то и пригождается понятие о том, что "метод принадлежит объекту".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Сентябрь, 2020 08:50 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1396
Откуда: Украина, Киев
Иван Денисов писал(а):
Раз планируется менять язык, то здорово, что планируется его немного упростить ближе к парадигме Оберона :)
А так упрощать технически проще, чем расширять. Но придется делать рефакторинг каких-то мест в А2, наверное. Зато надёжность возрастёт.
Так Денис планирует вообще уйти и от синтаксиса Оберона :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Сентябрь, 2020 11:46 

Зарегистрирован: Понедельник, 07 Сентябрь, 2020 10:02
Сообщения: 1
Есть же отдельная тема посвященная ETH Oberon viewtopic.php?f=22&t=6446 зачем здесь разводить флуд?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Сентябрь, 2020 12:28 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 957
ETH оберон - это ЯП из A2. Конкретно данная тема уже потеряла всякое русло, её можно с тем же успехом назвать "на завалинке" и обсуждать что угодно. Но давайте обсуждать в любых темах - отвечайте, переносите и т.п.

Касаемо отказа от синтаксиса Оберона - пока об этом речи не идёт. Перевести важнее, чем улучшить синтаксис. Из того, что я на сегодня вижу важным - сделать, чтобы оператор в конце строки мог обходиться без точки с запятой, причём не факт, что это вообще в Обероне возможно. В js и голенге это возможно, но там правила не очень простые и теоретически наступить на грабли при большом старании есть как. Вторая часть - это ключевые слова в нижнем регистре. Третья - более питоновский стиль отступов, когда end-ы (в русском варианте "кн") ставят подряд в конце строки, т.е. не
Код:
   что-то();
   end
  end
end MyProc

а
Код:
   что-то()  кн кн кн MyProc

Я уже получил море отрицательных отзывов в телеграм-группе. Теперь я знаю, что не нужно закрывать и обфусцировать исходники - достаточно перевести их на русский, записать транслитом и поставить такие отступы. Никто никогда не прочитает, т.к. всех стошнит.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Сентябрь, 2020 12:55 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 1396
Откуда: Украина, Киев
budden писал(а):
т.к. всех стошнит.
Тошнотворный язык обсуждать на заваленке, - самое то.
Надо тошнотворность как-то отразить и в названии. Например "Активный тошнотворный Оберон"


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Сентябрь, 2020 13:02 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 957
Предлагаю тебе сделать форк и так его назвать. Для меня он называется "исправленный от тошнотворности не-оберон с встроенной обфускацией".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Сентябрь, 2020 13:05 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 156
Откуда: Russia
Цитата:
чтобы оператор в конце строки мог обходиться без точки с запятой, причём не факт, что это вообще в Обероне возможно
Активный Оберон вполне может жить без разделителя ";". Для этого есть режим "Lax". В общем-то именно такой режим применяется в интерпретаторе. Как говорится, "всё уже украдено до нас".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Сентябрь, 2020 13:12 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 957
Круто, не знал, что это за режим, рука даже поднялась его выпилить, но не помню, опустилась ли. Тут основной вопрос - не возникнет ли какой-нибудь бяки на границе с соседним оператором. В языках, где можно игнорировать возврат процедуры, можно так попробовать:
Код:
   а := b()
   -c();

За счёт нечёткости или незнания разработчиком правил переноса результат может отличаться от ожидаемого. Возможно, есть и другие примеры.

В моём понимании, замена точки с запятой на знак конца строки сделана хорошо, если для любого компилирующегося текста при случайном удалении или добавлении любого количества знаков конца строки между словами, смысл текста либо не изменяется, либо текст заведомо не скомпилируется.


Последний раз редактировалось budden Понедельник, 07 Сентябрь, 2020 13:19, всего редактировалось 3 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 07 Сентябрь, 2020 13:16 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 957
А вообще, если уж вспоминать мои мечты о замене синтаксиса, я мечтал сделать вызов процедуры как в тикле:
Код:
имя_процедуры арг1 арг2 <знак-конца-строки>

При наличии процедур с переменным числом аргументов на грабли наступить элементарно. Когда я изобретал Яр, я долго ломал над этим голову, но решения так и не родилось. Также напрашивается подобное решение для языков представления данных, и в нём есть то же слабое место.

Однако не использовать такое мощное выразительное средство, как конец строки, тоже в наше время выглядит немодным (и мне лично кажется, независимо от мнения моды, что конец строки нужно как-то использовать для выражения смысла).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Сентябрь, 2020 14:00 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 156
Откуда: Russia
Цитата:
выкинуть Object scope как существенно усложняющий понимание написанных программ и не добавляющий ничего по существу;
Чтобы быть честным, и оберонов нужно выкинуть и module scope, ,существенно услодняющий понимание и т.д и т.п Остальные предлодения в, том де самом русле, от непонимания.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Сентябрь, 2020 14:03 

Зарегистрирован: Пятница, 11 Январь, 2019 19:26
Сообщения: 156
Откуда: Russia
Иван Денисов писал(а):
Зато надёжность возрастёт.
От чего конкретно возрастет надёжность? Что же вас так напрягает?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Сентябрь, 2020 14:33 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2831
Sergej Durmanov писал(а):
Иван Денисов писал(а):
Зато надёжность возрастёт.
От чего конкретно возрастет надёжность? Что же вас так напрягает?
Это я прочувствовал идею, высказанную Денисом, что для информационной безопасности система должна быть прозрачная.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Сентябрь, 2020 14:36 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 957
Я не понял суть предложения, но если оно состоит именно в том, чтобы вынести методы за пределы RECORD .. END, то я, пожалуй, частично соглашусь с Сергеем, но не совсем. Например, есть вложенные процедуры. Удобно ли их читать? Вообще говоря, неудобно, если они большие, т.к. смотрим на текст и не понимаем, где мы находимся.

Надо ли их выкинуть? Ни в коем случае. А что надо сделать? Сделать надо "хлебные крошки", чтобы IDE показывала, где мы находимся. Если же используется концепция, что всё должно быть ясно без IDE, при чтении на бумаге или в простом текстовом редакторе, то тогда область, в к-рой определена процедура, должна быть как-то указана явно, т.е. как-то так:

Код:
PROCEDURE Внеш;

  PROCEDURE Внеш.Внутр;
  BEGIN
  END Внеш.Внутр;

BEGIN
END Внеш;


Последний раз редактировалось budden Вторник, 08 Сентябрь, 2020 14:40, всего редактировалось 4 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Сентябрь, 2020 14:37 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 957
Если просто выкинуть область действия объекта, но ничего не сделать для удобства работы со вложенными процедурами, то это будут слегка двойные стандарты.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 08 Сентябрь, 2020 14:45 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 957
С прозрачностью тут задача оптимизации, которая не имеет единого решения. Нужно убирать неопределённое поведение, а вот как оптимально представить текст? Если текст содержит слишком много понятий и сокращений, то при их ошибочной интерпретации читающим (при перегрузке его восприятия количеством этих понятий), ясность исчезнет.

Но если всё расписывать до буквы, то вроде локальная ясность будет, а весь объём текста целиком станет слишком большим. Исчезнут уровни абстракции. И высокоуровневая ясность опять же исчезнет. Когда программист что-то чинит, он не держит в голове всю систему. Ему нужно успевать её постигать хотя бы быстрее, чем он её забывает. Значит, язык представления системы должен быть достаточно компактным, чтобы программист мог эффективно постигать незнакомые куски. Если всё расписано до буквы и абстракции отсутствуют, эта работа может стать слишком тяжёлой и опять же привести к ошибкам.

Вот такая ось компромисса, оптимальная точка на которой зависит от многих факторов, в том числе от привычки и культуры.

Если упрощаем язык, то у нас уменьшается набор абстракций. Хорошие абстракции безопасно комбинируются. В качестве примера приведу перечисления. Вроде это усложнение, а с другой стороны, оно надёжнее, чем просто числовые константы. Но гибкость меньше. Везде нужно выбирать, как при инженерном проектировании, между противоречащими требованиями.

Я высказывал мысль, хотя не уверен, что её кто-то понял. Что сложность языка логарифмически зависит от сложности системы, которую этот язык должен описывать.

Поскольку можно рассматривать задачу описания системы как задачу архивации файла - чем больше файл, тем больше словарь для хранения повторяющихся образцов.

Т.е. если у нас система на 1000 строк, то нужен один язык. Если на миллион, то нужен уже другой, более развитый.

В этом отношении мне представляется, что A2 размером в миллион строк имеет язык как раз по росту.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 80 ]  На страницу Пред.  1, 2, 3, 4

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2020, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB