OberonCore

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

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




Начать новую тему Ответить на тему  [ Сообщений: 679 ]  На страницу Пред.  1 ... 15, 16, 17, 18, 19, 20, 21 ... 34  След.
Автор Сообщение
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Вторник, 20 Декабрь, 2011 05:15 

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Вторник, 20 Декабрь, 2011 06:26 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
В смысле, предлагаете начинать войну прямо сейчас? :)


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Я ж говорю - со временем... :D Хотя, если в Вики всё так запущено - действительно, надо ли?..


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Валерий Лаптев в 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 

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

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


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот чой-то вспомнилось описание программы как абстрактного синт-дерева. Что у него будет в корне? У Мейера - отдельный класс (видимо, потому, о чём сказано здесь). А как, скажем, в структурном редакторе?..


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Документ = список узлов. Каждый узел имеет вложенные части. В том числе многие узлы имеют вложенный список узлов... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Воскресенье, 01 Январь, 2012 09:10 

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

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


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

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Будущее программирования


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Январь, 2012 16:46 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Январь, 2012 21:39 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Февраль, 2012 12:53 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Сергей Прохоренко писал(а):
... и далекий от математических или информационных моделей...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Февраль, 2012 00:35 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Сергей,

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

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

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

FBD? LabView?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Февраль, 2012 10:18 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
TAU писал(а):
Сергей Прохоренко писал(а):
Мне вообще кажется, что синтаксис будущих "визуальных" языков функционального программирования

FBD? LabView?


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

См. также PureBuilder


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 08 Март, 2012 08:42 

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


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

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Четверг, 08 Март, 2012 12:09 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Кажется, мы окончательно пришли к минималистичности языка и специализации объектов языка.
Вот например: типы, которые есть в языке:
Код:
Типы данных базовые (элементарные, основные):
- булевское, 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 () должен совпадать с типом записи указателя
Процедурная переменная
   присвоить имя_пп := имя_процедуры;
   Переменная имя_пп и процедура с именем имя_процедуры должны иметь точно совпадающий список параметров


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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Четверг, 08 Март, 2012 14:01 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Валерий Лаптев писал(а):
Кажется, мы окончательно пришли к минималистичности языка и специализации объектов языка.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Четверг, 08 Март, 2012 16:06 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Валерий Лаптев писал(а):
Кажется, мы окончательно пришли к минималистичности языка и специализации объектов языка.
Вот например: типы, которые есть в языке:
Что-то это всё мне напоминает...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Четверг, 08 Март, 2012 19:17 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Естественно!
Основная задача языка - первоначальное знакомство с основами программирования.
Поэтому он должен знакомить совсеми основами, но без излишних деталей, которые на первых шагах обучения совершенно лишние.

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

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

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

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

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


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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 679 ]  На страницу Пред.  1 ... 15, 16, 17, 18, 19, 20, 21 ... 34  След.

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


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

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


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

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