Forth
http://fforum.winglion.ru/

Критика ANS-94
http://fforum.winglion.ru/viewtopic.php?f=9&t=30		 Страница 2 из 3
Автор:  Hishnik [ Чт май 18, 2006 22:25 ]
Заголовок сообщения: 
yGREK писал(а):
Перечитал ещё раз тред - я написал кучу глупостей

Ну не знаю. Мне было интересно отвечать :)

yGREK писал(а):
Попытаюсь подвести итог. Альтернатива имеет место быть. Ничего кардинально плохого в текущей реализации нет.

Ну так и я о том же. Я же говорю - критиканством занимаюсь.. :)))
:shuffle;
Автор:  ygrek [ Вс янв 27, 2008 17:46 ]
Заголовок сообщения: 
WRITE-FILE ( c-addr u fileid -- ior )

Write u characters from c-addr to the file identified by fileid starting at its current position. [...]

Спрашивается зачем characters, а не address units?!
Автор:  mOleg [ Вс янв 27, 2008 18:04 ]
Заголовок сообщения: 
гм, раз уж опять поднялась тема, запощу свои соображения:
<pre>
1) стандарт не должен фиксировать реализацию каких бы то ни было слов системы,
например, при описании [IF] [ELSE] [THEN] структур, не стоило приводить код,
а стоило описать лишь интерфейс, а так же поведение в стандартных и нестандартных
ситуациях.

2) алфавитная сортировка имен определений словаря пригодна только в оглавлении,
или некоем индексирующем списке. В тексте должна быть логическая связность,
то есть каждой теме должен быть отведен собственный раздел.

3) как минимум стандарт должен быть разделен на три части(книги), каждая из которых
должна рассматривать следующие особенности реализации форт-системы:
- реализация виртуальной форт-машины, минимальный\оптимальный набор слов ФВМ;
- реализация компилятора форт-системы, организация памяти, работа словарей
(минимальная реализация);
- дополнительные полезные слова форт-системы, не обязательные, но удобные.
Только так возможно получить что-то логичное и более-менее пригодное для
использования. Возможно, имеет смысл ввести метки, отвечающие за полную\частичную
поддержку каждого уровня?

4) стандарт должен описывать набор слов, поведение слов, стековые диаграммы.
При этом не должен фиксировать реализацию чего бы то ни было, кроме интерфейса.

5) должен содержать тестовые примеры, позволяющие проверить совместимость со стандартом.
</pre>
Автор:  WingLion [ Вс янв 27, 2008 19:14 ]
Заголовок сообщения: 
A еще было бы не плохо иметь отдельный документ, который бы содержал таблицу сравнения стандартов, какие слова заменены, какие выкинуты, какие добавлены.
А так же в некоторых местах объяснения, почему так, а не этак.
Например, зачем съели слово FORGET и т.п...
Автор:  Hishnik [ Вс янв 27, 2008 20:13 ]
Заголовок сообщения: 
Такое сравнение было в книге Семенова, причем действительно с пояснениями, где и что. FORGET же, как мне думается, съели по причине появления достаточного количества памяти, чтобы безболезненно хранить разные версии слова. Все равно с клавиатуры много не наколотить...
Автор:  rvm [ Вс янв 27, 2008 20:14 ]
Заголовок сообщения: 
mOleg, Стандарт приводит реализацию в качестве примера (неформально), а не фиксирует. Это нормально.

Хищник писал(а):
А вот уже на основе векторизованного обработчика можно организовать CATCH/THROW

Слова, возвращающие ior не зависят от, и не навязывают выбор механизма обработки исключений, и это правильно. Если бы они вызывали вектор-обработчик вместо возврата ior, то они бы навязывали упомянутый выбор: был бы недостаток в слове более низкого уровня, как в случае с READ-FILE & Co, который по Стандарту дает длину в символах, а не в адресных единицах.
Автор:  mOleg [ Вс янв 27, 2008 20:16 ]
Заголовок сообщения: 
Хищник писал(а):
FORGET же, как мне думается, съели по причине появления достаточного количества памяти, чтобы безболезненно хранить разные версии слова.

ну, для начала, нужно вспомнить, что на место FORGET пришли MARKER

Цитата перевода АНСИ-94

<pre>MARKER
Поскольку реализации словаря стали более сложными, и в некоторых случаях
используют множественные адресные пространства, FORGET стал предельно трудным
или невозможным для реализации на многих системах Forth. MARKER очень ослабляет
проблему, делая возможным для системы помнить "ориентирующую информацию"
заранее, которая конкретно отмечает места, где словарь может быть перестроен в
некотором будущем.
</pre>

так вот, мне кажется, что это большая глупость.
Во-первых, Маркеры не проще получаются, да и не на столько удобны,
во-вторых, FORGET тоже надо было немного поменять, не экономить память, а исключать имя из словаря,
не обязательно исключая код...
Автор:  Hishnik [ Вс янв 27, 2008 20:22 ]
Заголовок сообщения: 
rvm писал(а):
Слова, возвращающие ior не зависят от, и не навязывают выбор механизма обработки исключений, и это правильно. Если бы они вызывали вектор-обработчик вместо возврата ior, то они бы навязывали упомянутый выбор: был бы недостаток в слове более низкого уровня

В каких случаях мы кладем поверх фанерного пола линолеум? Да практически во всех - так удобнее. Другое дело, что линолеум не надо прибивать гвоздями или приклеивать суперклеем. Но приводить человека в квартиру с фанерными полами и нештукатуренными стенами ("зато Вы сможете сами выбрать стиль мазков, цвет обоев и фактуру линолеума!") - дело гиблое. Зачем вот мне слово более низкого уровня? Сколько помню, проблемы с файловыми операциями заключались в том, что такого файла не было, а это уже не поправить изнутри программы. Ну разве что создать при отсутствии, но это решается средствами ОС - т.е. форматом вызова функции открытия файла. Что еще может быть? Физическая ошибка на диске? И мы при этом еще трепыхаемся и анализируем ior? Это мне никогда не было понятно. Ну вот дали эту пресловутую "свободу выбора"... и что с ней делать? Каждый раз выбирать (каждый раз поутру стелить линолеум, поверх класть ковры, и только потом ходить)? Наконец, доступ к API никто не закрывает - если нужен такой тщательный анализ низкоуровневых операций, можно и оформить нужные слова вручную.
Автор:  mOleg [ Вс янв 27, 2008 20:41 ]
Заголовок сообщения: 
ну, мне кажется, что вообще работа с файлами - это неизбежное зло.
В форте файлов быть не должно, как и файловых операций 8) все должно быть вокруг слов!
Что же насчет результата операции, то гораздо лучше было бы просто THROW делать.
Хотим ошибки обрабатывать делаем CATCH , не хотим, не обрабатываем 8)

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

Код:
: INCLUDE-PROBE ( addr u -- ... 0 | ior )
  R/O OPEN-FILE-SHARED ?DUP
  IF NIP EXIT THEN
  INCLUDE-FILE 0
;


вместо этого было бы логичнее и проще:
Код:
: INCLUDE-PROBE ( asc # --> ... 0 | ior ) ['] (INCLUDED1) CATCH ;


и это не проблема СПФа, а проблема используемого подхода, который, увы, и стандарт зафиксировал
Автор:  Hishnik [ Вс янв 27, 2008 21:04 ]
Заголовок сообщения: 
mOleg писал(а):
ну, мне кажется, что вообще работа с файлами - это неизбежное зло.
В форте файлов быть не должно, как и файловых операций все должно быть вокруг слов!

В языке - не должно быть. Но мы же делаем систему, работающую в определенном окружении. Если ОС содержит функции работы с файлами, вокруг этих функций необходимо сделать обертки. Кстати, крайне желательно, чтобы обертки были или как можно ближе к родному формату функций ОС, или тогда уж реализовывали некий общий знаменатель.
Автор:  mOleg [ Вс янв 27, 2008 21:09 ]
Заголовок сообщения: 
Хищник писал(а):
Если ОС содержит функции работы с файлами, вокруг этих функций необходимо сделать обертки. Кстати, крайне желательно, чтобы обертки были или как можно ближе к родному формату функций ОС, или тогда уж реализовывали некий общий знаменатель.

"если скрестить ужа и ежа - получится колючая проволока"... что и имеем
оно так и сделано.
Автор:  rvm [ Вс янв 27, 2008 21:14 ]
Заголовок сообщения: 
Хищник писал(а):
Зачем вот мне слово более низкого уровня? Сколько помню, проблемы с файловыми операциями заключались в том, что такого файла не было, а это уже не поправить изнутри программы.

Слово OPEN-LOGFILE открывает файл и позиционирует на конец, если файла нету — создает его, если позиционировать не удалось — закрывает хэндл (чтобы не было утечки):
Код:
: OPEN-LOGFILE ( a u -- h ior )
  2DUP FILE-EXIST 0= IF W/O CREATE-FILE-SHARED EXIT THEN
  W/O OPEN-FILE-SHARED DUP IF EXIT THEN DROP ( h )
  DUP 9REPOSITION-FILE DUP 0= IF EXIT THEN ( h ior )
  SWAP CLOSE-FILE DROP ( ior ) 0 SWAP ( 0 ior )
;


Хотелось бы взглянуть на описание этого слова через векторый обработчик и слова вида *-THROW (типа CLOSE-FILE-THROW), не возвращающие ior. Или таки это задача неправильная, и таких слов делать ненадо?
Автор:  Hishnik [ Вс янв 27, 2008 21:27 ]
Заголовок сообщения: 
rvm писал(а):
Слово OPEN-LOGFILE открывает файл и позиционирует на конец, если файла нету — создает его, если позиционировать не удалось — закрывает хэндл (чтобы не было утечки):


: OPEN-LOGFILE ( a u -- h )

h равен нулю, если открыть не удалось. Никакого векторного обработчика здесь не требуется, поскольку результат открытия файла в любом случае записывается в некую переменную, а в какой момент мы ее проверим - другой вопрос. ОС как бы не развалится, если мы будем пытаться писать в файл с номером 0. А вот кода станет меньше.
Автор:  rvm [ Вс янв 27, 2008 21:38 ]
Заголовок сообщения: 
Даже если так. Приведите пожалуйста код :)
(там еще надо проверить операцию позиционирования).
Автор:  Hishnik [ Вс янв 27, 2008 22:33 ]
Заголовок сообщения: 
rvm писал(а):
Даже если так. Приведите пожалуйста код
(там еще надо проверить операцию позиционирования).


Код:
invoke  CreateFileA, eax, GENERIC_READ+GENERIC_WRITE, FILE_SHARE_READ, 0, [b]CREATE_ALWAYS[/b], 0, 0
Страница 2 из 3 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/