OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 19:40

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




Начать новую тему Ответить на тему  [ Сообщений: 332 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 17  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 05 Сентябрь, 2019 15:57 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Oleg N. Cher писал(а):
Буду признателен за хорошие идеи.
Можно, конечно, думать и предлагать, но перед этим интересно узнать про предыдущий опыт. Иван делал сборку ББ с возможностью писать ключевые слова строчными буквами. Насколько востребована эта возможность?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Сентябрь, 2019 16:03 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Info21 писал(а):
Наличие у товарищей таких идиосинкразий намекает на наличие и других особенностей.
Ещё, лягушку можно варить постепенно. Правда, непонятно, кто кого сварит в конце концов :lol: .


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 520
Откуда: Украина, Днепропетровская обл.
Comdiv писал(а):
Можно, конечно, думать и предлагать, но перед этим интересно узнать про предыдущий опыт. Иван делал сборку ББ с возможностью писать ключевые слова строчными буквами. Насколько востребована эта возможность?
Да. Иван, а ты как-то решил проблему запрета на использования идентов DO или TYPE при работе в нижнем регистре?


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Oleg N. Cher писал(а):
Comdiv писал(а):
Можно, конечно, думать и предлагать, но перед этим интересно узнать про предыдущий опыт. Иван делал сборку ББ с возможностью писать ключевые слова строчными буквами. Насколько востребована эта возможность?
Да. Иван, а ты как-то решил проблему запрета на использования идентов DO или TYPE при работе в нижнем регистре?

Там это автоматически решается тем, что они считаются ключевыми словами и проводят к ошибке компиляции. Так что приходится их переименовать. У Trurl, к слову, более элегантное решение для программирования ключевыми словами в нижнем регистре.


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 520
Откуда: Украина, Днепропетровская обл.
Протестировал решение Трурля на таком модуле:
Код:
module DO; end DO.
Оно тоже не решает проблему идентов в верхнем регистре, совпадающих с ключевыми словами.

Здесь может даже регистровая нечувствительность была бы лучше? По крайней мере, тогда бы такие иденты запрещались, приравниваясь к ключевым словам. Хотя бардака типа:
Код:
fOR i := 1 To 10 bY 2 do .. eNd;
конечно же не хочется...


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

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Oleg N. Cher писал(а):
Протестировал решение Трурля на таком модуле:
Код:
module DO; end DO.
Оно тоже не решает проблему идентов в верхнем регистре, совпадающих с ключевыми словами.

Здесь может даже регистровая нечувствительность была бы лучше? По крайней мере, тогда бы такие иденты запрещались, приравниваясь к ключевым словам. Хотя бардака типа:
Код:
fOR i := 1 To 10 bY 2 do .. eNd;
конечно же не хочется...

Не должно быть таких идентификаторов в программе, которые совпадают с ключевыми словами. Не понимаю в чем проблема, Олег...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 07 Сентябрь, 2019 18:42 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Иван, есть какие-то данные о востребованности прописных ключевых слов?


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 520
Откуда: Украина, Днепропетровская обл.
Иван Денисов писал(а):
Не должно быть таких идентификаторов в программе, которые совпадают с ключевыми словами.
Не должно быть логически, ибо это программеру не надо? Или не должно быть вообще и запрещено директивно транслятором?

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


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 520
Откуда: Украина, Днепропетровская обл.
Всё-таки реализовал в Обероне-3 лоукейс. Теперь программисты смогут потешить свою лоукейсную жажду. При работе в нижнем регистре иденты, совпадающие с ключ. словами в верхнем, запрещены. SYSTEM по-прежнему остаётся капсом, но это я ещё обдумываю.


Также начал работу над реализацией беззнакового типа UBYTE. Из двух соображений: совместимость с GPCP и улучшение поддержки разработки для слабых таргетов. Есть и третье соображение: в Обероне-07 тип BYTE беззнаковый, так что всё равно нужно сделать.

Тип UBYTE уже можно тестировать.



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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Ну, например, type или module используются повсеместно как имена переменных, полей и т.п.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Сентябрь, 2019 18:50 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Oleg N. Cher писал(а):
Ввести регистровую независимость как в Паскале или Аде видится шагом назад (просто не хочется мешанины, когда ident и — iDeNT одно и то же)

И наоборот -- Паскаль, Ада (а также SQL и некоторые др.) могут и уменьшать мешанину -- например, одновременное содержание переменных "ident" и "Ident" (или "iDent" и т.д.) в одной области определения/видимости может свидетельствовать о наличии некоторой потенциальной прикладной ошибки, и Паскаль-стиль не позволит завести подобные идентификаторы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Сентябрь, 2019 18:56 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 473
Oleg N. Cher писал(а):
Я слышал, что в Zonnon'е если модуль начинается с MODULE, то ключевые слова ожидаются в верхнем регистре, а если с module, то только в нижнем. Это очень интересное решение, но, к сожалению, не учитывает момент, когда программист, работая с ключевыми словами в нижнем регистре заведёт и экспортирует переменную с именем TYPE (или DO), а другой программист, работая с исходником в верхнем регистре, не сможет её использовать. Этого бы очень хотелось избежать. Как бы вы предложили поступить в этом случае?

Oleg N. Cher писал(а):
Протестировал решение Трурля на таком модуле:
Код:
module DO; end DO.
Оно тоже не решает проблему идентов в верхнем регистре, совпадающих с ключевыми словами.

Здесь может даже регистровая нечувствительность была бы лучше? По крайней мере, тогда бы такие иденты запрещались, приравниваясь к ключевым словам. Хотя бардака типа:
Код:
fOR i := 1 To 10 bY 2 do .. eNd;
конечно же не хочется...


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

Например. Пусть ключевые слова задаются только в верхнем или нижнем регистре в зависимости от MODULE/module в начале.
Буквы идентификаторов должны быть в одном и том же регистре, т.е. нельзя одновременно определить (в одной области), к примеру, "ident" и "Ident" или "iDent" и т.д.
При совпадении набора букв в идентификаторе и ключевого слова хотя бы одна буква в идентификаторе должна быть в ином регистре. К примеру, допустимы "do" или "Do" (и "dO") при наличии ключевого слова "DO".

Ключевое (и, возможно, самое проблемное) -- необходимо разделить пространство имён -- на имена типов и все прочие имена, где две области имеют свою уникальность (по аналогии с рядом функциональных языков, и, вроде бы, в Паскаль-подобном языке такое размежевание потенциально осуществимо). Тогда имеется возможность иметь идентичные имена в типах и переменных/параметрах/константах (а также и процедурах), напр.:
Код:
var date: date;
(* или:
var date: Date; *)

При этом нельзя одновременно определить в одной области переменные как "var date: ..." и, напр., "var Date: ...". И не могут быть одновременно два типа, напр., как "type date = ..." и "type Date = ...".

На границе модулей экспортируемый интерфейс адаптируется для импортирующего модуля. Для последнего экспортируемые имена являются условно регистронезависимыми, но допускается только один вариант применения регистра в идентификаторе.
Например:
Код:
(* Модуль с ключевыми словами в верхнем регистре, экспортирующий
   тип и переменную *)
MODULE M1;
TYPE Do* = ...;
VAR do*: Do;
...
END M1.

(* Модуль с ключевыми словами в нижнем регистре, импортирующий
   элементы из M1 *)
module M2;
import M1;

(* Использование импортированного типа. Идентификатор "Do" может быть в любом регистре,
 напр. и как "DO" и пр., но допустим только один вариант применения: *)
var d1: M1.Do;
var d2: M1.Do;
(* var d2: M1.DO; -- ошибка, т.к. в модуле уже используется вариант M1.Do *)

(* Применение импортированной переменной. Аналогично, регистр идентификатора "do"
   может быть любым, но в единственном варианте: *)
...
begin
  d1 := M1.do;
  d2 := M1.do;
  ...
end;
...
end M2.

В импортирующем модуле в случае квалифицированных имён (как "модуль.идентификатор") регистр идентификатора может быть любым (но в единственном варианте). Если гипотетически в языке возможен и доступ без квалификации, то требуется использовать вариант регистра идентификатора, отличающийся от ключевого слова:
Код:
MODULE M1;
TYPE Do* = ...;
VAR do*: Do;
...
END M1.

module M2;
import M1;

(* использование типа M1.Do: *)
var d1: DO;
var d2: DO;

(* использование переменной M1.do: *)
...
begin
  d1 := Do;
  d2 := Do;
  ...
end;
...
end M2.

Возможна и некая расширенная форма директивы а-ля import в стиле:
Код:
(* импортируется переменная и тип с указанием варианта имени
   для каждого идентификатора: *)
import M1(Do, type DO);

Не в курсе, возможна ли подобная схема для Оберон-экспериментов (у себя ранее рассматривалась схожая проблематика, но не для Оберонов).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Сентябрь, 2019 21:46 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 520
Откуда: Украина, Днепропетровская обл.
Знаете, PSV100, тогда уж лучше вообще ничего не трогать, пусть будет как есть)
Технически впилить регистровую независимость будет сложнее, чем то, что сделано сейчас. Так стоит ли?

Илья Ермаков писал(а):
Ну, например, type или module используются повсеместно как имена переменных, полей и т.п.
Тут мы пойдём по пути ущемления любителей нижнего регистра, они просто не смогут использовать такие идентификаторы. Пущай присматриваются к правильному, верхнему ;-)

PSV100 писал(а):
И наоборот -- Паскаль, Ада (а также SQL и некоторые др.) могут и уменьшать мешанину -- например, одновременное содержание переменных "ident" и "Ident" (или "iDent" и т.д.) в одной области определения/видимости может свидетельствовать о наличии некоторой потенциальной прикладной ошибки, и Паскаль-стиль не позволит завести подобные идентификаторы.
Ну а мне нравится практика иметь переменную type типа Type. При наличии в языке ключевого слова TYPE. И не нравится бардак типа fOR i:=0 tO 10 bY 2 Do


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

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



Вложения:
Master.png
Master.png [ 23.04 КБ | Просмотров: 5390 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 30 Сентябрь, 2019 23:23 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Вот тестовый модуль:

Код:
MODULE Test;

VAR
  i:LONGINT;
  x:SHORTREAL;

BEGIN
  x:=i;
  x:=1.0;
  x:=1.0+i;
END Test.


Ofront+ (в режиме компонентного пвскаля с ключом -C) в предпоследней строчке выдаёт ошибку: 10:11 err 113 incompatible assignment

Oleg N. Cher, помните, я вас убедил, что вещественные константы быть нетиптзированными, и должны присваиываться и переменным типа REAL, и переменным типа SHORTREAL, при этом без потери точности. Это, конечно, должно выполняться не только для простых присваиваний, но и для выражений.

С уважением,
GH.


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 520
Откуда: Украина, Днепропетровская обл.
А Вы бы, GameHunter, для начала проверили тот же самый код в BlackBox и увидели бы, что он выдаёт ту же ошибку несовместимого присваивания. Помните, Вы меня убеждали, что вещественные константы должны по умолчанию иметь самую высокую точность? Ну так вот, это оно и есть. :D

В Компонентном Паскале для присваивания REAL => SHORTREAL используется SHORT(). Разумеется, для константных выражений это смягчено. А для неконстантных — нет.

Юзайте так:
Код:
x:=SHORT(1.0)+i;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Октябрь, 2019 05:00 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Да, ваша правда, в сообщении о языке написано:
A real number is always of type REAL.
Что ж, пусть будет так, хотя это и неудобно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Октябрь, 2019 12:41 
Аватара пользователя

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 520
Откуда: Украина, Днепропетровская обл.
В КП так сделали, чтобы избавиться от E и D при описании вещ. чисел в экспоненциальном виде, как это было в Обероне-2. Сочли D для двойной точности излишеством. Кстати, в Обероне-2 короткий вещественный тип имеет преимущество при вычислениях, поэтому константы в экспоненциальном виде с E и константы в неэкспоненциальном виде описывают короткие числа. А на длинные выходят только по необходимости, используя D. Сказывается то, что работали на старых машинах, где двойная точность была ёмче. Сейчас в архитектуре x64 сопроцессор всё перемалывает в 80-битном виде, так что разница только в выводе из сопроцессора и хранении. Получается, язык подтянулся за архитектурой.

Я долго думал, как поступить в Обероне-3 с этим. В конце концов, тоже счёл, что SHORT(1.0) это неудобно, и сделал как в Обероне-2: префиксы E и D, вещ. числа в неэкспоненциальном виде короткие, вещ. вычисления по умолчанию короткие, удлинять нужно явно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 01 Октябрь, 2019 16:51 

Зарегистрирован: Вторник, 22 Май, 2007 15:38
Сообщения: 220
Откуда: Питер
Вот такой тестовый модуль:
Код:
MODULE Test;

TYPE
  Arr = ARRAY 3,4 OF REAL;

PROCEDURE Do1 (): POINTER TO Arr;
  BEGIN
    RETURN NIL
  END Do1;

END Test.

Он компилируется без ошибок, но .c-файла на выходе почему-то нет.
(В ББ этот модуль тоже компилируется).
Если Arr = INTEGER и процедура возвращает 0, c-файл появляется, и всё работает как должно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Октябрь, 2019 14:15 
Аватара пользователя

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

Если интересны подробности, то оригинальный Ofront не разрешает задать результатом процедуры POINTER TO ..., пишет такую ошибку:
Код:
PROCEDURE Do1 (): {identifier expected} POINTER TO Arr;


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

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


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

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


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

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