OberonCore
https://forum.oberoncore.ru/

Семантический редактор
https://forum.oberoncore.ru/viewtopic.php?f=93&t=1542
Страница 18 из 34

Автор:  Владислав Жаринов [ Вторник, 20 Декабрь, 2011 05:15 ]
Заголовок сообщения:  Re: Семантический редактор

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


Такая статья пока есть только в английской Википедии, правда "резиновые" формулировки статьи позволяют рассматривать практически любой редактор как структурный.
Вот я как раз об ней... :wink: В общем, Вы правы - "история битвы" за ту же статью о ДРАКОНе наглядное тому подверждение...
Кстати, с учётом этого:
Валерий Лаптев писал(а):
...
Статью в Вики - рано.
Вот когда напишем статью в РСДН - тогда можно и о статье в Вики подумать.
. М.б. статья в РСДН со временем и зачтётся как АИ в Вики... :wink:

Автор:  Валерий Лаптев [ Вторник, 20 Декабрь, 2011 06:26 ]
Заголовок сообщения:  Re: Семантический редактор

В смысле, предлагаете начинать войну прямо сейчас? :)

Автор:  Владислав Жаринов [ Вторник, 20 Декабрь, 2011 07:06 ]
Заголовок сообщения:  Re: Семантический редактор

Я ж говорю - со временем... :D Хотя, если в Вики всё так запущено - действительно, надо ли?..

Автор:  Владислав Жаринов [ Суббота, 24 Декабрь, 2011 16:37 ]
Заголовок сообщения:  Re: Семантический редактор

Валерий Лаптев в viewtopic.php?f=26&t=808&p=68678#p68678 писал(а):
Поддержу Сергея.
Инструментарий просто не должен допускать неправильного проектирования-программирования.
Я тут уже привлодил пример, что мой студент, привыкнув писать в нашем редакторе исключительно структурно (постановка "руки"), потом и в шарпе стал так уже на автомате делать. И это - только один маленький пример. Причем это уже на 4 курсе, когда вроде все "плохие" привычки сформировались. И то их удалось скомпенсировать А если сразу начинающих в среду, которая просто не даст писать неправильно, то это как-раз то самое, о чем говорил ВИРТ: профессиональные привычки и качества.
Имелось в виду, наверное, это: viewtopic.php?f=26&t=808&p=68331#p68331.
Типа иллюстрации к этому:
3.2

Жил некогда на свете Учитель, который писал неструктурированные программы. Его ученик, который пытался подражать ему, так же стал писать неструктурированные программы. Когда ученик попросил Учителя оценить его прогресс, учитель отругал его за написание таких программ, сказав: “Что позволено Учителю, не позволено ученику. Ты должен постигнуть Дао до того, как структура станет трансцендентальной”.

Автор:  Владислав Жаринов [ Суббота, 24 Декабрь, 2011 17:24 ]
Заголовок сообщения:  Семантический редактор и правильнописание :)

Вот, кстати, ещё на похожую тему:
logout2d в http://dxdy.ru/post341606.html#p341606 писал(а):
...
К любой задаче я подхожу так:
Первым делом ее надо максимально осознать! И даже когда проблема ясна я не тороплюсь набивать код! Необходимо собрать максимум информации о проблеме, особенно будет ли программа совершенствоваться или она конечная, сделали раз и на всегда!
Хорошо допустим все аспекты задачи мы обварили!
Существует шутка у программистов что 70% времени они делают программу лежа на диване и лишь 30% набивая код! И это так и есть у нормальных программеров!
Крайне важно хорошо понять решаемую проблему!
Следующим шагом надо понять что мы хотим от программы! Чтобы она частично решала задачу или полностью и нужна ли она вообще!
Ну допустим нужна
Далее я проектирую "каркас" программы, состоящий из логики и интерфейса.
Я как то отошел от всяких блок схем, они только захламляют мозг!
Надо просто и ясно нарисовать абстрактную схему (без всяких правил для блок схем) КАК ВАМ ПОНЯТНО, как будет действовать программа, и на какие части она будет разделена. Будет ли это несколько программ?
Далее под эту абстрактную схему работы программы ваяем интерфейс на бумаге, прямо рисуем основные окна и тд, не надо разрисовывать досканально, главное создать каркас!
Создание каркаса существенно облегчает дальнейшее написание программы и избавляет от кучи иттераций рефакторинга, переделок и тд!
Далее по принципу разделяй и властвуй я пытаюсь разделить программу на самодостаточные модули, куски, функции. Желательно чтобы они были самодостаточны, чтобы их можно было сделать отдельно и проверить их правильность, а потом использовать.
Когда все это сделано, можно себе представить как будет работать будущая программа, погонять примеры ее использование в голове.
И только когда программа существует в таком виртуальном, А ГЛАВНОЕ КОНЦЕПТУАЛЬНО ЗАКОНЧЕННОМ, виде я приступаю к ее реализации!
Помните: программа появляется из ИДЕИ а не из кода, ударов по клаве и часов просиженных за компом!

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

Автор:  Владислав Жаринов [ Суббота, 31 Декабрь, 2011 20:18 ]
Заголовок сообщения:  Re: Семантический редактор

Вот чой-то вспомнилось описание программы как абстрактного синт-дерева. Что у него будет в корне? У Мейера - отдельный класс (видимо, потому, о чём сказано здесь). А как, скажем, в структурном редакторе?..

Автор:  Валерий Лаптев [ Суббота, 31 Декабрь, 2011 20:54 ]
Заголовок сообщения:  Re: Семантический редактор

Документ = список узлов. Каждый узел имеет вложенные части. В том числе многие узлы имеют вложенный список узлов... :)

Автор:  Владислав Жаринов [ Воскресенье, 01 Январь, 2012 09:10 ]
Заголовок сообщения:  Re: Семантический редактор

Вероятно, самая эргономичная структура. :) А "прошивка" дерева узлов документа тем самым предполагается? Ведь узел м.б. и процедурой, связанной с другими через вызов, и фрагментом документа со ссылками/закладками, так?
И узлы могут вестись как объекты БД - а документ как граф вхождения этих объектов?

Кстати, Мейер в принципе старается добиться как можно более высокого "когнитивного качества" изложения. Это главная языково- и парадигмо-независимая ценность его, я думаю.
    Так, весьма интересен сам по себе его подход к логике - и то, как он строит на этом перевод условий инвариантов в условия маршрутов.
    Или "обращённая детализация" - не писать сначала спецификацию как полностью неисполнимую - а наоборот, писать частично исполнимую программу как "спецификацию самой себя". Используя комментарии как заместители, не влияющие на транслируемость остального. Что соответствует графит-заместителям. Полностью по принципу фон Неймана - вместо "иерархии приложений" ГРАФИТ-ФЛОКСа...
Это к тому, что интересно было бы провести такие принципы в языке структурного редактирования. Давая схемный эквивалент - где и программа-спецификация будет иметь эргономичный вид за счёт замещения "структуроописующих слов" графовой частью схем (продуманного состава и взаимосвязи).

Автор:  Сергей Прохоренко [ Воскресенье, 29 Январь, 2012 18:57 ]
Заголовок сообщения:  Будущее программирования

Будущее программирования

Автор:  Владислав Жаринов [ Вторник, 31 Январь, 2012 16:46 ]
Заголовок сообщения:  Семантический редактор и перспективы формализации

Спасибо, весьма интересно. В общем то, с чем работает сочинитель (и то чем он работает :)) в перспективе, скорее всего, д.б. декларационной семантики (по крайней мере, спецификация и "исходные чертежи программ")...
Так что прав Валерий: "Как ни придумывай - в пределе ЛИСП получается"... :) Ну что ж, ждём ФП-модель и редактор... а там посмотрим, поддаётся ли ФП-язык "графитизации"... :)

Автор:  Сергей Прохоренко [ Вторник, 31 Январь, 2012 21:39 ]
Заголовок сообщения:  Re: Семантический редактор и перспективы формализации

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

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

Автор:  ilovb [ Среда, 01 Февраль, 2012 12:53 ]
Заголовок сообщения:  Re: Семантический редактор и перспективы формализации

Сергей Прохоренко писал(а):
... и далекий от математических или информационных моделей...

Любопытно! У меня представление с точностью наоборот! :D
На мой взгляд Лисп это и есть информационная модель в чистом виде.
Сколько людей столько мнений :lol:

Автор:  TAU [ Четверг, 02 Февраль, 2012 00:35 ]
Заголовок сообщения:  Re: Семантический редактор и перспективы формализации

Сергей,

Сергей Прохоренко писал(а):
ЛИСП слишком тексто-ориентированный, чтобы стать языком программирования будущего. Его синтаксис однообразный, невыразительный

Выражаю свое согласие.

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

FBD? LabView?

Автор:  Сергей Прохоренко [ Четверг, 02 Февраль, 2012 10:18 ]
Заголовок сообщения:  Re: Семантический редактор и перспективы формализации

TAU писал(а):
Сергей Прохоренко писал(а):
Мне вообще кажется, что синтаксис будущих "визуальных" языков функционального программирования

FBD? LabView?


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

См. также PureBuilder

Автор:  Владислав Жаринов [ Четверг, 08 Март, 2012 08:42 ]
Заголовок сообщения:  Новый язык вроде как семантического редактирования :)

Вот тут информировали ещё о проекте: https://docs.google.com/document/d/1Drl ... DYMGE/edit.
Сюды кидаю, т.к. по виду похоже на проекты, обсуждаемые здесь

Автор:  Сергей Прохоренко [ Четверг, 08 Март, 2012 11:21 ]
Заголовок сообщения:  Re: Новый язык вроде как семантического редактирования :)

Владислав Жаринов писал(а):
Вот тут информировали ещё о проекте: https://docs.google.com/document/d/1Drl ... DYMGE/edit.
Сюды кидаю, т.к. по виду похоже на проекты, обсуждаемые здесь


Совсем не похоже.

Автор:  Валерий Лаптев [ Четверг, 08 Март, 2012 12:09 ]
Заголовок сообщения:  Re: Семантический редактор

Кажется, мы окончательно пришли к минималистичности языка и специализации объектов языка.
Вот например: типы, которые есть в языке:
Код:
Типы данных базовые (элементарные, основные):
- булевское, boolean; true, false; истина, ложь; да, нет
- целое,integer;десятичные;   целые не имеют размера (длинные, реализованы программно);
- дробное, real; стандартный вид; размер соответствует типу double в С++ (IEEE-754-1985)
- символ, character;‘один_символ’; кодировка - ?
Вариант – letter, литера

Литералы (только элементарные типы):
-целое число – десятичное произвольного размера,
-дробное число – соответствует типу double в IEEE-754-1985,
-символ – один символ в апострофах (одиночная кавычка) – кодировка - ?
-строка – см. ниже о массивах
Внимание!    Встроенного типа «строка» - нет.
 -          Строка – это массив символов.
 -          Строковые литералы: последовательность символов в кавычках - “строка”
 -          Размер строкового литерала = количество символов
Операции
   - логические: ~ (not), & (and), | (or), ^ (xor)
   - сравнения: = (равно), #(не равно), <(меньше), >(больше), <=, >=
   - арифметика целая: + - * \ % (вопрос: целое деление – специальный знак?)
   - арифметика дробная: + - * /
Никаких неявных преобразований, кроме integer -> real
Думаем о том, чтобы как-то задавать кодировку символов в явном виде. Неявность тут не есть хорошо.

Массивы

Массив объявляется в том же операторе variable.
   Типом массива является [размер] тип
Примечание. Возможно специальное ключевое слово и отдельное объявление массива:
массив [размер] тип имя
   английское слово array

Семантика:
– нет начальных значений, нет констант!
– тип элементов может быть любой, в том числе массивом, записью, указателем и процедурным типом
– числовые элементы массива при объявлении обнуляются;
– булевские элементы массива при объявлении принимают значение false (ложь = ноль)
– массивы – только одномерные; многомерный массив трактуется как «массив массивов… массивов…»
– размер – это целочисленное выражение = количество элементов;
– размер вычисляется при выполнении программы
– размер массива можно получить с помощью метода размер(), который возвращает целое число типа integer
   m.size()   – английский вариант
        м.размер()    – русский вариант

Индекс – изменяется от 0 до N-1, если N– размер массива.
Индекс проверяется на корректность во время выполнения программы
Каждый индекс задаётся в скобках [индекс]

   Массив типа [размер] char – это массив символов;
        при объявлении элементы обнуляются;
Надо ли разрешать инициализацию? Криминала не наблюдается.

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

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

Записи – процедурная часть (без наследования и ООП)
запись поля; методы; конец
английское слово record
английское слово end
Альтернатива
   английское слово    class
   русское слово      группа
        русское слово      структура
        русское слово      кортеж
        русское слово       тип  - выбрали вот этот вариант.

Семантика
   нет начальных значений, нет констант!
   полем записи может быть объект любого типа, в том числе массив, указатель на тип, объект-запись
Вопрос: поле записи – процедурная переменная; пока разрешаем
Отметим:    объявление полей = объявление переменных без инициализации!
   Вместо слова переменная используется слово поле; английское field   
Запись определяет:
   – тип объектов
   – пространство имён
Тип объектов
   – определяется на уровне модуля
   - тип используется с момента объявления
   - тип локален в модуле; можно сделать тип публичным
Пространство имён
   -все имена видны внутри записи независимо от места объявления
   - все имена считаются локальными в записи;
   - даже если тип объявлен публичным, имена все равно являются локальными в записи
   – любое имя, определённое в записи, может быть явно сделано публичным
Доступ к открытым элементам записи
осуществляется только при объявлении объекта данного типа с помощью селектора – точка

Записи-объекты создаются
a) статически – обычное объявление переменной
b) динамически – во время выполнения программы в динамической памяти.
Только для записей определены указатели

Указатель на запись
variable тип имя;    – в качестве типа требуется задать указатель на тип записи
указатель-на тип
Вариант:
   ^ тип
   * тип
Замечание. На месте первого символа можно написать любой иероглиф, обозначающий указатель   
Семантика
   нет констант!
   тип – только объявленный тип записи
        необходим практически только для создания динамических структур данных из объектов-записей
   при объявлении получает значение (специальное) – пусто (nil)
   может быть полем записи
   может быть элементом массива
Совместимость по присваиванию - должны совпадать типы записей.

Процедурный тип
(параметры)      – тип переменной-процедуры
(параметры): тип    – тип переменной-функции
Примечание. Возможно специальное ключевое слово и отдельное объявление переменной - процедуры:
процедура (параметры)имя;
функция (параметры): тип имя;
Семантика
   – нет констант!
   – необходим практически только для того, чтобы передавать процедуру как параметр
   – при объявлении процедурной переменной она получает значение (специальное) – пусто (nil)
   – процедурной переменной может быть присвоено имя любой процедуры с таким же прототипом.
   (в том числе и стандартной) – в компонентном паскале - запрещено
   – начальные значения есть - ? (похоже, можно разрешить)
   – совместимость по присваиванию – точное совпадение списка параметров по типам

Примеры объявлений:

Переменные скалярные
   variable тип имя;
   variable тип имя, имя, …, имя;
        variable тип имя, тип имя, …, тип имя;
   
        variable тип имя := выражение;
   variable тип имя := выражение, имя := выражение, тип имя, …, имя := выражение;
        variable тип имя := выражение, тип имя, имя := выражение,…, тип имя := выражение;
русское слово:   переменная

Константы – требуется явный тип и инициализация
   constant тип имя = выражение;
   constant тип имя = выражение, имя = выражение,…;
constant тип имя = выражение, тип имя = выражение,…;
Внимание:    выражение вычисляется во время интерпретации
русское слово:   константа

Важное замечание: константа может быть только элементарного типа.
Отметим: перечисление – это просто сокращение явного объявления констант.
constant
   целый воскресенье = 0, понедельник = 1, вторник = 2;    -- и так далее
Замечание: в данном варианте отсутствует присвоение общего имени набору констант.
-----------------------------------------------------------------------------------------------------------
переменная массив [размер] тип имя;
переменная указатель на тип имя;
переменная процедура(параметры) имя;
переменная функция(параметры):тип имя;

Присваивание:
Альтернатива:      пусть
Английское слово   let

скалярные переменные базовых типов
   присвоить имя := выражение;
   Выражение по типу должно совпадать или приводиться к типу имени
Единственная операция неявного приведения: integer ->real
массив символов - единственный вариант присваивания массиву выражения.
   присвоить имя := строковый_литерал;
Размер строкового литерала не должен превосходить размера массива   
Элемент массива
   присвоить имя[индекс] := выражение;
   Выражение по типу должно совпадать или приводиться к типу имени

Вопрос:  элементом массива может быть массив. Разрешается ли присваивание такого элемента ?
И вопрос с присваиванием массивов. Либо вообще запрещаем, либо разрешаем.
Тогда возврат из функции массива надо разрешать.
Семантика присваивания может быть разная
      – либо размеры и тип элементов совпадают;
      – либо – не совпадают; 

Поле записи
   присвоить полное_имя := выражение;
   Вид выражения зависит от типа поля записи
Выражение по типу должно совпадать или приводиться к типу имени
   
Указатель на запись
   присвоить имя_указателя := имя_указателя;
   присвоить имя_указателя := new(тип-записи);
   Указатели по типу записи должны совпадать
   Тип записи в операции new () должен совпадать с типом записи указателя
Процедурная переменная
   присвоить имя_пп := имя_процедуры;
   Переменная имя_пп и процедура с именем имя_процедуры должны иметь точно совпадающий список параметров


варианты присваивания (Дейкстра)– не нужно, так как редактор семантический ?
присвоить имя, имя,… := выражение;   присвоить одно выражение нескольким переменным-- это бывает полезно


Пока как-то так

Автор:  Сергей Прохоренко [ Четверг, 08 Март, 2012 14:01 ]
Заголовок сообщения:  Re: Семантический редактор

Валерий Лаптев писал(а):
Кажется, мы окончательно пришли к минималистичности языка и специализации объектов языка.


Язык минималистичный и в то же время полный. Но не видно преимуществ и вообще каких-либо отличий СТРУКТУРНОГО редактора от текстового (IDE). Явно напрашивается табличная (или древовидно-табличная) форма задания объявлений. Не хотите попробовать?

Автор:  Евгений Темиргалеев [ Четверг, 08 Март, 2012 16:06 ]
Заголовок сообщения:  Re: Семантический редактор

Валерий Лаптев писал(а):
Кажется, мы окончательно пришли к минималистичности языка и специализации объектов языка.
Вот например: типы, которые есть в языке:
Что-то это всё мне напоминает...

Автор:  Валерий Лаптев [ Четверг, 08 Март, 2012 19:17 ]
Заголовок сообщения:  Re: Семантический редактор

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

Фактически мы убрали из КП:
1. размеры элементарных типов
2. Все, что связано с битами.
На наш взгляд, для изучения основ алгоритмизации это вещи не особо нужные.

О массивах остался только один кардинальный вопрос: будут ли какие-то выражения с массивами, или пусть все обрабатывают ручками.

Со строками все сразу было ясно: строк нет.
Модуль Строки - это состав фреймворка. И постараемся там как-то разрешить проблемы кодировки в явном виде. Поскольку для начинающих кодировка представляет некоторую проблему - вот пусть с самого начала с ней и знакомятся в чистом виде.

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

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


В объектной части записи обязательно будет основной базовый тип вроде anyrec.
Если нужно наследование - явно задается, как в КП.
Методы = процедуры с явным указанием дополнительного параметра (как в КП).
Сейчас требует детального разбора взаимоотношений процедурных переменных и методов.
Кроме того, наследование с переходом межмодульных границ, множественное наследование (абстрактный класс или интефейс?), проблемы видимости элементов записи при переходе границы модулей, виртуальность.
Естественно, в первую очередь смотрим на КП с некоторыми упрощениями

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

Страница 18 из 34 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/