Forth http://fforum.winglion.ru/ |
|
Структуры http://fforum.winglion.ru/viewtopic.php?f=2&t=3101 |
Страница 1 из 2 |
Автор: | Hishnik [ Чт июн 16, 2016 12:42 ] |
Заголовок сообщения: | Структуры |
Простой вариант структур, который сейчас используется в Форте - создание слов-описателей полей, которые просто прибавляют смещение к ранее заданному начальному адресу. Получается некоторая мимикрия, однако работающая. Недостатком является невозможность использования одинаковых имен полей в разных структурах. Кроме того, нет CREATE-слова, которое могло бы порождать экземпляры структур. Что бы хотелось тут иметь: Код: STRUCT POINT 4 -- X 4 -- Y END-STRUCT POINT Point1 10 Point1 X ! 20 Point1 Y ! Чего бы НЕ хотелось - особых случаев разбора и анализа. Однако видится некоторая схема реализации. Во-первых, понятно, что POINT должно содержать CREATE, потому что должно создавать слова. Соответственно, STRUCT - это уже слово, которое само создает CREATE-слова. Во-вторых, разграничение областей видимости в Форте имеет естественную реализацию - словари. Напрашивается очевидное решение - создаваемые слова (т.е. Point1) должны быть словарями. Тогда будет возможен и такой вариант Код: Point1 10 X ! 20 Y ! Для проб не хватает слова CREATE-VOC, которое создавало бы словарь. Описание слова STRUCT становится довольно интересным - это слово, которое создает слова, создающие словари (да еще и добавляющие в них описатели полей). Дополнительно в каждый такой словарик можно добавлять и собственный SIZEOF. |
Автор: | gudleifr [ Чт июн 16, 2016 14:07 ] |
Заголовок сообщения: | Re: Структуры |
<А я уже боялся, что mOleg не подойдет.> |
Автор: | VoidVolker [ Чт июн 16, 2016 20:59 ] |
Заголовок сообщения: | Re: Структуры |
Ну, такое решение вырисовывается довольно быстро после начала использования структур. И часто в структурах надо хранить токены/ссылки на функции/колбэки - а это уже методы. В итоге получается обычная объектная/классовая модель. В итоге, я выбрал наиболее простой вариант: слова доступа к методам/полям генерируются тупо добавкой к названию класса (для доступа к свойствам безымянных объектов), а так же к имени объекта. И получается что-то типа такого: Код: STRUCT POINT
4 -- X 4 -- Y END-STRUCT POINT: Point1 10 Point1.X! 20 Point1.Y! POINT VALUE Point2 10 Point2 POINT.X! 20 Point2 POINT.Y! |
Автор: | Victor__v [ Чт июн 16, 2016 21:02 ] |
Заголовок сообщения: | Re: Структуры |
Через словарь, да самое простое решение. А структуры сделанные через create, обладают некоторой ограниченностью ( по крайней мере в моей голове %) . Можно добавить в структуру-порождатель и парсер и прочие финтифлюшки. И получится то-то типа struct test ( a b c d ) , а доступ осуществлять так тогда: test a А если несколько нужно элементов структур? Да не вопрос test ( a d ) Итого: мой мыслительный процесс зашёл в тупик, ибо уже получился аналог словаря |
Автор: | mOleg [ Чт июн 16, 2016 21:43 ] |
Заголовок сообщения: | Re: Структуры |
Код: 0 struct MSG cell[] hwnd \ дескриптор окна адресата cell[] message \ идентификатор сообщения cell[] wParam \ первый параметр сообщения cell[] lParam \ второй параметр сообщения cell[] time \ время регистрации сообщения CELL 4 * fld[] pt \ координаты курсора при регистрации сообщения /struct Код: \ описание структуры битового поля 0 \ начальное битовое смещение BIT[] first \ поле размером в один бит (битовый флаг) 3 FLD[] second \ поле размером в три бита BIT[] thrid BIT[] fourth 2 FLD[] fifth 2 FLD[] sixth 8 FLD[] seventh 2 FLD[] eighth BIT[] nineth DROP Код: \ пример описания структуры с отрицательными полями -20 struct sample 0 fld[] aaaa 10 fld[] bbbb 20 fld[] cccc 0 fld[] dddd /struct /struct во-первых убирает лишнее число, во-вторых создает имя /sample содержащее размер структуры, в третьих закрывает словарь sample а было и такое обсуждение |
Автор: | Hishnik [ Сб июн 18, 2016 01:43 ] |
Заголовок сообщения: | Re: Структуры |
Вопрос здесь в основном лежит в такой плоскости: что нужно добавить к движку Форта, чтобы стали возможными такие приемы со структурами? Понятно, что можно много разного написать руками. Кстати, идея со стеком словарей из ANS94 и тут показывает несостоятельность. Каждый раз указывать последовательность поиска - лишнее. Последовательность получается путем планирования иерархии, для этого достаточно CONTEXT CURRENT. А ограничение по количеству словарей в ANS94 к тому же не даст объявлять много структур (их вполне может быть и больше заявленных . |
Автор: | mOleg [ Сб июн 18, 2016 08:52 ] |
Заголовок сообщения: | Re: Структуры |
Hishnik писал(а): А ограничение по количеству словарей в ANS94 к тому же не даст объявлять много структур ой нет, а подумать если? вот хоть 100500 структур создать можно (ограничение в АНС94 не на количество словарей вообще, а на количество словарей в контексте, которое к тому же можно изменять). Hishnik писал(а): Вопрос здесь в основном лежит в такой плоскости: что нужно добавить к движку Форта Я всегда считал, что ядро должно быть максимально компактным, а все сервисные вещи в библиотеках должны быть. |
Автор: | Hishnik [ Вс июн 19, 2016 00:47 ] |
Заголовок сообщения: | Re: Структуры |
mOleg писал(а): ой нет, а подумать если? вот хоть 100500 структур создать можно (ограничение в АНС94 не на количество словарей вообще, а на количество словарей в контексте, которое к тому же можно изменять). А думать всегда полезно. Структура вполне может быть вложенной. В этом, собственно, и смысл как-то ее выделять, потому что просто так пронумеровать смещения можно и без дополнительных мероприятий. А вот объявить точку, потом вложить ее в линию, линию в сложную фигуру, трехмерное тело и т.д. - уже существенно интереснее. Описывать сцену, содержащую такие фигуры и тела, может оказаться настолько увлекательным занятием, что предел в 8 словарей будет превышен. Вообще, есть правило "no magic numbers". 6 ячеек на стеке чисел с плавающей точкой - это отсылка к 8 ячейкам сопроцессора (еще 2 потребуются для печати). 8 словарей - это откуда взялось, и что за такое фундаментальное ограничение? А перекомпилировать каждый раз под новую прикладную программу - нет, спасибо. mOleg писал(а): Я всегда считал, что ядро должно быть максимально компактным, а все сервисные вещи в библиотеках должны быть. Это как раз не сервисные вещи. Здесь ведь дело сводится к тому, чтобы дать расширенные возможности создания словарей и слов, а уж во что конкретное это выльется - второй вопрос. Другое дело, что расширять возможности следует под конкретный сценарий использования. |
Автор: | VoidVolker [ Вс июн 19, 2016 11:00 ] |
Заголовок сообщения: | Re: Структуры |
Hishnik писал(а): Здесь ведь дело сводится к тому, чтобы дать расширенные возможности создания словарей и слов, а уж во что конкретное это выльется - второй вопрос. Другое дело, что расширять возможности следует под конкретный сценарий использования. Да, вот именно. Для маленьких и небольших по объему кода программ обычно вполне хватает глобального словаря и/или нескольких словарей. А вот в чем-то более сложном - уже нужна более сложная структура. Ибо в программе появляется несколько уровней управления, модули и подмодули, интерфейсы, структуры, объекты, и прочее. Соответственно одним или несколькими линейными словарями тут уже не обойдешься и нужная какая-то иерархическая структура. В идеале такая структура должна соответствовать архитектуре программы. И в данном случае получается вот что: словарь содержит список функций, а так же позволяет совершать некие действия над ним, следовательно словарь - это тот самый же класс/объект со своими методами и свойствами. И тогда, наиболее простой и логичной видится примерно такая схема: 1) Добавить в структуру, описывающую слово, новое поле - вложенный список слов; и при поиске следующего слова сначала искать его в списке слов предыдущего слова, а уже затем в списке слов предыдущего слова 2) Разрешить объявление новых слов в контексте другого слова, причем как приватных так и доступных снаружи. 3) Добавить специальный механизм для парсинга входящего потока в контексте текущего слова (типа того же NOTFOUND). Т.е., я предлагаю стереть границу между словом и словарем и объединить их в единую сущность. Т.о., каждое слово может иметь свои собственные методы, локальные переменные, быть и просто функцией/процедурой, и классом, и объектом, и модулем, и интерфейсом, и вообще чем угодно и как угодно. И конечно механизм управления всем этим должен быть открытым. Для примера можно взять те же локальные переменные - объявляются внутри слова и являются приватными. Так почему же не расширить и не унифицировать этот механизм для удобного использования? |
Автор: | Hishnik [ Вс июн 19, 2016 21:02 ] |
Заголовок сообщения: | Re: Структуры |
VoidVolker писал(а): ) Разрешить объявление новых слов в контексте другого слова, причем как приватных так и доступных снаружи. 3) Добавить специальный механизм для парсинга входящего потока в контексте текущего слова (типа того же NOTFOUND). Это уже добавлено: viewtopic.php?f=23&t=2942 Код: : TEST LOC[ VARIABLE X : R 2 2 + . ; ]LOC 5 X ! X @ . R ; Реализуется довольно просто - при определении слова запоминается точка входа в словарь (CURRENT @ @), при компиляции ; восстанавливается. Таким образом, все, накомпилированное после слова TEST, будет исключено из контекста поиска (но в процессе компиляции TEST оно там есть). |
Автор: | VoidVolker [ Вс июн 19, 2016 21:25 ] |
Заголовок сообщения: | Re: Структуры |
Hishnik писал(а): Это уже добавлено: viewtopic.php?f=23&t=2942 О как, а я как-то пропустил. Осталось добавить возможность делать локальные слова доступными снаружи и объявлять не только внутри слова во время определения, но и уже после. |
Автор: | Hishnik [ Вс июн 19, 2016 22:00 ] |
Заголовок сообщения: | Re: Структуры |
VoidVolker писал(а): Осталось добавить возможность делать локальные слова доступными снаружи и объявлять не только внутри слова во время определения, но и уже после. Это выглядит как-то уже за пределами понятия "локальное определение". Оно ведь на то и локальное, чтобы не быть видимым снаружи? Если надо специально, то можно завести указатель на локальный объект, все равно при таком механизме все локальные переменные находятся в точности на тех же местах при каждом вызове внешнего определения. |
Автор: | VoidVolker [ Пн июн 20, 2016 14:30 ] |
Заголовок сообщения: | Re: Структуры |
Hishnik писал(а): Это выглядит как-то уже за пределами понятия "локальное определение". Оно ведь на то и локальное, чтобы не быть видимым снаружи? Это если приводить к концепции, приведенной мною ранее. Кстати, а как именно компилируются эти локальные определения: среди кода текущего слова или как-то отдельно? |
Автор: | Hishnik [ Пн июн 20, 2016 14:46 ] |
Заголовок сообщения: | Re: Структуры |
VoidVolker писал(а): Кстати, а как именно компилируются эти локальные определения: среди кода текущего слова или как-то отдельно? Среди кода. LOC[ создает ссылку вперед и переключает в режим интерпретации. ]LOC разрешает эту ссылку и возвращает в режим компиляции. Таким образом, LOC[ ]LOC - это просто вставка новой цепочки словаря, которая потом будет выключена из поиска (однако все еще видна, пока не отработало ; и не восстановило CURRENT). Поэтому никакого фрагментарного кода и описаний вида "в новой версии размер памяти для локальных определений увеличен до 128 кб" нет и не предвидится. Пока есть память, можно добавлять локальные описания. Подобную же вещь стоит проделать и со структурами. Имитация синтаксиса структур или классов - это обычный с точки зрения Форта код, который к его основным особенностям не имеет никакого отношения. Раз в Форте управление областью видимости осуществляется с помощью связанных списков (на основе которых строятся словари), то и работу со структурами имеет смысл рассмотреть через призму связанных списков и их особенной организации. |
Автор: | Victor__v [ Пн июн 20, 2016 23:53 ] |
Заголовок сообщения: | Re: Структуры |
Цитата: Кроме того, нет CREATE-слова, которое могло бы порождать экземпляры структур Создающие слова можно и без Create делать. К примеру, : const : lit, [compile] ; ; : var here 0 , : lit, [compile] ; ; И всё нормально работает. Если таким Макаром подойти к созданию структур? |
Страница 1 из 2 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |