Автор Тема: Модифицированный синтаксис Оберона  (Прочитано 180416 раз)

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #465 : Декабрь 01, 2012, 08:19:01 pm »
Цитировать
Оберон не является достаточно высокоуровневым языком, где можно было бы писать компактно (скажем попробуйте ка в Обероне инициализировать массив константами - придется нарисовать 100500 присваиваний вместо одного присваивания как в других яызках).
Как решить вопрос?
Странно все это слушать. Есть же простой и универсальный (хотя и неказистый) способ конструирования любых значений средствами яыка. Через сторки.
Как-то так:
a := StringToMatrixOfInteger(
"[[1, 0, 0]," +
 "[0, 1, 0]," +
 "[0, 0, 1]]", 3, 3)
Конечно, инициализация происходит при загрузке, а не при компиляции.
А зачем еще в язык введены строки, как не для обработки текста программ?

За такое надо расстреливать без права воскрешения.
Y = λf.(λx.f (x x)) (λx.f (x x))

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #466 : Декабрь 01, 2012, 09:02:29 pm »
За такое надо расстреливать без права воскрешения.
А что я, я то что, я ничего. Вы на разработчиков ББ посмотрите, в модуле Strings они числа в строки и строки в числа гоняют процедурами IntToString, IntToStringForm, RealToString, RealToStringForm, StringToInt, StringToLInt, StringToReal. Это все они!

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

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #467 : Декабрь 01, 2012, 09:07:27 pm »
За такое надо расстреливать без права воскрешения.
А что я, я то что, я ничего. Вы на разработчиков ББ посмотрите, в модуле Strings они числа в строки и строки в числа гоняют процедурами IntToString, IntToStringForm, RealToString, RealToStringForm, StringToInt, StringToLInt, StringToReal. Это все они!

Я вот думаю, может вообще от числовых литералов избавиться, какие-то они не такие. И получать их конвертацией строк при компиляции. Будут одни строки.
Нет, лучше избавиться от строк, как-то они выбиваются из концепции, и путь будут одни числа (но не такие как сейчас) и литеры.
Я все же предпочитаю получить ошибку на этапе компиляции, а не на этапе работы приложения.
Y = λf.(λx.f (x x)) (λx.f (x x))

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #468 : Декабрь 01, 2012, 11:31:11 pm »
Я все же предпочитаю получить ошибку на этапе компиляции, а не на этапе работы приложения.
"Константы"-переменные все равно будут инициироваться при загрузке модуля, и результат их вычисления (включая ошибку) не будет зависеть от окружения, если их вычисление не опирается на импортируемые сущности. Достаточно одной проверочной загрузки модуля, чтобы обнаружить ошибку (модуль не загрузится).

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

Правда в ББ мне не удается прокомпилировать модуль с выражением для константы, содержащим импортируемый операнд из несуществующиего модуля. А как же раздельная компиляция?
MODULE mmm;
IMPORT nnn(*symbol file of imported module not found*);
CONST a = nnn.a;
BEGIN
END mmm.
« Последнее редактирование: Декабрь 01, 2012, 11:33:47 pm от ddn »

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #469 : Декабрь 01, 2012, 11:39:52 pm »
Я все же предпочитаю получить ошибку на этапе компиляции, а не на этапе работы приложения.
"Константы"-переменные все равно будут инициироваться при загрузке модуля, и результат их вычисления (включая ошибку) не будет зависеть от окружения, если их вычисление не опирается на импортируемые сущности. Достаточно одной проверочной загрузки модуля, чтобы обнаружить ошибку (модуль не загрузится).
Стоп. Какие такие "константы"-переменные применительно к Оберону? Они целиком и полностью известны на этапе компиляции.
Y = λf.(λx.f (x x)) (λx.f (x x))

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #470 : Декабрь 01, 2012, 11:44:39 pm »
Стоп. Какие такие "константы"-переменные применительно к Оберону? Они целиком и полностью известны на этапе компиляции.
Это переменные, которые имитируют константы - инициируются при загрузке модуля и в дальнейшем не изменяют свое значение.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #471 : Декабрь 01, 2012, 11:50:31 pm »
Стоп. Какие такие "константы"-переменные применительно к Оберону? Они целиком и полностью известны на этапе компиляции.
Это переменные, которые имитируют константы - инициируются при загрузке модуля и в дальнейшем не изменяют свое значение.
Эмм.. А кто гарантирует что они действительно не будут изменяться?
Y = λf.(λx.f (x x)) (λx.f (x x))

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #472 : Декабрь 01, 2012, 11:55:45 pm »
Эмм.. А кто гарантирует что они действительно не будут изменяться?
Естественно, что программист, а кто еще? По крайней мере, можно ограничиться программистом модуля этой переменной, если он поставит ей метку экспорта только для чтения.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #473 : Декабрь 02, 2012, 12:08:08 am »
Эмм.. А кто гарантирует что они действительно не будут изменяться?
Естественно, что программист, а кто еще? По крайней мере, можно ограничиться программистом модуля этой переменной, если он поставит ей метку экспорта только для чтения.
Ну, э... Например компилятор. В других языках такое возможно.

Кстати. в Обероне вроде как нельзя переменные экспортировать не в read-only.
Y = λf.(λx.f (x x)) (λx.f (x x))

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #474 : Декабрь 02, 2012, 03:12:31 am »
Что-то я сбился с фокуса дискуссии.

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

Я возразил: существующими средствами языка создание структурных фиксированных значений возможно почти также кратко и наглядно, как и через конструкторы. Оно возможно через строки. Строка - самый компактный конструктор, потому что лексический.
Конструктор-выражение отображаемое одной такой строкой не должно использовать имена полей (в конструкторах записей), идентификаторы и операции, а только лишь литеральные константы и подконструкторы - тогда значение выражения фиксированно его текстовым представлением. Впрочем, можно еще использовать предопределенные идентификаторы констант, функций и операций, т.к. возможно автономное распознание их значений.

Да, проверка внутренности этих строк на синтакис и допустимость значений невозможна при компиляции, как это имеет место для конструкторов. Но если нужно получить фиксированное (текстом строки) структурное значение, то проверка корректности задающей его константной строки возможна уже при загрузке, если проверка идет в теле модуля.

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

Когда же я говорил об избавлении от числовых литералов и о выражении чисел через строки, это уже другая тема. Я имел ввиду изменение языка, когда преобразующие функции "строка в число" становятся предопределенными, и значит могут использоваться в константных выражениях.

Ну, э... Например компилятор. В других языках такое возможно.
Если нам нужно не просто компактное и наглядное получение фиксированных структурных значений, а именно создание константных структурных значений и введение структурных констант, да, в Оберонах это невозможно.
Если мы хотим, чтобы значения структурных объектов проверялись на фиксированность (постоянство) компилятором или хотя бы при загрузке, мы должны сделать идентификаторы этих объектов константами. А выражения для структурных значений этих констант должны использовать конструкторы структурных значений или предопределенные функции со структурными значениями.

Язык здесь требует расширения - конструкторами или преобразующими предопределенными функциями.
В варианте с преобразующими функциями, компактнее всего использовать строки.

Кстати. в Обероне вроде как нельзя переменные экспортировать не в read-only.
Я работаю только с КП в ББ, там можно.

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #475 : Декабрь 02, 2012, 05:00:20 am »
Ввести возможность инициализации, как это сделано в Активном Обероне, хотя Модула-3 в этом плане мне нравится больше
В Сириусе идеи для модификации Оберона взяты с них?
Да

igor

  • Sr. Member
  • ****
  • Сообщений: 438
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #476 : Декабрь 02, 2012, 07:12:41 am »
Правда в ББ мне не удается прокомпилировать модуль с выражением для константы, содержащим импортируемый операнд из несуществующиего модуля. А как же раздельная компиляция?
MODULE mmm;
IMPORT nnn(*symbol file of imported module not found*);
CONST a = nnn.a;
BEGIN
END mmm.
Похоже, что Вы путаете раздельную компиляцию с независимой компиляцией. Для раздельной компиляции по определению нужны символьные файлы всех импортируемых модулей. При желании об этом можно почитать у Н.Вирта "Построение компиляторов", гл. 15.

DIzer

  • Гость
Re: Модифицированный синтаксис Оберона
« Ответ #477 : Декабрь 02, 2012, 10:47:31 am »
Что-то я сбился с фокуса дискуссии.

Утверждалось, что присвоение переменным фиксированных структурных значений слишком громоздское и ненаглядное по сравнению с конструкторами, которых в языке нет. А инициализация структурных констант вообще невозможна.
.....
Никто этого не утверждал.. я лично говорил о том,  что не очень хорошо выглядит ПОЛНОЦЕННЫЙ кортеж , и не всегда возможна ПОЛНОЦЕННАЯ (с точки зрения приложения) инициализация переменных ПЕРЕД выполнением программы (подпрограммы) в секции VAR..

ddn

  • Jr. Member
  • **
  • Сообщений: 59
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #478 : Декабрь 02, 2012, 11:58:50 pm »
Похоже, что Вы путаете раздельную компиляцию с независимой компиляцией. Для раздельной компиляции по определению нужны символьные файлы всех импортируемых модулей. При желании об этом можно почитать у Н.Вирта "Построение компиляторов", гл. 15.
А мне почему-то казалось, что символьные файлы импортируемых модулей нужны только при загрузке, и что при компиляции импортируемые идентификаторы воспринимаются полностью абстрактно (типо промежуточное КС-представление модуля). А подлинная (JIT-) компиляция с проверкой типов идет только при загрузке. Теперь понятно. Никакого абстрактного промежуточного представления нет, сразу бинарный код.

Значит случай с константами вычисляемыми при загрузке отпадает. Так даже лучше.
Раз импортируемые константные операнды, входящие в выражение инициирующее местную константу, известны при компиляции, то значение самой местной константы будет при компиляции известно, проверено на корректность (ее выражение) и вычислено.

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

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

Вообще проблема конструкторов в том, что в паскаль-семействе языков эквивалентность типов не структурная. Поэтому конструкторы-выражения в силу их предопределенности не должны иметь типа, иначе их было бы невозможно присвоить объектам с типом введенным пользователем. Но в этом случае, в конструктор-выражениях нельзя будет использовать любые идентификаторы (они типизированы), а только лишь литеральные константы (числа, литеры, строки). Это очень сильное ограничение.

А в случае структурной эквивалентности типов пришлось бы делать все возможные типы предопределенными.

igor

  • Sr. Member
  • ****
  • Сообщений: 438
    • Просмотр профиля
Re: Модифицированный синтаксис Оберона
« Ответ #479 : Декабрь 03, 2012, 03:11:37 am »
А мне почему-то казалось, что символьные файлы импортируемых модулей нужны только при загрузке, ...
При компиляции символьные файлы нужны для статической проверки типов.

Значит случай с константами вычисляемыми при загрузке отпадает. Так даже лучше.
Раз импортируемые константные операнды, входящие в выражение инициирующее местную константу, известны при компиляции, то значение самой местной константы будет при компиляции известно, проверено на корректность (ее выражение) и вычислено.

Так что значения аналогичных структурных констант (по факту представляемых переменными) также будут быть известны при компиляции (ибо не зависят от глобальных переменных и импортированных процедур), хотя проверяться на корректность (их выражения) и вычисляться они могут при загрузке (если инициируются в теле модуля), так как их выражения используют непредопределенные преобразующие функции.
При загрузке модуля никакие константы не вычисляются. В процессе компиляции производится свёртка констант, так что в объектном модуле (который и подлежит загрузке) никаких константных выражений уже нет. К тому же, память выделяется только под строковые константы (я про Оберон), а остальные константы компилятор размещает в регистрах проца (по месту использования). Таким образом, при загрузке инициализируются только строковые константы. Они по сути реализуются как переменные только для чтения. Остальные объявленные в модуле константы по факту (т.е. в процессе выполнения) используются как непосредственные константы. Это, кстати, одна из причин, почему в общем случае невозможно однозначно диззассемблировать машинные коды.