Автор Тема: Oberon-07/13: заметки  (Прочитано 83489 раз)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #45 : Февраль 04, 2014, 04:22:50 pm »
Вообще-то компилятор должен сообщать о непроинициализированных переменных...

1. По репорту - не должен.
2. Это усложнение.
3. Это не всегда возможно, собенно если учесть возможность передачи переменной по ссылке вообще в другой модуль.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #46 : Февраль 04, 2014, 04:27:54 pm »
Какие именно ошибки провоцирует VAR-секция?

И в довесок - надо делать диагностику неиспользуемых переменных. Потому как секция VAR провоцирует их появление в процессе эволюции кода.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #47 : Февраль 04, 2014, 05:53:01 pm »
Какие именно ошибки провоцирует VAR-секция?

И в довесок - надо делать диагностику неиспользуемых переменных. Потому как секция VAR провоцирует их появление в процессе эволюции кода.
Ну, справедливости ради, это надо делать вне зависимости от наличия VAR-секции.

+ нужно делать анализ неиспользуемых импортов.
Y = λf.(λx.f (x x)) (λx.f (x x))

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #48 : Февраль 04, 2014, 09:14:10 pm »
Ну, справедливости ради, это надо делать вне зависимости от наличия VAR-секции.

В случае объявление-есть-инициализация получить неиспользуемую переменную довольно сложно (если конечно не заниматься эмулированием VAR объявляя/присваивая все переменные в начале процедуры).

Все-таки хочется держать сложные проверки по минимуму (или отдельной примочкой) в свете желания иметь компиляцию на лету на вебе.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #49 : Февраль 04, 2014, 09:51:35 pm »
Ну, справедливости ради, это надо делать вне зависимости от наличия VAR-секции.

В случае объявление-есть-инициализация получить неиспользуемую переменную довольно сложно (если конечно не заниматься эмулированием VAR объявляя/присваивая все переменные в начале процедуры).

Все-таки хочется держать сложные проверки по минимуму (или отдельной примочкой) в свете желания иметь компиляцию на лету на вебе.
Эти проверки - штука ОЧЕНЬ легкая относительно всего остального. Даст замедление в 0.001% :-)
Y = λf.(λx.f (x x)) (λx.f (x x))

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #50 : Февраль 04, 2014, 11:28:04 pm »
Эти проверки - штука ОЧЕНЬ легкая относительно всего остального. Даст замедление в 0.001% :-)

Конкретно касательно oberon -> js - проверки это 99% :) И 1% - генерация кода.

adva

  • Sr. Member
  • ****
  • Сообщений: 385
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #51 : Февраль 05, 2014, 12:23:03 am »
Возникла такая мысля (наверняка не новая):

Для оберона вполне можно реализовать не только синтаксическую проверку (исходя из следующих предпосылок):
1) для всех условий используются только переменные простых типов (сравнение с ними). Если есть обращение к другим модулям, то считается что они корректны (для обозначения этого можно какой-то АССЕРТ придумать)
2) везде где нужно прописываются АССЕРТЫ (именно на них и ориентировалась бы проверка). Это, пожалуй, самая сложная часть для программиста, но без нее похоже проверки не сделать.
3) под проверкой понимаю тот факт, что код выполнится процедурой от начала до конца (с учетом вызова других процедур).

Тут же будут проверяться и не проиниченные переменные (на входе то цикла или чего там еще, тоже будет стоять АССЕРТ).

По сути, как понимаю, будут проверяться выполнение АССЕРТОВ, а также сравниваться между собой АССЕРТЫ (входные и выходные).

Или такие АССЕРТЫ катастрофически усложнят написание кода?

adva

  • Sr. Member
  • ****
  • Сообщений: 385
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #52 : Февраль 05, 2014, 12:27:24 am »
Хотя пожалуй, можно даже будет выдавать сообщения, что от этого до этого АССЕРТА проверка не удалась, т.к. нет каких-либо промежуточных АССЕРТОВ (и либо ты уверен в этом участке и не исправляешь ничего, либо продумываешь АССЕРТЫ)

Заодно вопрос,

Вроде в КП у АССЕРТА можно было номер вводить, для О7 это возможно (что-то не нашел этой возможнгости)?

adva

  • Sr. Member
  • ****
  • Сообщений: 385
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #53 : Февраль 05, 2014, 12:55:01 am »
О, мысли возникли параллельно с темой http://forum.oberoncore.ru/viewtopic.php?f=82&t=4963&view=unread#unread (хотя ее еще не видел). "Как" интересно, идеи передаются :)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #54 : Февраль 05, 2014, 02:48:46 am »
Для оберона вполне можно реализовать не только синтаксическую проверку (исходя из следующих предпосылок):
1) для всех условий используются только переменные простых типов (сравнение с ними). Если есть обращение к другим модулям, то считается что они корректны (для обозначения этого можно какой-то АССЕРТ придумать)

Не понял. f1() = f2() уже не написать?

2) везде где нужно прописываются АССЕРТЫ (именно на них и ориентировалась бы проверка). Это, пожалуй, самая сложная часть для программиста, но без нее похоже проверки не сделать.

Ну здесь как бы ничего нового. Ассерты прописываются где нужно. Было бы желание программиста их писать (оберон для этого не обязателен).

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

Не понял. Он и так выполняется от начала до конца (а обероне O7 только один RETURN).

Тут же будут проверяться и не проиниченные переменные (на входе то цикла или чего там еще, тоже будет стоять АССЕРТ).

Это масло маляное. Непроиниченные переменные потому и непроиниченные, что про них забыли. Ассерт забудут с тем же успехом.

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #55 : Февраль 05, 2014, 02:53:57 am »
Вроде в КП у АССЕРТА можно было номер вводить, для О7 это возможно (что-то не нашел этой возможнгости)?

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

adva

  • Sr. Member
  • ****
  • Сообщений: 385
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #56 : Февраль 05, 2014, 05:48:36 am »
Не понял. f1() = f2() уже не написать?
...
Это масло маляное. Непроиниченные переменные потому и непроиниченные, что про них забыли. Ассерт забудут с тем же успехом.

Если f1() из этого же модуля, то при вызове сравнивается ее входной АССЕРТ и соответствие состояние переменных до ее вызова (то же самое для f2)

Внутри f1 (и других) проверяется, что условие ассерта выхода выводится из входного ассерта (если не возможно, то об этом сообщается).

Если же f1 из другого модуля, то считается, что данное условие корректно (тут надо подумать).

Для непроиниченных наверное конкретно ассерты не надо ставить, просто проверять, что они присваиваются каким либо способом до места сравнения.

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

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #57 : Февраль 08, 2014, 05:47:47 am »
Что можно переписано на оберон. В принципе можно было еще context.js попробовать, но он очень большой, а дальше так жить нельзя.

Следующее расширение - STRING. Это будет value-тип, которы

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re: Oberon-07/13: заметки
« Ответ #58 : Февраль 08, 2014, 05:54:42 am »
Что можно переписано на оберон. В принципе можно было еще context.js попробовать, но он очень большой, а дальше так жить нельзя.

Следующее расширение - STRING. Это будет value-тип, который не может быть NIL. По  минимуму, но концептуально (не как в ББ).

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: Oberon-07/13: заметки
« Ответ #59 : Февраль 10, 2014, 01:14:47 pm »
Следующее расширение - STRING. Это будет value-тип
Фиксированной длины?