[SBE 1]

А сам язык не расширяли надстройкой, например, для записи формул в обычном виде и необходимым "дизайном привычного вида"

Многие алгоритмы, Форт реализаций функций, уже собраны в проектах Форт библиотек ffl sfl . Если посмотреть в i-Forth там очень много математики реализовано на Форт без "классического" синтаксиса, (может

это эффективнее (или оптимальнее по каким то критериям), чем может создать выполняемый код, например, какой-нибудь взятый Си компилятор)

 

P.S. Разбирать математику может оказаться действительно сложно без применения дополнительного инструментария. Но и в переложении на С уровень реализации, без знания предмета, тоже не такое простое (если же возможно) действие. У математики свой язык оперирования предметной областью, зачастую плохо перекладываемый на компьютерные языки общего назначения. Чему уж тут удивляться или огорчаться.

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

Библиотеки, про которые вы говорите, это для PC, хотя можно оттуда кое-что переносить и в МК. Их пишут на чистом форте для переносимости, и без особых расширений для читабельности.

 

Тут дело не в заумной математике и сложных алгоритмах. А в том, что даже простое выражение с несколькими аргументами, на форте выглядит абракадаброй, густо сдобренной неочевидными стековыми операциями. А уж если там массивы... Посмотрите как это выглядит в исходниках той же ffl, когда справа в комментариях короткая понятная нотация привычного вида, а справа текст форт на несколько строк. Или вот простой расчет выражения от пяти переменных :rolleyes:

(    N = { L1*[X2-X] + L2*[X-X1] } / [X2-X1] )
: MyFunc   ( L2 L1 X2 X1 X --- N )
  DUP ROT -           ( L2 L1 X2 X XX1- )
  ROT ROT -           ( L2 L1 XX1- X2X- )
  OVER OVER +         ( L2 L1  XX1-  X2X-  X2X1- )
  3 ROLL               ( L2 XX1- X2X-  X2X1-  L1  )
  ROT                    ( L2 XX1- X2X1-  L1   X2X- )
  M*                     ( L2 XX1- X2X1-  D_L1*X2X- )
  4 ROLL 4 ROLL       ( X2X1-  D_L1*X2X- L2 XX1- )
  M*                    ( X2X1-  D_L1*X2X- D_L2*XX1- )
  D+                    ( X2X1-  D_L1*X2X-L2*XX1-+ )
  ROT                  ( D_L1*X2X-L2*XX1-+ X2X1-  )
  M/ROUND;

Это может не удачный пример, но проблему манипуляции на стеке с локальными переменными, когда их много, и неочевидности записи выражений он высвечивает. Тоже и с массивами, в чистом виде адресная арифметика.

 

Три десятка килобайт - это "очень" много для Форт применением. (лнейкой конечно не мерил). В реализации Си с использованием Форт схемы, думаю раница окажется не такая существенная.

Это действительно много, у нас проекты были такого порядка. Про то и речь, что для меньшего объема экономии кода нет, а большой попробуй напиши на форте. Лучше сэкономленное время потратить на раздумья по правильной структуре и алгоритмах, можно выиграть больше :rolleyes:

 

Неплохой результатдля ужимания текста в именах слов даёт Radiх кодировка. (вроде 5-ть бит на символ)

А для Forth с его @!+"<>? и т.п. его хватит?

 

Есть и такие варианты, поэтому это не контраргумент.

Мы такой вариант и использовали, кросс-компиляция по делу вещь нужная. Я просто пытался донести несерьезность доводов, что компиляция и сборка совсем не нужны для форта, и это так хорошо и быстро.

 

В этом есть правда (в России тем более) т.к. выход Форт в "массовые" проекты не так уж заметен "невоуружённым" взглядом:). А с какими системами сравнивали? И что больше всего не устроило?

Я искал Форт-систему под свои задачи в конце 90-х, ничего достойного не всплыло. Потом стало не актуально, С/С++ взамен. Тем более, что кое-какое наследство от Форта осталось.

А с чем сравнивать?

 

[ReAl 0]

А для Forth с его @!+"<>? и т.п. его хватит?

RADIX50 это не пять бит на симовл (что невыгодно, пропадает один бит в 16-битном слове). Там 050 (т.е. 40 в десятичной системе счисления) символов кодируется, 40*40*40 = 64000, до 65535 немного пропадает. Но кодирование требует умножения (а раскодирование деления, но если только новые имена кодировать и потом сравнивать со словарными статьями, то раскодировать не надо). Но все равно набор символов сильно ограничен.

 

[Kopa 0]

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

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

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

 

Тут дело не в заумной математике и сложных алгоритмах. А в том, что даже простое выражение с несколькими аргументами, на форте выглядит абракадаброй, густо сдобренной неочевидными стековыми операциями. А уж если там массивы... Посмотрите как это выглядит в исходниках той же ffl, когда справа в комментариях короткая понятная нотация привычного вида, а справа текст форт на несколько строк.

Это правда, но не забываем, что привычный для наших глаз код, пройдёт через "жернова" компилятора и устроит ли конечный вариант

по эффективности ещё неизвестно. (@"Вам ехать, или шашечки") Хотя с Фортом, на не стековой архитектуре потери могут оказаться

катастрофическими и не пригодными для "реального" использования, но проверить какие то "задумки" всё же можно на рабочей библиотеке.

а дальше принять решение по необходимости оптимизации.

(из своей практики, коллега писал фильтрацию на ассемблере, но когда увидел возможность быстро написать Фильтр для неторопливой

задачи на Форте с использованием локальных переменных, то неприменуемо им воспользовался. Си исторически не использовался для

довольно слабого процессора.)

 

Это может не удачный пример, но проблему манипуляции на стеке с локальными переменными, когда их много, и неочевидности записи выражений он высвечивает. Тоже и с массивами, в чистом виде адресная арифметика.

Вполне удачный, только не известно удачнее ли решение (эффективнее) на Форте окажется с использованием локальных переменных

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

оно только и выиграет. При желании можно привлечь "старшего брата" (ака С), для генерации нужного математического кода (хотя это может и выглядеть некошерно)

 

Это действительно много, у нас проекты были такого порядка. Про то и речь, что для меньшего объема экономии кода нет, а большой попробуй напиши на форте. Лучше сэкономленное время потратить на раздумья по правильной структуре и алгоритмах, можно выиграть больше :rolleyes:

Может стоило не только решать "насущные" задачи, но и подумать как с помощью сильных сторон Форта подстроить синтаксис/семантику/

генерацию кода для уменьшения, хотя бы процесса "прототипирования"

 

А для Forth с его @!+"<>? и т.п. его хватит?

Не понял вопрос, например в 16бит (ячейку) утрабуется 3символа и останется 1бит (например как признак ограничитель длины строки)

В две 16битных ячейки уже 6символов и.т.д. Для многих команд Форта может хватить одой ячейки (16 бит)

 

Мы такой вариант и использовали, кросс-компиляция по делу вещь нужная. Я просто пытался донести несерьезность доводов, что компиляция и сборка совсем не нужны для форта, и это так хорошо и быстро.

Конечно нужна если задача плохо решается имеющимися средствами,а что то менять для её "убыстрения" необходимио. Но, кроме

оптимзации, можно пойти по современному подходу "взять контроллер помощнее" или через профилирование набрать статистику

по "узким" местам, могут быть использованы и другие варианты, вплоть до покупки профессиональных средств или введением

в свой генератор кода небольших правил оптимизации целевого кода. (всё зависит от "кривизны" рук пользователя)

 

Я искал Форт-систему под свои задачи в конце 90-х, ничего достойного не всплыло. Потом стало не актуально, С/С++ взамен. Тем более, что кое-какое наследство от Форта осталось.

А с чем сравнивать?

За неимением профессональных средств сравнивать можно только любительские или полупрофессиональные. Для контроллеров

уровень тех и других может оказаться недостаточным. (для LPC есть прошивка без компиляции от MPE Ltd) А так этот вопрос

требует отдельного исследования, хотя достойные варианты для рассмотрения и начальной работы существуют.

Допилить, например, ff303 (в моём случае) вполне возможно, но выбор конкретного Форта дело сугубо индивидуальное. А так как для

PC их очень много, то какие то решения можно и применить для контроллеров (для контроллеров, тоже не малое количество)

 

RADIX50 это не пять бит на симовл (что невыгодно, пропадает один бит в 16-битном слове). Там 050 (т.е. 40 в десятичной системе счисления) символов кодируется, 40*40*40 = 64000, до 65535 немного пропадает. Но кодирование требует умножения (а раскодирование деления, но если только новые имена кодировать и потом сравнивать со словарными статьями, то раскодировать не надо). Но все равно набор символов сильно ограничен.

Когда то разбирался с этим вопросом, но уже подзабыл:) Символов да ограничено, но в каких то вариантах должно хватить и возможно

ещё какие то "извраты" возможны.

Изменено 12 ноября, 2012 пользователем Kopa

[chu 0]

Тут дело не в заумной математике и сложных алгоритмах. А в том, что даже простое выражение с несколькими аргументами, на форте выглядит абракадаброй, густо сдобренной неочевидными стековыми операциями. А уж если там массивы... Посмотрите как это выглядит в исходниках той же ffl, когда справа в комментариях короткая понятная нотация привычного вида, а справа текст форт на несколько строк. Или вот простой расчет выражения от пяти переменных :rolleyes:

(    N = { L1*[X2-X] + L2*[X-X1] } / [X2-X1] )
: MyFunc   ( L2 L1 X2 X1 X --- N )
  DUP ROT -           ( L2 L1 X2 X XX1- )
  ROT ROT -           ( L2 L1 XX1- X2X- )
  OVER OVER +         ( L2 L1  XX1-  X2X-  X2X1- )
  3 ROLL               ( L2 XX1- X2X-  X2X1-  L1  )
  ROT                    ( L2 XX1- X2X1-  L1   X2X- )
  M*                     ( L2 XX1- X2X1-  D_L1*X2X- )
  4 ROLL 4 ROLL       ( X2X1-  D_L1*X2X- L2 XX1- )
  M*                    ( X2X1-  D_L1*X2X- D_L2*XX1- )
  D+                    ( X2X1-  D_L1*X2X-L2*XX1-+ )
  ROT                  ( D_L1*X2X-L2*XX1-+ X2X1-  )
  M/ROUND;

 

Это может не удачный пример, но проблему манипуляции на стеке с локальными переменными, когда их много, и неочевидности записи выражений он высвечивает. Тоже и с массивами, в чистом виде адресная арифметика.

 

И действительно - отвратительно

Прогнал с карандашиком на бумажке, понял , что туфта ( несоответствие м\у выполняемыми операциями и стековыми комментариями ), переписал по своему,

опираясь на N = { L1*[X2-X] + L2*[X-X1] } / [X2-X1]

: MyFunc   ( L2 L1 X2 X1 X --- N )

OVER OVER - >R          \  L2 L1 X2 X1 X ---  R: [x2-x1]  
SWAP OVER SWAP - >R     \  L2 L1 [x2-x]  ---  R: [x2-x1]  [x-x1] 
M*   SWAP R>            \  L1*[x2-x]  L2 [x-x1]  ---  R: [x2-x1] 
M*   D+   R>            \  L1*[x2-x]+L2*[x-x1] [x2-x1]
m/round       \ кажется "нестандартное" слово, впрочем, несущественно
;

( форту должно быть стыдно за "идеологичеки вредный" ROLL)

Не могу сказать, что стало понятнее для "неизвращенного" ума.

Но обычно "фортеры" избегают такого "винегрета на стеке" либо тщательно оптимизируют подобное "жонглирование"

 

 

Смею предположить что в приведенном фрагменте Х - некая измеряемая величина,

L1 L2 - видимо какието коэффициенты, X2 X1 - вероятно, граничные значения параметра Х,

в таком случае (наверняка) L1 L2 X1 X2 хранятся в constant\value\variable виде,

и ничто не мешает иметь

 

: [X2-X1]    X2  X1  - ;
: L1*[X2-X]  ( X -- N1 ) X2 SWAP - L1 M* ;
: L2*[X-X1]  { X -- N2 ) X1 - L2 M* ;

: My_N       ( X -- N  )
 DUP   L1*[X2-X]
 SWAP  L2*[X-X1]
 D+ [X2-X1] m/round
       ;

 

На мой "извращенный" взгляд, стало нагляднее, впрочем - дело вкуса.

 

Хотя и несогласен, я принимаю и уважаю Вашу точку зрения, которую, возможно утрируя, представляю так:

"

Форт - прикольная и любопытная вещица, наподобие "сферического коня в вакууме",

использование которой - бесперспективно, ведет в тупик и способствует "извращению умов".

"

Но есть люди, которые исследуя Forth и применяя его, испытывают ни с чем несравнимое "интеллектуальное удовлетворение",

конечно же неуместное при массовом потоковом производстве...

 

[MrYuran 16]

Я нахожу форт отличным средством для обучения основам, а не верхушкам технологий программирования.

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

Но это я уже повторяюсь.

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

[SBE 1]

И действительно - отвратительно

Прогнал с карандашиком на бумажке, понял , что туфта ( несоответствие м\у выполняемыми операциями и стековыми комментариями ), переписал по своему,

опираясь на N = { L1*[X2-X] + L2*[X-X1] } / [X2-X1]

: MyFunc   ( L2 L1 X2 X1 X --- N )

OVER OVER - >R          \  L2 L1 X2 X1 X ---  R: [x2-x1]  
SWAP OVER SWAP - >R     \  L2 L1 [x2-x]  ---  R: [x2-x1]  [x-x1] 
M*   SWAP R>            \  L1*[x2-x]  L2 [x-x1]  ---  R: [x2-x1] 
M*   D+   R>            \  L1*[x2-x]+L2*[x-x1] [x2-x1]
m/round       \ кажется "нестандартное" слово, впрочем, несущественно
;

( форту должно быть стыдно за "идеологичеки вредный" ROLL)

Не могу сказать, что стало понятнее для "неизвращенного" ума.

Но обычно "фортеры" избегают такого "винегрета на стеке" либо тщательно оптимизируют подобное "жонглирование"

 

Наверно, у вас есть неточность, M* - 32 битный результат, если еще помню. Извиняюсь, привел плохой пример, но суть поясняет - как сложно некоторые простые вещи пишутся на форте. Разворачивать добавляя слова можно, но ясности и простоты может и не добавить, и производительность не улучшит. То же и про оптимизацию "жонглированием", необходимость таковой никак не есть достоинство языка.

 

Я не настолько категоричен, "пусть цветут все цветы". Просто хотел поправить некоторые не очень грамотные суждения о сильных сторонах Forth, применительно к микроконтроллерной практике.

Форт концептуально красив, возня с ним доставляет удовольствие. Действительно, единственный компилятор, который мне по силам написать. Действительно, "живая" интерактивная система почти сразу, можешь одновременно писать и на ассемблере и на своем метаязыке.

Но как рациональный выбор инструмента для реальных задач, за некоторым исключением, Forth ИМХО плохой вариант.

 

Мне сложно судить хорош ли форт для обучения. Это смотря чему обучатся. Если программированию, то зачем на микроконтроллере? Если устройству МК, то почему форт, а не ассемблер или С плюс JTAG? Если с азов, то нотация и стековые навороты форта запудрят новичку мозги. Хотя с другой стороны, я сам когда-то учился программировать на стековой машине советского калькулятора, с сомнительным как видим результатом :rolleyes:

 

Из практических советов порекомендовал бы искать форт-систему, написанную на самом Forth, с исходниками. Разумеется портированную на нужный МК через форт-ассемблер. Глаже решаются вопросы кросс-компиляции, и не нужно использовать другие языки при модификации системы.

Солидно выглядит MPE Forth cross compiler Увы, не бесплатно.

 

Если есть нужна портируемая на разные МК система или желательная связка форта с С (вот тут сила), то лучше брать систему, полностью реализованную на С. Может быть типа pForth - Portable Forth in 'C'

Я использую подобные решения, их легче всего адаптировать под себя. Сам форт конечно будет работать медленнее.

 

 

[chu 0]

Наверно, у вас есть неточность, M* - 32 битный результат, если еще помню.

Да, Вы правы.Это не неточность, а грубая ошибка, которая свидетельствует о том что бардак на стеке - недопустим.

Но, если бы я писал не "умозрительный" а реальный пример, я бы просто протестировал это слово в диалоге с форт-системой на реальных данных.

А сейчас мне стыдно - так облажаться на весь почтенный форум...

А М* - это из Вашего примера.

А второй вариант реализации Вашего примера - форту как то более близок ( я бы сказал - роднее)

Впрочем, это моя, сугубо личная, точка зрения.

PS. Я действительно облажался в первом "примере" со стековыми манипуляциями, мне стыдно.

Первым желанием было - отредактировать текст, но оставил "как есть",пусть эта "лажа" послужит всем примером - "Форт не прощает ошибок".

[Kopa 0]

Действительно, "живая" интерактивная система почти сразу, можешь одновременно писать и на ассемблере и на своем метаязыке.

Но как рациональный выбор инструмента для реальных задач, за некоторым исключением, Forth ИМХО плохой вариант.

Может тогда определить область где c Фортом "уместно" "возиться", а куда, кому и кем (чем) путь закрыт.. И не стоит сопоставлять

умение написать "простейший" Форт компилятор с единственной задачей достойной для его применения.

 

Пока, что кроме "неочевидных" умений по применению набора операций в словах, и отличающегося синтаксиса от общих принципов построения общих языков, мало ИМХО, что прозвучало. При этом для использования или не использования дополнительно локальных переменныхе нет трудностей.

К тому же, например "излишне cтруктурирование" синтаксиса, может ограничить способ поиска приемлемого решения задачи. (не знаю, как точно мыслит программист, но предположу, что удобно решать задачу в рамках необходимой последовательности действий, чем бы она ни была)

Форт имея "простейший" синтаксис способен решать (или всё же с помощью грамотного пользователя) любые задачи используя "минимальные" ресурсы. Мнимым ограничением может представляться, зачастую, необходимость использования "инородного" материала без его преобразования (в том виде как дан) при решении необходимой задачи.

 

Мне сложно судить хорош ли форт для обучения. Это смотря чему обучатся. Если программированию, то зачем на микроконтроллере? Если устройству МК, то почему форт, а не ассемблер или С плюс JTAG? Если с азов, то нотация и стековые навороты форта запудрят новичку мозги. Хотя с другой стороны, я сам когда-то учился программировать на стековой машине советского калькулятора, с сомнительным как видим результатом :rolleyes:

Сложно в целом всегда определять оптимальный путь введения, в ту или иную область знаний. И применение например С со звёздочками,

взятием адреса. пост или пре декремента переменной и др. не так уместны при изучении азов существующих МК. Для МК, чем ближе, проще

к пониманию устройства и принципов функционирования МК тем лучше.

 

P.S. Не знаю поможет ли с пониманием программирования "подрастающему" поколению эксперименты с Форт программированием

в моде Red Power 2 для игры Minecraft, но хочется верить в формирование правильных основ программинга.

Изменено 14 ноября, 2012 пользователем Kopa

[chu 0]

Форт концептуально красив, возня с ним доставляет удовольствие. Действительно, единственный компилятор, который мне по силам написать. Действительно, "живая" интерактивная система почти сразу, можешь одновременно писать и на ассемблере и на своем метаязыке.

Ядро Форта оперирует низкоуровневыми понятиями и ориентировано в основном на поддержку процесса расширения самого себя в любую предметную сторону. Это в чем-то напоминает разум маленького ребенка - он еще ничего не умеет, но самое главное "оптимизирован" на развитие и обучение. Добавляя новые слова в систему, программист обучает Форт новым понятиям и новым лексиконам, постепенно добиваясь ситуации, когда обученный предметной области Форт становится "профессионалом" в этой области и понимает "учителя-программиста" с полуслова. С другой стороны, это означает, что если программист толком не знает, что хочет добиться, то у него ничего и не выйдет - такому Форт покажется непробиваемым тугодумом...

Идеи языка Форт

Красиво сказано. Нравится. А стек и польская нотация - "это не баг, это - фича" :laughing:

[MrYuran 16]

А стек и польская нотация - "это не баг, это - фича" :laughing:

Я вот подумал - а ведь можно сделать JIT-компиляторы для любой архитектуры с абстрактного (но стандартизированного!) форта.

Тогда стек может стать виртуальным, как и связанные с ним издержки.

 

(под PC уже реализовано :) )

 

Кстати, только что получилась логическая цепочка: forth->CIL->mono-> что бы вы думали? LLVM!

Попробую покопать в этом направлении.

[Kopa 0]

Кстати, только что получилась логическая цепочка: forth->CIL->mono-> что бы вы думали? LLVM!

Попробую покопать в этом направлении.

Можно сразу попробовать forth->LLVM byte code LLVM Мощная виртуальная машина для встраивания в ваши приложения

P.S. Ещё по теме Курс п платформе NET

У меня было некоторое желание "покопаться" алгоритмах кодогенерации VFХ (forth от MPE) и в I-Forth, но для RISC контроллеров

это может быть не так пригодно или пойти по пути полуручной оптимизации по шаблонам пробовал кодогенерацию из LLC C в SPF4

 

P.S. Есть в документации LLVM пример стекового языка Stacker: An Example Of Using LLVM

Изменено 14 ноября, 2012 пользователем Kopa

[chu 0]

Зато ужас было писать на форте математику или обработку массивов и структур. И разбирать написанное тоже непросто.

У форта все нормально со сруктурами

Каждый раз с удовольствием использую "нестандартное" слово --

Простота и "элегантность" его определения

: -- create over , + does> @ + ;

Наглядность ( на мой взгляд ) описания структур

\ структуры памяти ds18x2x
  0       \ rom
  1   --   1w_family
  6   --   1w_id#
  1   --   1w_crc
 constant /1w_rom

и применения

create 1w-inpbuf /1w_rom allot  \ объявление буфера и выделение памяти
1w_inpbuf 1w_crc   ( a )  \ адрес байта в котором хранится контрольная сумма принятого от микролан пакета

Изменено 14 ноября, 2012 пользователем chu

[Xenia 35]

C/C++ за оператор goto в свое время полоскали-полоскали, чуть ли не источник всех ошибок в нем видели. Тогда как Forth за его выкрутасы и убить мало! :)

[Kopa 0]

C/C++ за оператор goto в свое время полоскали-полоскали, чуть ли не источник всех ошибок в нем видели. Тогда как Forth за его выкрутасы и убить мало! :)

Ага, полная демократия. На том и стоим. Каждый может видеть "свои" интересные и не так что бы моменты.:)

 

 

Простота и "элегантность" его определения

: -- create over , + does> @ +;

Конструкция

: name create .... does> ... ;

Одна из базовых возможностей (находка Форт) по формированию произвольных данных c именем (чаще всего в "кодофайле")

во время трансляции программы (слова между CREATE ...и... DOES> ) и обработка их словами после does> адрес данных которых

передаётся на стек (неявно для пользователя) словам после маркерного слова does> при вызове сформированного по имени слова (сформированного словом CREATE и дальнейшей последовательностью действий до слова-ограничителя DOES>).

Слово CREATE при вызове name берёт следующее слово из входного потока при исполнении созданного определения.

 

Понятно или необходимо лучшее объяснение?

 

В книге Баранова/Ноздрунова этот момент описан как мощный базовый принцип по частичной параметризации кода

(вроде так) При этом, слова после does> могут сделать "всё что угодно при исполнении" (впрочем как и при трансляции слова) т.к. имеют доступ к текущим данным на стеке и "ресурсам" в Форт системе, а также к контексу вызова данного слова. (контекст вызова для Форт слов может изменяться, и соответственно слова могут "подстраиваться" под контекст вызова, иметь ограничения по контексту использования или активно менять существующий контекст)

 

Простейшее определение Форт слова CONSTANT можно ввести так

 
:  CONSTANT  ,  DOES>  @;

и вариант использования

 12345 CONSTANT ABCDE

 ABCDE

положит на стек число 12345

Изменено 14 ноября, 2012 пользователем Kopa

[SBE 1]

У форта все нормально со сруктурами

Был неправ насчет этого. Посмотрел, в том числе и для работы с С-стилем структур есть дополнения. Не такие простые и изящные, конечно. Ваш код разобрать уже не способен, такое помнишь только пока работаешь :rolleyes: . Тоже не лучшее свойство языка.

 

 

 

 

C/C++ за оператор goto в свое время полоскали-полоскали, чуть ли не источник всех ошибок в нем видели. Тогда как Forth за его выкрутасы и убить мало! :)

Как не странно, на практике применение Forth давало довольно безошибочный результирующий код, как у меня, так и у коллеги. Видимо, потому, написание на форте требовало предельной мобилизации всех сил организма :rolleyes:

Если серьезно, то помимо мобилизации и погружения, играла роль и интерактивность, и то что на форте удобнее писать короткими простыми словами. Само собой получается идеологически ближе к TDD. Ну и просто писали меньше и медленнее.

 

Хотя бытующее утверждение, что "Форт не скрывает ошибки...поскольку ошибки мгновенно «обрушивают» программу" , по моему очень сомнительно. Это примерно как сказать, что работа с указателями не скрывает ошибок, поскольку ошибочное обращение мгновенно выдаст исключение доступа к памяти.