[quote="Ethereal"]А почему именно с плавающей точкой ? Ведь это-же числа с [b]плавающей запятой[/b] !
Это у пиндосов floating point, а у нас - плавающая запятая.[/quote]
Россiйскiй фортъ, н? такъ-ли?

[quote="Ethereal"]А почему именно с плавающей точкой ? Ведь это-же числа с плавающей запятой !
Это у пиндосов floating point, а у нас - плавающая запятая.[/quote]
Я не знаю, кто такие пиндосы с точки зрения технического русского языка. Что касается IEEE-754, описывающего формат с плавающей точкой, то там именно точка. Что не отменяет возможности использования запятой, если она соответствует национальным стандартам.
[quote="Ethereal"]Добавь к существующему формату записи литералов в Форте правило - запятая в записи
числа означает число с плавающей запятой. И получается совместимость сверху
вниз с существующими стандартами (кроме точки для чисел двойной точности
и буквы E для действительных чисел с мантиссой и показателем степени теперь
будет ещё и запятая).[/quote]
У меня именно так запятая и используется - это эвкивалент точки. Использование точки в Форте мне видится аналогом скобок - в ответ на детские, вобщем-то, претензии к непривычной записи выражений и отсутствии операций с числами с плавающей точкой пошла такая же детская реакция - а вот вам скобки в качестве комментариев, и точка в качестве разделителя для чисел двойной длины. И будете пользоваться, или уходите из нашей песочницы.

[quote="Хищник"]
Итак, что хотелось бы видеть? Точку в прдставлении числа как признак формата с плавающей точкой. И, если уж так хочется, двоеточия для обозначения чисел двойной длины.
[/quote]
А почему именно с плавающей точкой ? Ведь это-же числа с [b]плавающей запятой[/b] !
Это у пиндосов floating point, а у нас - плавающая запятая.
Добавь к существующему формату записи литералов в Форте правило - запятая в записи
числа означает число с плавающей запятой. И получается совместимость сверху
вниз с существующими стандартами (кроме точки для чисел двойной точности
и буквы E для действительных чисел с мантиссой и показателем степени теперь
будет ещё и запятая).

Раз уж пошел разговор (в другой ветке), то выступлю, сам того не желая, в роли адвоката ANSI. И так:

[b]1.[/b] Почему некоторые слова возвращают код ошибки на стеке а не вызывают exception?
Существуют два вида исключений: ошибки программы, кторые возникают вследствие неверных действий программы и делают ее дальнейшее выполнение бессмысленным или даже опасным; и штатные, когда ошибка может возникнуть вне зависимости от корректности действий программы. Первый случай, это, например переполнение стека, AV, деление на 0. Второй случай часто возникает при работе с файлами, поскольку при написании программы вы никак не можете гарантировать что ошибка не возникнет. При этом нет необходимосты прерывать работу программы, и часто можно обработать такую ошибку. Позиция коммитета такова, что если мы даем возможность работать с файлами, мы обязаны также дать возможность обрабатывать их ошибки в программе. Если бы слова работы с файлами выполняли THROW , то такая обработка могла бы выглядеть:
[code]: ?DISK3 ( -- ior ) S" A:\DISK3ID.INI" R/O ['] OPEN-FILE CATCH DUP IF ." Insert Disk3 and try again." THEN ;[/code]
Но Exception wordset опциональный, и может отсутствовать вне зависимости от присутствия File-access wordset в системе. Поэтому, был выбран самый простой метод обработки ошибок.
ЗЫ Всего в стандарте 2 набора слов использующих такой подход это работа с файлами и выделение памяти, по понятной причине. Остальные слова не возвращают код ошибки (кроме CATCH) а выполняют THROW , в случае его доступности.

[b]2.[/b] На счет измерения файлов в символах а не одресных единицах, понять замысел коммитета сложнее. Единственное возможное обьяснение которое я нашел упрятано вот тут:
[quote]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.[/quote]
Из этого следует, что File-access wordset поддерживает character размером только в 1 байт, а значит его размер равен address unit, поскольку последний не может быть больше за character, но и меньше 1 байта не бывает (практически).
Хотя формально это не декларируется, и причины такого решения не обьясняются. Что, конечно, не есть хорошо.

[b]3.[/b] Отсутствие FORGET ... Кто сказал что он отсутствует? Он есть, просто в следующих версиях его похерят. Причина проста - далеко не во всех реализациях Форта его возможно реализовать. Например, если у вас разделенная память для кода и данных, то получив адресс слова которое надо забыть, вы можете определить куда откотить указатель на область кода и словарей, но если данно слово не содеражало данных (создано не CREATE), то вы не будете знать куда откатывать область данных. Конечно, можно в словарной статье, для всех слов сохранять положения всех областей памяти, вот только это слишком жестокое требование для одного только слова FORGET, к тому носящего утилитарный характер (используется только при разработке). Альтернативный механизм с MARKER-ами позволяет сохранять в теле маркера сколь угодно точную и развернутую информацию о состоянии системы к которому надо откатиться. Словарные статьи при этом не страдают.

[b]4.[/b]Контекст поиска не требует более 8 списков слов. Заметьте - это нижнее ограничение. Вы можете его снять вообще в своей реализации. На практике, большинство программ, особенно для малых систем не используют больших количество словарей одновременно в контексте поиска. Приведенный пример с ООП, конечно верный, но поскольку реализация ООП выходит за пределы АНСИ, то и принцип работы поиска по словарям тоже может быть изменен. Причем, во-первых - АНСИ дает достаточный инструментарий для создания практически любой системы поиска; во-вторых - не все ООП именно так работают со словарями.
Следует помнить, что набор слов управления поиском (Search order word set) является не завершенным механизмом, а инструментом создания таких механизмов. Там даже слова VOCABULARY нет, но оно легко создается, при необходимости. Так же и все другое.

[b]5.[/b]Стандарт должен содержать тестовы пример. Совершенно верно. И АНСИ их содержит. Но очень, очень мало. Пару штук буквально, по памяти в локалзах, в комментарии к [b]][/b], в CASE, и еще парочку. Совершенно согласен, что этого катастрофически мало, поскольку неоднозначных моментов есть много. К тому же, те что есть не вынесены в отдельный раздел, как того требуется.

Зато появился MARKER. Его можно сделать "выразительным", типа COLD-RESTART, SOFT-RESTART, RELOAD-PARAMETERS.

[quote="Хищник"]Такое сравнение было в книге Семенова, причем действительно с пояснениями, где и что. FORGET же, как мне думается, съели по причине появления достаточного количества памяти, чтобы безболезненно хранить разные версии слова. Все равно с клавиатуры много не наколотить...[/quote]

странно... с клавиатуры можно легко набрать строчку:
<pre>
INCLUDE 10Mb_source_file.frt
</pre>

/me раньше свои проекты на форте писал со строчек
<pre>
FORGET КАКАЯ-НИТЬ-ФИГНЯ
: КАКАЯ-НИТЬ-ФИГНЯ ." ик-пук-траляля" ;
</pre>

И при повторном инклюде старое забывалось, а новое компилилось..

a на стандарте ANS-94 оно уже не канает :(

[quote="rvm"]Даже если так. Приведите пожалуйста код
(там еще надо проверить операцию позиционирования).[/quote]

[code]invoke CreateFileA, eax, GENERIC_READ+GENERIC_WRITE, FILE_SHARE_READ, 0, [b]CREATE_ALWAYS[/b], 0, 0[/code]

Даже если так. Приведите пожалуйста код :)
(там еще надо проверить операцию позиционирования).

[quote="rvm"]Слово OPEN-LOGFILE открывает файл и позиционирует на конец, если файла нету — создает его, если позиционировать не удалось — закрывает хэндл (чтобы не было утечки): [/quote]

: OPEN-LOGFILE ( a u -- h )

h равен нулю, если открыть не удалось. Никакого векторного обработчика здесь не требуется, поскольку результат открытия файла в любом случае записывается в некую переменную, а в какой момент мы ее проверим - другой вопрос. ОС как бы не развалится, если мы будем пытаться писать в файл с номером 0. А вот кода станет меньше.

[quote="Хищник"]Зачем вот мне слово более низкого уровня? Сколько помню, проблемы с файловыми операциями заключались в том, что такого файла не было, а это уже не поправить изнутри программы.[/quote]
Слово OPEN-LOGFILE открывает файл и позиционирует на конец, если файла нету — создает его, если позиционировать не удалось — закрывает хэндл (чтобы не было утечки):
[code]: 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 )
;[/code]

Хотелось бы взглянуть на описание этого слова через векторый обработчик и слова вида *-THROW (типа CLOSE-FILE-THROW), не возвращающие ior. Или таки это задача неправильная, и таких слов делать ненадо?

[quote="Хищник"] Если ОС содержит функции работы с файлами, вокруг этих функций необходимо сделать обертки. Кстати, крайне желательно, чтобы обертки были или как можно ближе к родному формату функций ОС, или тогда уж реализовывали некий общий знаменатель.[/quote]
"если скрестить ужа и ежа - получится колючая проволока"... что и имеем
оно так и сделано.

[quote="mOleg"]ну, мне кажется, что вообще работа с файлами - это неизбежное зло.
В форте файлов быть не должно, как и файловых операций все должно быть вокруг слов! [/quote]
В языке - не должно быть. Но мы же делаем систему, работающую в определенном окружении. Если ОС содержит функции работы с файлами, вокруг этих функций необходимо сделать обертки. Кстати, крайне желательно, чтобы обертки были или как можно ближе к родному формату функций ОС, или тогда уж реализовывали некий общий знаменатель.

ну, мне кажется, что вообще работа с файлами - это неизбежное зло.
В форте файлов быть не должно, как и файловых операций 8) все должно быть вокруг слов!
Что же насчет результата операции, то гораздо лучше было бы просто THROW делать.
Хотим ошибки обрабатывать делаем CATCH , не хотим, не обрабатываем 8)

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

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

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

и это не проблема СПФа, а проблема используемого подхода, который, увы, и стандарт зафиксировал

[quote="rvm"]Слова, возвращающие ior не зависят от, и не навязывают выбор механизма обработки исключений, и это правильно. Если бы они вызывали вектор-обработчик вместо возврата ior, то они бы навязывали упомянутый выбор: был бы недостаток в слове более низкого уровня[/quote]
В каких случаях мы кладем поверх фанерного пола линолеум? Да практически во всех - так удобнее. Другое дело, что линолеум не надо прибивать гвоздями или приклеивать суперклеем. Но приводить человека в квартиру с фанерными полами и нештукатуренными стенами ("зато Вы сможете сами выбрать стиль мазков, цвет обоев и фактуру линолеума!") - дело гиблое. Зачем вот мне слово более низкого уровня? Сколько помню, проблемы с файловыми операциями заключались в том, что такого файла не было, а это уже не поправить изнутри программы. Ну разве что создать при отсутствии, но это решается средствами ОС - т.е. форматом вызова функции открытия файла. Что еще может быть? Физическая ошибка на диске? И мы при этом еще трепыхаемся и анализируем ior? Это мне никогда не было понятно. Ну вот дали эту пресловутую "свободу выбора"... и что с ней делать? Каждый раз выбирать (каждый раз поутру стелить линолеум, поверх класть ковры, и только потом ходить)? Наконец, доступ к API никто не закрывает - если нужен такой тщательный анализ низкоуровневых операций, можно и оформить нужные слова вручную.

[quote="Хищник"] FORGET же, как мне думается, съели по причине появления достаточного количества памяти, чтобы безболезненно хранить разные версии слова.[/quote]
ну, для начала, нужно вспомнить, что на место FORGET пришли MARKER

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

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

так вот, мне кажется, что это большая глупость.
Во-первых, Маркеры не проще получаются, да и не на столько удобны,
во-вторых, FORGET тоже надо было немного поменять, не экономить память, а исключать имя из словаря,
не обязательно исключая код...