Раз уж пошел разговор (в другой ветке), то выступлю, сам того не желая, в роли адвоката ANSI. И так:
1. Почему некоторые слова возвращают код ошибки на стеке а не вызывают exception?
Существуют два вида исключений: ошибки программы, кторые возникают вследствие неверных действий программы и делают ее дальнейшее выполнение бессмысленным или даже опасным; и штатные, когда ошибка может возникнуть вне зависимости от корректности действий программы. Первый случай, это, например переполнение стека, AV, деление на 0. Второй случай часто возникает при работе с файлами, поскольку при написании программы вы никак не можете гарантировать что ошибка не возникнет. При этом нет необходимосты прерывать работу программы, и часто можно обработать такую ошибку. Позиция коммитета такова, что если мы даем возможность работать с файлами, мы обязаны также дать возможность обрабатывать их ошибки в программе. Если бы слова работы с файлами выполняли THROW , то такая обработка могла бы выглядеть:
Код: : ?DISK3 ( -- ior ) S" A:\DISK3ID.INI" R/O ['] OPEN-FILE CATCH DUP IF ." Insert Disk3 and try again." THEN ;
Но Exception wordset опциональный, и может отсутствовать вне зависимости от присутствия File-access wordset в системе. Поэтому, был выбран самый простой метод обработки ошибок.
ЗЫ Всего в стандарте 2 набора слов использующих такой подход это работа с файлами и выделение памяти, по понятной причине. Остальные слова не возвращают код ошибки (кроме CATCH) а выполняют THROW , в случае его доступности.
2. На счет измерения файлов в символах а не одресных единицах, понять замысел коммитета сложнее. Единственное возможное обьяснение которое я нашел упрятано вот тут:
Цитата: A.11.6.1.0765 BIN
Some operating systems.....
....The Technical Committee has declined to address issues regarding the impact of “wide” characters on the File and Block word sets.
Из этого следует, что File-access wordset поддерживает character размером только в 1 байт, а значит его размер равен address unit, поскольку последний не может быть больше за character, но и меньше 1 байта не бывает (практически).
Хотя формально это не декларируется, и причины такого решения не обьясняются. Что, конечно, не есть хорошо.
3. Отсутствие FORGET ... Кто сказал что он отсутствует? Он есть, просто в следующих версиях его похерят. Причина проста - далеко не во всех реализациях Форта его возможно реализовать. Например, если у вас разделенная память для кода и данных, то получив адресс слова которое надо забыть, вы можете определить куда откотить указатель на область кода и словарей, но если данно слово не содеражало данных (создано не CREATE), то вы не будете знать куда откатывать область данных. Конечно, можно в словарной статье, для всех слов сохранять положения всех областей памяти, вот только это слишком жестокое требование для одного только слова FORGET, к тому носящего утилитарный характер (используется только при разработке). Альтернативный механизм с MARKER-ами позволяет сохранять в теле маркера сколь угодно точную и развернутую информацию о состоянии системы к которому надо откатиться. Словарные статьи при этом не страдают.
4.Контекст поиска не требует более 8 списков слов. Заметьте - это нижнее ограничение. Вы можете его снять вообще в своей реализации. На практике, большинство программ, особенно для малых систем не используют больших количество словарей одновременно в контексте поиска. Приведенный пример с ООП, конечно верный, но поскольку реализация ООП выходит за пределы АНСИ, то и принцип работы поиска по словарям тоже может быть изменен. Причем, во-первых - АНСИ дает достаточный инструментарий для создания практически любой системы поиска; во-вторых - не все ООП именно так работают со словарями.
Следует помнить, что набор слов управления поиском (Search order word set) является не завершенным механизмом, а инструментом создания таких механизмов. Там даже слова VOCABULARY нет, но оно легко создается, при необходимости. Так же и все другое.
5.Стандарт должен содержать тестовы пример. Совершенно верно. И АНСИ их содержит. Но очень, очень мало. Пару штук буквально, по памяти в локалзах, в комментарии к ], в CASE, и еще парочку. Совершенно согласен, что этого катастрофически мало, поскольку неоднозначных моментов есть много. К тому же, те что есть не вынесены в отдельный раздел, как того требуется.
|
