Forth • Ответить

...

Forth-FAQ

WingLion.Ru

Список форумов » Литература » Стандарты Форта (Forth Standards)

Часовой пояс: UTC + 3 часа [ Летнее время ]

Архитектурный бардак в Forth на примере слов вывода числа

Модераторы: Модераторы

Ответить

Имя пользователя:

Заголовок:

Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000.

Размер шрифта:

	Цвет шрифта
[quote="KPG"]Ответ от ИИ (не сочтите за спам :) [quote]Текст содержит глубокий и справедливый структурный анализ: главная архитектурная проблема классического Forth заключается в нарушении принципа ортогональности и сокрытии глобального состояния (BASE) внутри базовых примитивов. Цитата «форт-слово “точка” приняло решение о типе числа» точно бьет в цель — смешение логики интерпретации типов данных с логикой их строкового представления порождает лавину исключений и ломает чистоту функций. Почему текущая модель Forth — это «комбайн» исключений Нарушение чистоты: Слово . зависит от скрытого внешнего аргумента (BASE), делая поведение кода контекстно-зависимым. Дублирование примитивов: Из-за жесткой связки типа и вывода стандарту требуются отдельные слова под каждый чих: U., D., U.R, D.R. Проблема расширения: Добавление новых форматов (ведущие нули, денежный формат, разделители тысяч) заставляет плодить бесконечные новые слова-исключения вместо комбинации существующих. Критика интерфейса BASE («Кишки наружу») Разработчик абсолютно прав насчет связки BASE @: Лишнее звено: Возврат адреса ячейки памяти вместо самого значения заставляет программиста постоянно писать шаблонный код BASE @ или BASE !. Засорение стека: Адрес переменной на стеке является промежуточным состоянием, которое не несет семантического смысла для прикладной логики. Как выглядит ортогональная архитектура (Value → Notation → Output) Вместо монолитных макро-команд предлагается разделение на независимые слои: [Числовое значение] ──► [Политика представления (Notation)] ──► [Форматирование в строку] ──► [Вывод (Type)] При таком подходе исторические слова вроде . переходят в разряд идиом (PATTERNS), разворачиваясь в явную цепочку чистого кода: : . DECIMAL FORMAT TYPE ; Это избавляет язык от скрытых зависимостей. Мы передаем параметры форматирования явно, сохраняя функции детерминированными. Если вам интересно развить эту тему, мы можем обсудить: Как спроектировать идеальный дескриптор политики представления (Notation Descriptor) для нового стандарта? Как концепция Input Source Frame решает аналогичную проблему «грязного» глобального состояния с >IN? Каким образом в вашей или современной реализации Forth можно элегантно изолировать компилятор от интерпретатора текста? [/quote] Мой комментарий в диалоге: Словао точка в такой интерпритации становится выводом в десятичной системе тогда и многообразие "дублирующих"" слов явилось решением "проблемы" отсутствия типа и размера у числа на стеке. [quote] Вы абсолютно правы. Вы нащупали самый корень проблемы: в классическом Forth на стеке находятся просто обезличенные биты (ячейки данных — cells). У них нет метаданных, они «не знают» своего типа, знаковости или размера. Именно поэтому исторический Forth пошел по пути типизации самих слов (операций), а не данных. К чему привело отсутствие типов на стеке? Слова берут на себя роль диспетчера типов: Поскольку число 11111111 на стеке может быть и знаком -1, и беззнаковым 255, и частью double-числа, программисту приходится именем слова указывать, как эти биты трактовать (. — как знаковое, U. — как беззнаковое). Комбинаторный взрыв имен: Если у вас есть 2 размера (single/double), 2 признака знаковости (signed/unsigned) и 2 варианта форматирования (обычный/с заданной шириной поля), вам математически требуется разных слов (., U., D., UD., .R, U.R, D.R, UD.R) просто для того, чтобы напечатать число. Решение проблемы в ортогональной архитектуре Если мы разделяем логику, как предлагает автор статьи, мы уходим от этой проблемы без усложнения стека динамической типизацией: Семантика значения (Интерпретация): Мы по-прежнему держим на стеке «сырые» биты, но явно говорим, как их читать (например, слово SIGNED или UNSIGNED преобразует их во внутреннее стандартизированное представление числа). Семантика представления (Политика): Задаем базис (HEX, DECIMAL) и опции (WIDTH). Вывод: Одно универсальное слово PRINT (или пара FORMAT TYPE). В такой парадигме слово . (точка) действительно становится не фундаментальным механизмом системы, а всего лишь жестко зашитым макросом-идиомой для быстрого интерактивного вывода в консоль: forth : . DECIMAL SIGNED FORMAT TYPE ; А для беззнакового вывода вместо создания «костыля» U. мы просто пишем явную композицию: forth 123 UNSIGNED FORMAT TYPE Если хотите, мы можем спроектировать, как должен выглядеть стековый интерфейс для передачи этой информации. Что, по вашему мнению, правильнее передавать в универсальное слово форматирования: явный дескриптор типа/формата (как объект) или разделять это на цепочку последовательных слов-модификаторов?[/quote][/quote]

Настройки:

BBCode ВКЛЮЧЕН

[img] ВЫКЛЮЧЕН

[flash] ВЫКЛЮЧЕН

[url] ВКЛЮЧЕН

Смайлики ВЫКЛЮЧЕНЫ

	Отключить в этом сообщении BBCode
	Не преобразовывать адреса URL в ссылки

Вопрос

Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.

Обзор темы - Архитектурный бардак в Forth на примере слов вывода числа

Автор

Сообщение

Victor__v

Заголовок сообщения:

Re: Архитектурный бардак в Forth на примере слов вывода числ

Человек, у которого в форте есть только . :
Как скучно я живу)

Добавлено: Вт сен 01, 2026 10:27

Hishnik

Заголовок сообщения:

Re: Архитектурный бардак в Forth на примере слов вывода числ

KPG писал(а):

Ответ от ИИ (не сочтите за спам

Сочтем!

Добавлено: Сб авг 29, 2026 17:39

Hishnik

Заголовок сообщения:

Re: Архитектурный бардак в Forth на примере слов вывода числ

SmartForth писал(а):

В новой статье мысль всё та же: сейчас Форт выглядит как архитектурный бардак. Проблема — в стандарте языка, точнее, в комитете по стандартизации, в котором заседают те, кто так и не понял, по какому пути должен был пойти язык программирования. В результате Форт сильно потерял свои позиции в мировом сообществе.

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

В чем состоит большая ошибка? В попытке сделать "как в Си". В мире мейнстрима есть ОС - пусть будет ФортОС! В мире мейнстрима есть библиотеки - давайте тоже писать библиотеки на Форте! В результате появляются трансляторы, которые вместо того, чтобы активно помогать программисту встраивать в проект сильные стороны Форта начинают перетяги�