OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 03 Декабрь, 2021 12:24

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




Начать новую тему Ответить на тему  [ Сообщений: 272 ]  На страницу Пред.  1 ... 10, 11, 12, 13, 14  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 20 Август, 2021 11:43 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9447
Откуда: Россия, Орёл
Ну и в отношении ^ (разыменование указателя) уже есть пример от Вирта такой же необязательности.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 20 Август, 2021 12:42 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1375
Нет уж, не дикси. Подали мячик - принимайте теперь ответ. Я не понял, что Вы хотели сказать этими шпаргалками. Шпаргалки - для тех, кто уже знаком с темой. А для новичков это просто китайская грамота. Я единственное, что понял (если правильно) - это что точка смотрится чище, чем ; , поэтому и ставить её разделителем не так больно. Если так, то это здорово, но в тех языках, к которым относится оберон, точка отделяет член от организма, к которому этот член относится (гусары, молчать!). Но что такое

Код:
{ -42 . #($a #a #'I''m' 'a' 1.0 1.23e2 3.14s2 1) }

?

Предлагаю переместиться с этим обсуждением в тему про точки с запятой, потому что здесь тема про Ofront+, а необязательные точки с запятой, как выяснилось, сначала придумали в AO/A2, потом некий многомудрый швейцарец (забыл его имя) перенёс его в свой "oberon+", и только потом Олег это позаимствовал. Во всяком случае, мне так показалось по сумме того, что было сказано и найдено. Можно даже и правило в Го пытаться вывести из АО, но это больше похоже на натяжку пока что, тем более, что в Го правило другое.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 20 Август, 2021 17:58 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 185
Откуда: Питер
Следующая ошибка.

Эта программа, по идее, должна выводить на экран число 2, но не выводит ничего - какой-то тихий крэш? Если закомментировать вызов процедуры IncProc, то, как и одидается, на экран выводится число 0.

Код:
MODULE Ex;

IMPORT
  Console;

TYPE
  IncRec = EXTENSIBLE RECORD
  END;

  IncRec1 = RECORD ( IncRec )
  END;

VAR
  i:INTEGER;
  r:IncRec1;

PROCEDURE ( VAR r: IncRec ) Inc ( VAR i: INTEGER ), NEW, EXTENSIBLE;
  BEGIN
    i := i + 1
  END Inc;

PROCEDURE IncProc ( VAR r_param: IncRec; VAR i: INTEGER );
  VAR
    r: IncRec;
  BEGIN
    r := r_param;
    r.Inc ( i );
    r_param := r
  END IncProc;

PROCEDURE ( VAR r: IncRec1 ) Inc ( VAR i: INTEGER ), EXTENSIBLE;
  BEGIN
    i := i + 2
  END Inc;

BEGIN
  i := 0;
  IncProc ( r, i );
  Console.LongInt(i,0); Console.Flush;
END Ex.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 21 Август, 2021 00:04 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 185
Откуда: Питер
Пардон, ошибся, по идее, программа должна выводить на экран число 1 (но не выводит).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 21 Август, 2021 21:54 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 185
Откуда: Питер
Ещё одна ошибка.

Этот модуль успешно компилируется в BlackBox, а при компиляции oFront+'ом происходит ошибка со следующим сообщением: OfrontOPV 610:50 Terminated by Halt(-4). CASE statement: no matching label and no ELSE.

Код:
MODULE Ex;

TYPE
  Rec0 = EXTENSIBLE RECORD
  END;

  Rec1 = RECORD (Rec0)
    i:INTEGER;
  END;

PROCEDURE as_Rec1 (VAR r:Rec0): POINTER TO Rec1;
  BEGIN
    RETURN NIL
  END as_Rec1;

PROCEDURE Process (VAR r:Rec0);
  BEGIN
    as_Rec1(r)^.i:=0;
  END Process;

END Ex.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 22 Август, 2021 07:34 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
Подтверждаю: оба примера вызывают проблемы.

Первый пример вообще интересный. Вы пробовали компилировать его BlackBox'ом? Находит две ошибки, почему? Попробовал в самой свежей сборке Центра.

Изображение

А вот Ofront+ такое компилит, но сишный код несколько подозрительный. Разбираюсь дальше.


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
GameHunter, вуаля: убираем EXTENSIBLE и - о чудо - пример начинает компилиться. Знаете почему? Потому что две расширяемых записи, находящиеся в родстве, в КП не могут считаться совместимыми. Вдруг одна из них расширена. Тогда присваивание не имеет смысла.

Я помню этот момент, когда ещё добавлял в Ofront+ атрибуты записей и процедур. Но я сделал как в Обероне-2: тут могут, тут все записи расширяемые. А в КП не могут. Так что это не ошибка.

Т.е. в Ofront'е+ сейчас совместимость расширяемых записей проверяется в рантайме. И если присваивание имеет смысл, то оно происходит, а если не имеет - тогда будет трап. Ну как и в Обероне-2. И для КП я сделал так же. Возможно, здесь стоило бы сделать как в BlackBox'е.

Комментарии приветствуются.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Август, 2021 00:15 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 185
Откуда: Питер
В сообщении о компонентном паскале написано, что расширяемые записи не совместимы для присваивания. По этому надо просто на этапе компиляции выводить сообщение об ошибке, как это сделано в BB.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Август, 2021 00:23 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 185
Откуда: Питер
Следующая ошибка. Этм два модуля успешно транслируются в си, но результат при компилировании выдаёт ошибки.

Код:
MODULE Ex1;

TYPE
  Rec0 * = EXTENSIBLE RECORD
    y * : RECORD
    END;
  END;

END Ex1.


Код:
MODULE Ex;

IMPORT
  Ex1;

TYPE
  Rec1 * = RECORD ( Ex1.Rec0 )
  END;
  Rec2 * = RECORD ( Ex1.Rec0 )
  END;

END Ex.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Август, 2021 13:22 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
GameHunter, ого, Вы меня практически завалили. :? Буду разгребаться помаленьку.

GameHunter писал(а):
В сообщении о компонентном паскале написано, что расширяемые записи не совместимы для присваивания. По этому надо просто на этапе компиляции выводить сообщение об ошибке, как это сделано в BB.
Дело в том, что в Обероне и Обероне-2 (а заодно и в O7) все записи по умолчанию расширяемые. И они при этом совместимы для присваивания. Поэтому используются рантайм-проверки.

Кстати, в КП не решена проблема копирования расширяемых записей этим способом. Вы бы как предпочли копировать? Только поэлементно? Тут ведь приведение типа с охраной не сработает.

Или же надо вводить в транслятор новую сущность "особо злая и страшная расширяемая запись КП, которую ни-ни". Но надо ещё придумать как её потом стыковать с записями на других диалектах. Вот честно, не хочется заморачиваться.

P.S. GameHunter, что-то Вы, видимо, мутите хитрое - судя по коду. :o


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Август, 2021 17:28 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 185
Откуда: Питер
Я не упомянул, что использую при компилировании опцию -C, т.е. компонентный паскаль. А раз в сообщении о нём написано, что расширяемые записи нельзя друг другу присваисать, значит, так и должно быть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Август, 2021 11:54 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
По этой ошибке выяснилось:
GameHunter писал(а):
Эта программа, по идее, должна выводить на экран число 2, но не выводит ничего - какой-то тихий крэш?
Программа аварийно завершается по защите типа:

Изображение

Т.е. то, что BlackBox находит явно в процессе проверки синтаксиса, Ofront+ делает в рантайме.

Мне пришло в голову, что мы всё-таки можем сделать "как в BlackBox". Для чего я просто буду проверять текущий диалект, и если это КП, то генерить ошибку.

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

GameHunter, маленький хинт: если импортировать Kernel, то будет консольный вывод ошибок. А если нет, тогда только код возврата в ОС.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Август, 2021 12:49 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
Проверил в онлайн-Обероне-07, такое присваивание тоже компилится:

Изображение

Получается, что в диалектах, где все записи расширяемые без акцента на этом (потому что они могут быть и не расширены), такое присваивание проверяется в рантайме. А в КП специально ввели тег EXTENSIВLE, чтобы ограничить использование записей, в т.ч. и по присваиванию.

Я предлагаю вот такую правку, реализующую поведение в режиме -C согласно описания языка, для остальных же режимов будет проверка в рантайме. Если этого недостаточно, дайте знать.

Изображение

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Август, 2021 13:40 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
По второй проблеме (слева Online Oberon-07, справа Ofront 1.4 for BlackBox):

Изображение

Как видим, данный случай мог бы быть обработан в этих трансляторах, но он всё равно не реализован.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Август, 2021 16:17 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
Влад Фольц утверждает, что описание языка Oberon-07/16 прямо запрещает такое использование вызова:
Vlad Folts писал(а):
Это грамматика такая. Точнее там неоднозначность с охраной типа, поэтому оно проверяется не на уровне синтаксиса, а уже при проверке семантики. Т.е. репорт явно запрещает такую конструкцию.

Тогда вопрос: разрешить только для КП, запретив для остальных диалектов?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Август, 2021 16:49 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
По третьей проблеме советуюсь с Йозефом Темплом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Август, 2021 18:30 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 185
Откуда: Питер
Как мне кажется, раз вы реализуете (среди прочего) компонентный паскаль, по спорным вопросам надо просто обращаться к сообщению о нём. Соответственно, - да, проверка на присваивание в рантайме.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Август, 2021 18:31 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 185
Откуда: Питер
Тьфу, опечатался. Правильно - соответственно, проверка на присваивание во время компиляции.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Август, 2021 15:20 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
Закрыл вторую проблему:


Сейчас разыменование результата процедуры разрешено в диалектах КП и O3.

Побочным эффектом добавил в O3 косвенный вызов процедуры вида:
Код:
MODULE Test;

TYPE Proc = PROCEDURE;

PROCEDURE proc; END proc;

PROCEDURE getProc(): Proc;
  BEGIN RETURN proc
END getProc;

BEGIN
    getProc()(); (* OK in Eberon, error in original oberon *)
END Test.
Как у Влада реализовано в Eberon. Как оказалось, OP2 синтаксически поддерживает эту конструкцию, только надо было поправить один вызов (OPV.design на expr, кто в теме).

Для желающих поспорить подчеркну: такой вызов реализован только в экспериментальном диалекте O3.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 29 Август, 2021 13:54 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 462
Откуда: Украина, Днепропетровская обл.
По третьей проблеме: оказывается, она не решена и в CPfront. Йозеф сейчас поддерживает Ofront не шибко оперативно, это может затянуться. Так что, я думаю, нам есть смысл подключить Дмитрия Викторовича Дагаева, если у него есть интерес закрыть эту ошибку в МультиОбероне.

GameHunter, когда уже явите миру свой супер-проект на Обероне? :) Для которого нужен такой хитрый код с вложенными записями. В исходниках BlackBox, которые я пересобирал CPfront'ом полностью, такого кода нет. Иначе бы эта проблема вскрылась раньше.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 272 ]  На страницу Пред.  1 ... 10, 11, 12, 13, 14  След.

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


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

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


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

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