Ну чем оно отличается от венгерской нотации? Обьясните, я действительно не вижу разницы. (про вариант возможного использования при переносе не говорю, поскольку он требует 100% дисциплины иначе только палка в колеса).
Дык, все кто говорит про пользу контроля типов и состояния стека в форте.
Ага.
Да, кстати!
Нафиг надо. Оно только красиво выглядит. А пользоваться замучишься... Ничего принципиально не улучшается, некоторые ошибки выявляются быстрее, зато на написание кода тратится больше времени (надо думать какие типы где использовать, то также иногда порождает ошибки, которых в обычном форте быть не может).
Ну и реализация там слабенькая - 16 бит шитый код, если не ошибаюсь.
Зато структура типов, пожалуй наилучшая как для форта. Если бы пришлось делать что-то похожее я бы исходил из нее. Довольно гармонично выглядит.
Точно! Делаем так:

После чего определение, скажем квадрата числа будет выглядеть так:


Вот такие программы глючть не будут по определению!

Возможно и не отличается. Просто в данном случает так удобнее.


А кто жалуется?

Безусловно! Венгерская нотация очень удобная вещь.
...все кто говорит про пользу контроля типов и состояния стека в форте. Иначе зачем оно нужно?

еще раз, КТО ГОВОРИТ? ("а судьи кто?")

в моем случае A@ A! A, ADDR слова были введены не столько для контроля типов, сколько для различения размеров адресных ссылок по сравнению с CELLом. То есть и Венгерская запись не причем, на самом деле, а причем форт-подход.

Не вы. В основном Лёха возмущается.
Уходим от ANSI? Что ж, ваше право, вот только если сохранять совместимость с этим стандартом, то размер ссылки должен быть равен CELLу.
Вергерская нотация, это когда к имени определения (переменной, класса, функции и т.д.) добавляются символы, которые по предварительному согласованию имеют определенную смысловую нагрузку, характеризующую данное определение. Всего лишь. Поэтому то что сделали вы является именно венгерской нотацией, по крайней мере до тех пор, пока никак не влияет на компиляцию кода.

иными словами, обычно фортом возмущаются привыкшие к попсовым ЯП, не разобравшиеся в форте. Им и польская запись мешает, и отсутствие типов, и всяких там ООПов не хватает. Но это как бы сказать, ничего не показывает.


анси мне никогда не нравился.

Да, гдето так.
Ну, про таких даже не говорим. Помнится, лет 20 тому дети средних классов на ура справлялись с БЗ-34, МК-54,56,61,52.
Да, поэтому я и говорю, что не нужно оно. Форт есть таким, это одна из его особенностей, и не получится ее изменить не создав нового языка, который уже не будет Фортом, но и не станет еще Паскалем.
Мне тоже... Но одно дело когда пишешь для себя, а другое дело когда начинаешь думать про развитие... Стандарт нужен. Это факт. Как бы ни хотелось сделать все лучше, без него нет будущего. А что брать за стандарт сегодня, если не ANSI? Других то и кандидатов нет. Да и не в его "хорошести" сила, а в его соблюдении. Есть проблема - на сегодняшний день ANSI сильно недостаточен, он отстал лет на 20 от средних потребностей. Поэтому невозможно ничего серьезного написать что бы не использовало каких либо расширений вне стандарта... Это плохо... В результате стандарте нет. А откуда его взять? Опять собрать коммитет для создания нового ANSI? К сожалению, не получится. На это надо деньги. В конце 80х было много фирм желающих поучаствовать в создании стандарта, были ресурсы. Сегодня, кроме Forth Inc. никого серьзного не осталось... А без стандарта - крышка. Может, конечно, стандарт сформируется сам, просто набрав критическую массу по исходникам, но пока не видать такой перспективы. Похоже, что именно под ANSI существует больше всего (по разнообразию тем, не реализаций) исходников. Хотя, могу ошибаться, слишком много всего в андерграунде запрятано.

Ну - и болты у нас не той системы.

По сравнению с некоторыми, так сказать, лучшими образцами маразма, с которыми я бывало сталкивался, форт-слово на двести строк - это образец ясности, читабельности и понятности. Так что я не возмущаюсь. Я просто пытаюсь понять - есть ли выход из тупика. А вы, граждане, опять скатились к извечному постулату: "раз мы такие крутые - гора сама должна к нам прийти". Не прийдёт. Лет через двадцать Форт будет, возможно, применяться как язык программирования ОЧЕНЬ маломощных микроконтроллеров. Печально, но такова тенденция.

Это из той же темы что небывает плохих штанов - бывают плохие танцоры. Каждый имеет свою точку зрения, и все они в целом субьективны.
"Нет никакой ложки"(с). То есть, нет тупика, нет...
Согласен. Не нравится мне такой постулат.
Во, и мы тут как раз о том думаем, как его сделать применимым для более сложных задач. И у каждого свои идеи: у вас, что надо в корне менять сам язык, правда как, вы пока не знаете, стек адресов вроде показал свою несостоятельность; у меня, что надо приходить к одному, пусть даже плохому стандарту и дальше развивать только его, и прекратить изобретать велосипеды; у некоторых других проскакивает мысль что надо его сделать быстрее за счет оптимизации, или что либ мало, надо наклепать побольше, есть и идея исползования промежуточного кода, причем с намеком на CIL, и так дальше.... Пока думаем...

Мысль совсем старая. Полагаю, именно такая идея двигала людьми, создававшими стандарты для Форта. И каков результат?
Имеем группу стандартов (несовместимых друг с другом!), и реально никакой стандартизации,
потому что Форт изначально в своей основе отвергает стандартизацию, т.к. позволяет программисту делать с собой что угодно.

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

А по сему, надо сначала определить, что же, собственно, надо стандартизировать?
И не надо ли начинать со стандартизации стандартов на стандарты?

п.с. A по поводу "надобности" изобретения велосипедов тема на форуме уже была: http://fforum.winglion.ru/viewtopic.php?t=13

Ну насчёт стеков - ещё вопрос, стоит ли её списывать. А насчёт такого варианта реализации - просто стека - действительно, нужно списать. Но не исключено, что в каком-то виде идея может пригодится. Вообще, держать ВСЁ на одном стеке - другая крайность, но возможно, не такая и глупая... Беда только, что всё не положишь - те же числа с плавающей запятой, например. Пока что вариант со специальными словами A! A@ ..., но работающими с одним стеком - оптимальный, имхо. Если ещё предусмотреть слова-заглушки типа N>A можно сделать тулз (_НЕ_ встроить в компилятор, а сделать подключаемый тулз!), который мог бы проверять ошибки в логике, комментарии преобразований стека и т.п. Имхо - уже что-то...

Насчёт библиотек - частично вы правы. Но имхо, опять же - проблему это не решит, т.к. даже если будет создан некоторый набор библиотек, то чем он будет лучше того, что создано для плюсов? Или для FreePascal? Хороший пример, кстати - язык медленно, но верно развивается. Если мы всё-таки хотим поднять Форт до такого уровня популярности, то он должен давать что-то, чего не дают ни C++, ни Java, ни Pascal, ни скриптовые языки типа Python или Ruby.

Форт уже сейчас эффективная технология.
А популярности ему мешает - "непопулярный" синтаксис.

P.S. И если станет популярным синтаксис используемый Фортом, то многое решится автоматически:)

Брр... Мысль не в том чтобы придумать стандарт, а в том чтобы его соблюдать. А результат таков, что никто их не соблюдает.
Ну, если быть обьективным, то только ANSI еще на что-то годен, ведь нас не интересует 16 битная реализация с шитым кодом (а иначе не получится, если 100% соблюдать 79 или 83)?
Да, он отвергает жесткую стандартизацию, так же как и жесткую типизацию, например. Но это не значит что никто не может соблюдать стандарт сам. Все зависит от программера. В нем проблема. И глюк в развитии форта аналогичен глюку в программе с ошибками типов...
Вот именно.
Вот, вот. Пока не ясно. Хотя, мое предположение таково - мне всеравно как стандартизировать и на что будет похож этот стандарт, главное, чтобы все программы написанные в последствии на Форте можно было использовать с помощюь любого компилятора. Ну, в разумных пределах, конечно, системная и аппаратная зависимость это другой вопрос, главное чтобы не было зависимости от реализации языка.
А вот вопрос на который я ищу ответ, это как такой стандарт воплотить в жизнь, как сделать так, чтобы все его придерживались?
Я опоздал. Прошу прощения.

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

Думаете? Я вот уверен, что синтаксис тут СОВЕРШЕННО ни при чём. По моему опыту - люди могут писать на чём угодно, если это достаточно эффективно для решаемой задачи. Возьмите хоть такой маразм как 1С, и то - пишут.

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

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

Наверное, я несколько сумбурно объясняю... Это трабла большинства технарей. Лучше приведу пример, который часто приходит мне в голову.

Пример такой - операция присваивания. Вариант Сей:

a = b;

Что тут написано? Нечто a будет содержать значение b.

Теперь Форт:

b @ a !

А тут? Взять адрес переменной b, извлечь число, хранящееся по адресу переменной b, взять адрес переменной a, записать число по адресу переменной a. Дополнительно: а и b содержат числа размером одна-ячейка, адрес совместим с размером одна-ячейка. Ещё связанный нюанс - если что-то возвращает две величины, вторая из которых может использоваться первой, то стоит заранее подумать о будущем использовании (и единообразии кода) и, вероятно, поменять их местами - сделать аналогично слова ! .

Вот и получается, что на Сях я говорю ЧТО мне надо сделать, а на Форте - КАК мне надо сделать. И по моему наблюдению, языки всё больше эволюционируют в сторону этого "что надо сделать". Конечно, можно возразить, что Форт несложно, вроде бы, расширить до чего угодно. Но какова цена вопроса? А очень просто - срабатывает "Закон дырявых абстракций". См. http://russian.joelonsoftware.com/Artic ... tions.html, если не знакомы с этим термином. Как результат, имхо, решение на Форте менее продуктивно, чем аналогичный способ описать задачу используя средства другого языка высокого уровня - неважно, используя ли средства самомго языка, или, если это удобнее, написав транслятор с языка описания задачи в этот язык.

В конечном счёте, нахождение баланса между ЧТО и КАК - во многом вопрос компромисса, определяемый, в том числе, и мощностью доступного железа. Этим, думаю, и объясняется популярность скриптовых языков в последние годы. И мне кажется, что для Форта этот путь не закрыт. Должен быть способ в чём-то, наверное, даже упростить его, сделав более продуктивным.

Дык! И приходится учитывать и реализацию и неопределённость стандарта и вообще - какого чёрта я должен знать как они могут быть реализованы? Мне надо два числа сложить!



Логично, в таком случае, просто подключить эти либы как DLL, возможно через переходники.

Только следующим логичным шагом будет отказ от Форта...



Зато здорово ускоряют программиста для ряда задач. В конце концов - зачем всем программам быть быстрыми?