Forth
http://fforum.winglion.ru/

Критика ANS-94
http://fforum.winglion.ru/viewtopic.php?f=9&t=30		 Страница 1 из 3
Автор:  Hishnik [ Сб май 13, 2006 23:48 ]
Заголовок сообщения:  Критика ANS-94
Итак, вытаскиваю из запасников давно лежащую там бочку дегтя.

Сначала небольшая, зато с самого верха, ложка. В подавляющем большинстве языков программирования числа с плавающей точкой распознаются (кто бы мог подумать?) по наличию точки в записи числа. В Форте точка использовалась для обозначения чисел двойной длины... то есть таких как 0000:B800. Соответственно, пришлось придумывать, как бы выделить эти самые плавающеточечные числа, и придумано было ориентироваться на символ E. То есть 3.1415 - это число двойной длины, а вот 3.1415E0 - правильная запись. И несмотря на наступление 90-х годов, данная несуразица не была поправлена. Замечаем, что 32 и даже 64 разряда в качестве ширины числа одинарной длины уже ничего сложного не представляют, остается только удивляться.
Итак, что хотелось бы видеть? Точку в прдставлении числа как признак формата с плавающей точкой. И, если уж так хочется, двоеточия для обозначения чисел двойной длины.

Далее, Форт имеет в активе мощнейшую концепцию контекстных словарей. Наличие словарей делает практически ненужной реализацию объекто-ориентированного программирования, поскольку все свойства объектов (инкапсуляция, наследование, полиформизм) словари обеспечивают. В сочетании с векторными переменными они обеспечат еще и динамическое связывание (а статическое обеспечивается самим механизмом их работы).
Что получилось в '94? Словарей стало "как минимум 8". Появилась необходимость (а не возможность!) регулировать порядок поиска (ONLY, ALSO). Итак, форт-система, поддерживающая только восемь словарей, имеет полное право считаться ANS-совместимой (то есть будьте любезны ограничиваться 8 объектами), и при попытке переключиться на другой словарь следует явным образом выписать порядок поиска (читай: иерархию). Кто-нибудь может представить, что в OWL каждый раз при обращении к объекту надо писать TObject->TVisible->TWIndow->TWinControl->TButton? Нет, можно, конечно, наслоить еще десять разновидностей ООП-библиотек. Устаревающая технология, кстати...

Можно добавить, что блоки CATCH/THROW копируют несколько чуждую Форту технологию обработки исключений. Почему чуждую? А можно ставить THROW после каждой строки? Можно? А тогда почему транслятор не хочет делать это сам, а заставляет программиста заниматься подобными вещами? К тому же Форт-система с ее консолью весьма терпимо относится к исключениям. Откомпилированную программу при делении на ноль придется перезапустить. В консоли же достаточно повторно набрать необходимое слово, устранив предварительно причину исключения. Вывод: THROW должно выполняться автоматически, без необходимости его набора в тексте.

Пока вот так.
Автор:  forther [ Вс май 14, 2006 00:28 ]
Заголовок сообщения:  Re: Критика ANS-94
Хищник писал(а):
Можно добавить, что блоки CATCH/THROW копируют несколько чуждую Форту технологию обработки исключений. Почему чуждую? А можно ставить THROW после каждой строки? Можно? А тогда почему транслятор не хочет делать это сам, а заставляет программиста заниматься подобными вещами? К тому же Форт-система с ее консолью весьма терпимо относится к исключениям. Откомпилированную программу при делении на ноль придется перезапустить. В консоли же достаточно повторно набрать необходимое слово, устранив предварительно причину исключения. Вывод: THROW должно выполняться автоматически, без необходимости его набора в тексте.


Я не совсем понял про THROW после каждой строки ... С таким же успехом можно спросить про "long_jump" (C -шный) после каждой строки.
Автор:  Hishnik [ Вс май 14, 2006 01:08 ]
Заголовок сообщения: 
Сейчас THROW следует писать после каждой операции, оставляющей на стеке код ошибки. Не слишком ли однообразным и предсказуемым получается текст?

Код:
OPEN-FILE THROW
WRITE-FILE THROW
CLOSE-FILE THROW


Не кажется, что "в этой сказке что-то не так"?
Автор:  Гость [ Вс май 14, 2006 05:32 ]
Заголовок сообщения: 
Хищник писал(а):
Сейчас THROW следует писать после каждой операции, оставляющей на стеке код ошибки. Не слишком ли однообразным и предсказуемым получается текст?

Код:
OPEN-FILE THROW
WRITE-FILE THROW
CLOSE-FILE THROW


Не кажется, что "в этой сказке что-то не так"?


Нет. Этих операций совсем мало. А в без-осных системах совсем нет. Кроме того можно и без
THROW ошибку обработать или просто похерить.
Автор:  ygrek [ Вс май 14, 2006 12:06 ]
Заголовок сообщения: 
ну во-первых, никто ведь не мешает
Код:
: AUTOTHROW >IN @ ' SWAP >IN ! CREATE , DOES> @ EXECUTE THROW ;
AUTOTHROW OPEN-FILE
AUTOTHROW CLOSE-FILE


во-вторых - если сделать автоматом THROW, то как обрабатывать не критичные исключения? Хотя бы пользователю сообщить?.. Получается CATCH уже нафиг не нужен.. Например тот же файл не открылся - я не хочу отваливаться с маловразумительным -2003 WORD OR FILE NOT FOUND, а хочу красивое окошко например юзверю вывести с именем файла, или в лог записать...
ИМХО с THROW/CATCH всё в порядке.
Автор:  Hishnik [ Вс май 14, 2006 14:19 ]
Заголовок сообщения: 
Гость писал(а):
Нет. Этих операций совсем мало. А в без-осных системах совсем нет. Кроме того можно и без
THROW ошибку обработать или просто похерить.


Код ошибки все равно лежит на стеке и с ним надо сделать хотя бы DROP.
Автор:  Hishnik [ Вс май 14, 2006 14:24 ]
Заголовок сообщения: 
yGREK писал(а):
ну во-первых, никто ведь не мешает

Теперь приходится постоянно писать AUTOTHROW? Вопрос как раз в том, чтобы ограничить объем текста и упростить структуру операций с очевидным поведением.

yGREK писал(а):
а хочу красивое окошко например юзверю вывести с именем файла, или в лог записать...


Это легко сделать собственным обработчиком исключений. Который будет вызываться всегда, а не только тогда, когда он будет явно указан.
Автор:  WingLion [ Вс май 14, 2006 14:33 ]
Заголовок сообщения: 
Хищник писал(а):
Теперь приходится постоянно писать AUTOTHROW? Вопрос как раз в том, чтобы ограничить объем текста и упростить структуру операций с очевидным поведением.


А там (у yGREK), вроде код, который переопределяет слово, а не... :)
Автор:  Hishnik [ Вс май 14, 2006 14:44 ]
Заголовок сообщения: 
Аа, точно, не заметил :) Но тогда зачем надо делать не-AUTOTHROW версии? :) А придется сделать сначала с THROW (потому что в стандарте), а только потом переопределить на AUTOTHROW. При этом софт, который ориентируется на простановку THROW после OPEN-FILE, уже не заработает.
Автор:  ygrek [ Вс май 14, 2006 17:21 ]
Заголовок сообщения: 
В общем случае, если автоматически кидать THROW, теряется возможность самому отловить ошибку и в месте ошибки произвести контекстные действия по её исправлению. Остаётся только один глобальный CATCH. Во многих случаях такое поведение неприемлимо.
То есть у нас есть два варианта - кому-то хочется
Цитата:
ограничить объем текста и упростить структуру операций с очевидным поведением.

, а кому-то надо иметь возможность оперативно реагировать на ошибки не вываливая всю программу.
Текущий стандарт позволяет реализовать оба поведения (первое например с помощью AUTOTHROW, второе в стандарте).

Цитата:
При этом софт, который ориентируется на простановку THROW после OPEN-FILE, уже не заработает.

А вот не надо включать такие переопределния перед чужим кодом. Для частного пользования only.
Автор:  Hishnik [ Вс май 14, 2006 19:26 ]
Заголовок сообщения: 
yGREK писал(а):
В общем случае, если автоматически кидать THROW, теряется возможность самому отловить ошибку и в месте ошибки произвести контекстные действия по её исправлению. Остаётся только один глобальный CATCH.


Можно менять адрес обработчика исключений. Я исхожу из того факта, что в минимальном объеме программа рассчитывает, что все файлы откроются и все запишется как надо. Поэтому никакой CATCH просто не пишется, и встает вопрос: что же делать с результатом операции, который так и лежит на стеке? А вот уже на основе векторизованного обработчика можно организовать CATCH/THROW.

yGREK писал(а):
А вот не надо включать такие переопределния перед чужим кодом. Для частного пользования only.


Мы рассматриваем стандарт. И я хочу сказать, что в стандарт включен неуниверсальный механизм обработки исключений.
Автор:  in4 [ Пн май 15, 2006 14:12 ]
Заголовок сообщения: 
yGREK писал(а):
Цитата:
При этом софт, который ориентируется на простановку THROW после OPEN-FILE, уже не заработает.

А вот не надо включать такие переопределния перед чужим кодом. Для частного пользования only.


По-фортовски нужно придумать новые названия для AUTOTHROW-слов. OPEN-FILE-AT , например.

А вот плодить кучи похожих названий тоже нехорошо. :(
Автор:  ygrek [ Вт май 16, 2006 09:20 ]
Заголовок сообщения: 
Хищник писал(а):
Можно менять адрес обработчика исключений. Я исхожу из того факта, что в минимальном объеме программа рассчитывает, что все файлы откроются и все запишется как надо. Поэтому никакой CATCH просто не пишется, и встает вопрос: что же делать с результатом операции, который так и лежит на стеке? А вот уже на основе векторизованного обработчика можно организовать CATCH/THROW.

Мне идея с векторизированным CATCH наверное не сильно нравится... Вектор придётся не только устанавливать при входе в слово где может произойти исключение, а и восстанавливать при выходе...
При глобальном векторном CATCH'е где точка возврата из обработчика?
Да, кстати.... Почему я решил что остаётся только глобальный CATCH... Никто ведь не мешает и самому CATCH локально использовать...
Хищник писал(а):
Мы рассматриваем стандарт. И я хочу сказать, что в стандарт включен неуниверсальный механизм обработки исключений.

Вообщем по-моему текущий стандарт не мешает ввести предлагаемое тобой поведение
(в качестве подключаемой либы и может немного в компиляторе..). А вот вносить такое поведение в стандарт - ИМХО не стоит.
Автор:  Hishnik [ Вт май 16, 2006 22:11 ]
Заголовок сообщения: 
yGREK писал(а):
Мне идея с векторизированным CATCH наверное не сильно нравится... Вектор придётся не только устанавливать при входе в слово где может произойти исключение, а и восстанавливать при выходе...


А зачем? Есть поведение "по умолчанию" - выдать сообщение и перейти в консоль со сбросом стеков. Если надо нечто иное, можно написать обработку конкретного исключения (ввести retry/abort/ignore, к примеру) и поступить так, как нужно в конкретном случае. В этом случае все файловые операции в пределах проекта будут обработаны единообразно.

yGREK писал(а):
При глобальном векторном CATCH'е где точка возврата из обработчика?


QUIT

yGREK писал(а):
Вообщем по-моему текущий стандарт не мешает ввести предлагаемое тобой поведение
(в качестве подключаемой либы и может немного в компиляторе..). А вот вносить такое поведение в стандарт - ИМХО не стоит.


Так вот и CATCH надо было вводить не стандартом, а подключаемой либой. Я же не про механизм обработки говорю (они в целом сопоставимы), а именно про то, что в стандарт ввели неочевидное решение, которое имеет альтернативы.
Автор:  ygrek [ Чт май 18, 2006 21:24 ]
Заголовок сообщения: 
Перечитал ещё раз тред - я написал кучу глупостей :) И с чем собственно спорил - уже сам не понимаю.
Попытаюсь подвести итог. Альтернатива имеет место быть. Ничего кардинально плохого в текущей реализации нет.
Страница 1 из 3 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/