Очень много текста, извините, не осилил. Верю вам на слово. Только не могу понять как это относится к моему случаю, или к хитростям форта?



Так значит эксель во всём виноват? Я вот так и знал! Емнип, эксель на Windows появился во времена Windows 1-2. Т.е. когда он еще был, по сути, графическим нортон-командером. Да и WinApi в части нативных окон c тех пор изменилось не сильно. Те же вин-проки, та же обработка сообщений, те же классы окон.

С другой стороны - в последнее время, когда мне нужен гуй, я пользуюсь опен-сорс фрэймворками: GTK, wxWidget, tk (тот же самый, что и в tcl/tk), iUP. Это с одной стороны, куда дешевле написания интерфейсов на голом вин-апи, с другой - позволяет надеяться, что программу будет не слишком сложно собрать на системе, где, допустим, GTK есть, а WinAPI - только через вайн. (и тут всё через бутыль делается!)

Никак, просто пример возможности реализации FORTH на любом уровне.

В MS Excel появился MDI - т.е. не равноправие мелких полезных окошек, а одно большое, которое содержит в себе, по сути, целую ОС. Если до этого программист мог спокойно возложить обмен между частями программы на ОС, то после должен реализовать его самостоятельно.

Но...
И... все. Что мешает строить свой язык поверх них? Нет, конечно отдельные команды должны реализовываться на языке более низкого уровня, но интерфейсы обмена (файлы, сообщения, стеки, словари, потоки...) должны быть сущностями, понятными Вашим фреймворкам.

Извините, я немного неправильно выразился - не фреймворками а тулкитами. Из всего перечисленного только у GTK есть родственные библиотеки с таким охватом. Остальные - лишь библиотеки построения оконных интерфейс, без лишних абстракций. Т.е. они берут на себя работу по созданию окон, созданию контролов/виджетов на них, и скрывают реализацию обработки событий, предоставляя на любой системе одинаковый интерфейс.

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

Т.е. существующие +100500 решений меня не устраивают, и я предлагаю свое +100501-е ни с чем не совместимое... И перепишу под него все существующее ПО... Думаю, проще перебрать пару-другую типовых конфигураций.

На хабре покопалсяhttps://habrahabr.ru/post/219139/
Раз быстрее faq6, значит будем его использовать
Переписал на форте
: FAQ6 ( ADDR U - HASH )
>R
0 SWAP
R> 0 DO
DUP I + C@ SWAP >R
+
DUP 10 LSHIFT +
DUP 16 RSHIFT XOR
R>
LOOP
DROP
DUP 3 LSHIFT +
DUP 11 RSHIFT XOR
DUP 15 LSHIFT +
;

Твою функцию протестирую, но уже завтра на работе

Там у ТС проблемы с измерением производительности - в комментариях это указано. ROT13 потенциально быстрее. меньше операций. Но я не настаиваю.

Да, примерно так, за исключением трёх нюансов.

1. На самом деле, достойных решений в этой области удивительно мало. Кроме тех, что я перечислил (и с которыми работал), я знаю еще только два - Qt и FLTK. А если учесть, что tk и iUP на деле не самостоятельны (на windows используют нативные контролы, на юниксах - GTK или (только tk) нативные X-windows контролы, то ситуация с выбором более чем печальная.

2. Я в душе не могу представить, с чем может быть совместима интерфейсная библиотека, кроме программ, которые для неё написаны и операционных/графических подсистем, на которые она портирована. Ну, честное слово - не могу, и всё тут. В любом случае, совместимость и портируемость у такой библиотеки не может быть хуже, чем у голого WinAPI.

3. Я нигде, никоим образом не указывал, что собираюсь вот прямо сейчас писать свой оконный тулкит. Просто сказал, что не хочу делать компонет, который планирую использовать в своем ПО, зависимым от конкретных фреймворков. Да, это очень удобно, но снижает область возможных применений компонента. К тому же я пока не находил удобного конкретно для меня инструмента.

Т.е. до меня наконец дошло - Вы хотите создать универсальный GUI. Не прошло и полгода... По-прежнему остается неясным, будет ли это старый добрый CUA? Или MDI, или еще что? И зачем это надо?
(Например, в недописанном проекте, на который я ссылался, хватило HTML+Perl на удаленном сервере - т.е. совсем, практически, без требований к клиентской части... Однако, сейчас. по-моему и халявный хостинг с Perl найти становится проблемой).

В любом случае, мне кажется, что общий знаменатель лежит уровнем ниже, а конкретное визуальное представление (HTML, Win-API, X) - дело конкретной ОС. Огрызки...

С точки зрения FORTH выглядит естественно ассоциировать системные/оконные события с вводимыми словами, а запросы на ввод (рисующие на экране Controls) - со словами-лейблами. Т.е. программист тупо запрашивает СКОРОСТЬ для определения VELOCITY, а то, что формируется Controls Edit во фрейме КОРАБЛЬ, посылающее по нажатию кнопки ГОТОВО во входной поток слова 3660 VELOCITY ! - это уже должно быть, скорее делом техники, а не визуального редактирования.

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

Про Гуй я упоминал, только что
1. интерпретатор будет работать в основном в составе програм с гуем.
2. В качестве гуя будет эти программы будут использовать какие-либо открытые тулкиты.
3. Тулкит, который бы меня удовлетворял бы полностью я пока не нашел. Это в основном касается интерфейса с программой.

Если немного помечтать о идеальном пользовательском интерфейсе (только немного помечтать, не более того)...

Динамически генерируемый html + браузер, это на самом деле один из самых простых способов сделать приложению красивый гуй. (не важно сетевому или локальному, видел очень много именно локальных программ, пошедших по этому сценарию. Но самый большой плюс этого подхода одновременно и самый большой минус - браузер. Гигантская программа от стороннего производителя, часто и сильно меняющаяся. К тому же таких программ, особенности которых стоит учитывать, как минимум четыре разных реализации.

Слишком сложно, что бы стабильно работать. И ведь не работает стабильно!

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

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

lex + yacc

Как говорит мой начальник... Эм, нет, так, как он это говорит, мне написать заприщают правила форума...

Ну, в общем: а как же получение острого сексуального удовлетворения от процесса?

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

Как раз контроль типов на yacc можно было бы и повесить... Эти программы не очень и сложны (см К&П "Unix" или "Дракона"), но есть хитрость (см. табличку языков) они лежат на ветке компиляторов и, в отличие от FORTH не могут формировать язык постепенно - в них можно закладывать только готовые грамматики.

И, все-таки, рано или поздно Вам придется выбрать 0-уровень языка. Все эти разговоры о всеохватности до добра не доведут.

Если я правильно понимаю, то и YACC, и, тем более, LEX, относятся к языкам программирования в той же степени, что и vi и emacs. На основе сгенерерованных ими синтаксического и грамматического анализатора, можно построить как интерпретатор, так и транслятор. А можно - вообще парсер json-а или html.

Контроль типов - это задача программиста, а не языка. Мне нужно, что бы программист мог узнать, что именно подразумевается под значением (hex) 80ab7413, переданным ему в качестве параметра - Адресс процедуры, Адресс данных, число (dec) 2158720019, число (dec) -2136247277, число (dec) 6,2e-307? Т.е. всего лишь прицепить к ячейке пару байт определения типа. Ну, а что бы форт превратился в лисп остаётся самая малость - добавить в ячейку тип "пара указателей на ячейки" и передавать любой функции всегда один параметр - указатель на первую ячейку списка параметров. Ну и чуть-чуть переписать интерпретатор.


Да. Я оставлю этот выбор, на этап применения языка. Никто же не запрещает делать это на форте?

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

Не совсем так. Они сами компилируются, поэтому "неполную" грамматику ими описать нельзя. А честные интерпретаторы вполне способны работать с неполностью определенными грамматиками и/или доопределять их по ходу дела.

Это обычная несбыточная хотелка (т.к. в ней заложено неустранимое противоречие).


Не совсем. Честный LISP из стандартного FORTH получить затруднительно. Но кому нужен честный LISP? Обычно все проще. Даже, если нужен ИИ (см. "Почти LISP)...

Запрещает. Сначала надо выбрать уровень этого FORTH.

Тогда, в чем проблема выбора уровня? Понимаете, построить честную FORTH-систему (или C-программу), а затем пытаться засунуть в нее интерфейсы, сложно. Поэтому C-программы стараются писать для хороших ОС (POSIX), а FORTH - на "текущем BASIC", т.е. там, где интерфейсы уже в наличии. (В последних двух фразах вместо C/FORTH можно подставить более обще компиляторы/интерпретаторы соответственно).

Ну, если я правильно понял, то на выходе yacc и lex получается Си-код, который в свою очередь можно научить чему угодно =).

В "несбыточной" хотелке противоречия нет. И даже более того - в таком режиме работает целая куча языков - tcl, php, lisp, javascript и многие другие. "Подразумевается" не синоним слова "является".

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

Уровень абстракции для своей системы я уже обозначил - данные в виде абстрактных типизированных ячеек. Интерпретация процедур через байт-код. Возможность прямой работы с памятью через специальное расширение. Интерфейс с языком Си.

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

Ну, например, допустим, у нас уже есть ядерный язык. Мы решаем поэкспериментировать с синтезом звука. Пишем на си расширение для нашего языка, реализующее клиентскую часть к ASIO или ПульсАудио, или DirectAudio, - что сейчас под рукой есть. И расширение заполнения буферов произвольными данными. И этого нам достаточно, что бы начать эксперименты. Встроенной в интерпретатор математики хватает что бы синтезировать базовые формы сигналов и пропускать их через фильтры. В последствии - уже эти кирпичики можно переписать на си для скорости, а на внутреннем языке реализовать секвенсор. Плюс дописать на си интерфейс к midi. Тем же путём добавить красивый гуй. И так далее, постепенно наращивая функционал.

Неправильно. Сначала "научить", а потом "получается". А в интерпретаторах можно учить в процессе.

Есть. Либо типы конторолирует язык (Вы внутри клетки), либо пользователь (Вы снаружи). Говорить после введения тэгов о каком-либо контроле программистом не приходится (C++ лучше знает, что с данным типом делать).

С точностью до наоборот.

И то, и то - не шутка.

Уровень абстракции никого не интересует. Нужно тупо решить, на чем писать.

В том-то и дело: желательно найти уровень, на котором интерфейс уже входит в состав ОС/BASIC. Просто, в силу экономии усилий: согласно Бруксу, такое "расширение программы" утраивает затраты.