Forth
http://fforum.winglion.ru/

Разработка стандарта "от тестов"
http://fforum.winglion.ru/viewtopic.php?f=36&t=2521		 Страница 1 из 2
Автор:  Hishnik [ Вс мар 14, 2010 22:38 ]
Заголовок сообщения:  Разработка стандарта "от тестов"
Не секрет, что умозрительная работа над чем бы то ни было является источником спорных и проблемных утверждений. Недостаток здесь не в том, что появляются ошибки, неточности и неэффективные предложения, а в том, что нет механизма их исправления и четких критериев достижения результата (кстати, какого?). Поскольку критерии и цели могут быть не менее умозрительными, чем предложения, можно попробовать оттолкнуться от фиксированных результатов (тестов). Иными словами, в документацию по стандарту включаются тестовые алгоритмы (не программы и не слова), которые будут служить отправной точкой при выборе синтаксиса и семантики слов-кандидатов в ядро и те или иные расширения. Примером тестового алгоритма может быть: "вычислить сумму элементов массива, заданного начальным адресом и размером, содержимое массива - целые числа". В этом случае используемые слова могут быть совершенно любыми, хоть единственное слово ARRAY-SUM в ядре. Таким образом, специфицироваться будут не слова Форта, и не примеры их применения, а примеры конкретных частных задач. И утверждение "транслятор совместим со стандартом" для программистов будет означать, что с помощью этого транслятора они смогут решить вполне определенный круг задач (а не просто скачивать нечто, а потом гадать, что имел в виду автор, добавляя и исключая определенные возможности).
Автор:  вопрос [ Вс мар 14, 2010 22:54 ]
Заголовок сообщения: 
А как можно определиться с перечнем алгоритмов?
Автор:  Hishnik [ Пн мар 15, 2010 00:06 ]
Заголовок сообщения: 
Можно посмотреть на широко распространенные тесты. Еще интересный сайт eembc.org, где есть наборы тестов для МК. Интересно там то, что оценка МК производится по сферам применения. В самом деле, "усредненно-универсально-производительный" МК имеет неплохие шансы проиграть в частных случаях специализированным решениям. Примерно та же ситуация и с Фортом - сферы применения разные, то, что для одной области является требованием, для другой - излишество. Поэтому и алгоритмы можно (и наверное следовало бы) разбить по группам.
Автор:  Kopa [ Пн мар 15, 2010 00:33 ]
Заголовок сообщения: 
Хищник писал(а):
Можно посмотреть на широко распространенные тесты. .


Чем это отличается от решения разных задач встречающихся в программисткой практике на заданном языке ( реализации )
Например: Rosetta code
и набора уже существующего библиотечного кода ( например ffl для Форта )

P.S. Следуя логики решения этих задач должен обеспечивать стандарт?
Автор:  Hishnik [ Пн мар 15, 2010 01:30 ]
Заголовок сообщения: 
Kopa писал(а):
Чем это отличается от решения разных задач встречающихся в программисткой практике на заданном языке ( реализации )
Например: Rosetta code
и набора уже существующего библиотечного кода ( например ffl для Форта )

Принципиально - ничем. Конкретно - тем, что такая работа еще не произведена, тесты не сгруппированы, их актуальность не проверена. Наконец, особого фанатизма тоже ведь быть не должно, это для работы конкретных людей, а не чтобы кому-то доказать, какие умные слова и термины знают разработчики стандарта.
Автор:  Alexander [ Пн мар 15, 2010 12:00 ]
Заголовок сообщения: 
Идея Хищника мне понятна и даже нравится. Даже виртуоз Вирт писал книги про разные алгоритмы и структуры данных и рассказывал в них как решить проблему на известном языке программирования. Что касаетя FSL и FFL - это средозависимые разработки и при их переносе приходится кое-что подправлять. Например, в контроллер алгоритм быстрой сортировки не всегда нужен.
осонвне операции в контроллере : сброс/установка сигнала на выходе, пересылка байта, слова, массива.
основне опреации консольного приложения: дизайн/программирование интерфейса.
типовые алгоритмы: вычисление БПФ, оценка МО, СКО; сортировка данных, построение структуры данных типа "дерево", ну и т.д.
Похоже, что выйдет так будет файл с деклараций высогоуровнего слова и файл аппаратнозависимой реализации (из серии сборки по условию [IF] [THEN]).
Автор:  chess [ Пн мар 15, 2010 17:12 ]
Заголовок сообщения: 
Хищник писал(а):
Не секрет, что умозрительная работа над чем бы то ни было является источником спорных и проблемных утверждений. Недостаток здесь не в том, что появляются ошибки, неточности и неэффективные предложения, а в том, что нет механизма их исправления и четких критериев достижения результата (кстати, какого?).

В качестве результата могу предложить создать стандарт на ядро форт-системы, которая будет заточена на создание форт-систем со специализированными ядрами(в том числе форт-системы для кросскомпиляции).
Специализация может касаться как платформы, так и набора базовых процедур ядра(включая INTERPRET-движок).
Платформы разные по типу архитектуры в части организации памяти, вычислительной модели, набора команд(фон Нейман, Гарвард, систолическая матрица процессоров, ТТА и т.п.).
С одной стороны это узкая задача, с другой широкая.
А наращивать функционал путем догрузки библиотек в одну базовую-стандартную форт-систему чтобы "угодить" всем задачам нереально в рамках
Форта. Наращивать функционал для специализированной форт-системы, заточенной под определенный круг задач - это уже реально.
Автор:  Hishnik [ Пн мар 15, 2010 21:06 ]
Заголовок сообщения: 
chess писал(а):
В качестве результата могу предложить создать стандарт на ядро форт-системы, которая будет заточена на создание форт-систем со специализированными ядрами(в том числе форт-системы для кросскомпиляции).

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

Вполне соглашусь. Но тут ведь важно провести границу между Фортом и его расширениями (runtime-библиотеками?). Ведь Си для ПК и Си для МК имеют разные стили использования, несмотря на то, что язык один и тот же. Просто библиотеки разные. Что уж говорить о Форте, где граница между ядром и библиотеками очень расплывчатая, поскольку ключевые слова заданы не спецификацией языка, а общими соглашениями. Так может быть, и не требовать от Форта, чтобы любая прикладная программа, даже написанная левой задней лапой, автоматически и беспроблемно транслировалась на всех известных платформах?
Автор:  вопрос [ Пн мар 15, 2010 21:53 ]
Заголовок сообщения: 
Цитата:
А не слишком ли сложно получается? "Система для разработки систем для разработки программ"
Мечта , если есть внятная концепция
Автор:  danbst [ Пн мар 15, 2010 23:41 ]
Заголовок сообщения: 
вопрос писал(а):
Мечта , если есть внятная концепция

Но это уже не форт.
Автор:  вопрос [ Вт мар 16, 2010 00:49 ]
Заголовок сообщения: 
danbst писал(а):
вопрос писал(а):
Мечта , если есть внятная концепция

Но это уже не форт.
А кто это решает?
Автор:  danbst [ Вт мар 16, 2010 01:15 ]
Заголовок сообщения: 
[offtop]
вопрос писал(а):
А кто это решает?

это интересный, философский вопрос. но на интуитивном уровне я не смогу назвать систему для создания системы для разработки программ Фортом. Это будет уже нечто другое.[/offtop]
Автор:  VoidVolker [ Вт мар 16, 2010 09:20 ]
Заголовок сообщения: 
danbst писал(а):
я не смогу назвать систему для создания системы для разработки программ Фортом

Ммм... Форт?
Автор:  idem [ Чт мар 18, 2010 11:34 ]
Заголовок сообщения: 
Хищник писал(а):
ключевые слова заданы не спецификацией языка, а общими соглашениями. Так может быть, и не требовать от Форта, чтобы любая прикладная программа, даже написанная левой задней лапой, автоматически и беспроблемно транслировалась на всех известных платформах?

С другой стороны, именно общие соглашения позволяют написать программу там, где для монитора с визуальным отображением кода не достаточно ресурсов. Для общего примера:
Код:
> Ok ( 1110 или 0001 )       /  «младший бит -- вершина стека»
«DUP»
> Ok ( 1100 или 0011 )
«ROT»
> Ok ( 1001 или 0110 )
…
…
> Ok ( 00 11 )
«SWAP» (?)
> Ok ( 11 00)

Если при раскрутке системы от таких общих принципов действовать непротиворечиво и последовательно, тогда при единстве Форт-системы различия начнутся только с формирования файла конкретной ОС, а дальше подключаются библиотеки и т.д. И я еще раз подчеркну, что главное – это сформировать общую модель для различных систем маш. кодов.
Автор:  вопрос [ Чт апр 29, 2010 20:38 ]
Заголовок сообщения:  Re: Разработка стандарта "от тестов"
Интересно, это возражение Хищнику или наоброт

мысль такая - стандартизирована должна быть функциональность примитивов, но не от тестов а от "функциональности построенного на них кода" который расширяет примитивы до полноценной форт-системы

например - есть код СПФ, сделанный на ассемблере, это, пусть будем называть, примитивный код. И есть некоторое количество форт-файлов, которые ( *.f )
не есть пользовательские файлы или библиотеки, а есть часть самого СПФ

Вот стандартизировать можно то, что "некоторый стандартный код, надстроенный над примитивами" - давал определенную функциональностъ
Страница 1 из 2 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/