Что такое FORTH?

Перейти вниз

Что такое FORTH?

Сообщение автор Gudleifr в Ср Мар 29, 2017 11:46 am

FORTH - это простейший интерпретатор:


Устроен он примерно так:


Т.е. это простейший способ реализовать цикл (рисунок из TF Броуди):


Последний раз редактировалось: Gudleifr (Вт Май 15, 2018 11:23 am), всего редактировалось 2 раз(а)
avatar
Gudleifr
Admin

Сообщения : 912
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Что такое FORTH?

Сообщение автор Gudleifr в Пт Мар 31, 2017 9:58 am

ИНТЕРПРЕТАТОР ИНТЕРПРЕТАТОРОВ
* "FORTH - язык: изобретен в 1971 году Чарльзом Муром для управления телескопом /lurkmore/".
Во-первых, Мур работал в обсерватории не в 71-м, а в 58-м; во-вторых даже версия-прародитель FORTH 58-го года не была предназначена для управления телескопом; в-третьих, похоже, Мур реализовал FORTH, но никак не изобрел, и, наконец, FORTH - не язык!
* Что же такое FORTH?
По Муру, метод написания "хороших" программ. Не язык, не операционная система, не среда программирования... Метод! Однако, что это за метод, если его "каждый понимает по-своему"? Если он практически не имеет обязательных рекомендаций?
* Я предлагаю следующее "определение": имеем A (язык машины), пишем на нем на коленке за неделю язык F (FORTH), затем на нем - P (проблемно-ориентированный язык), отдаем последний пользователю для решения своих задач. (Концепция тупого программиста и умного пользователя).
* Отсюда: F должен быть максимально прост (если он сравним по сложности с P, то проще сразу P и реализовать) и настолько универсален, что бы его можно реализовать для любого A.
* Что можно выиграть от A=F (FORTH-процессор)? Почти ничего. Вот от процессора, ориентированного сразу на P выигрыш велик...
* Соглауется ли мое определение с принципами Мура?
Термин "проблемно-ориентированный язык" (P), по крайней мере, Мур использовал.
Основным Принципом (с большой буквы) Мур считает простоту. Так что мое "за неделю, на коленке" вполне соответствует Муру.
Следствием Основного Принципа Мур считал отказ от написания программ заранее, от предвосхищения будущих задач. У меня, очевидно, тоже самое: нет потребности в P - нет и F.
* "FORTH очень быстр и компактен" - любят говорить фортеры. Однако, забывают уточнить, что подразумевается не столько ресурсопотребление FORTH-программ, сколько быстрота их написания/правки и малый объем программных текстов.
Последнее особенно важно - чем компактнее наши программы, тем больше мы успеем написать до того момента, когда сложность программного текста превысит нашу способность его осмыслить.
* Мур говорил: "Сделай сам!" (и считал это еще одним следствием Основного Принципа). Это и давало упоминаемую "простоту компактности": FORTH-программы состоят только из того, что в них понапихал сам программист.
Ему не нужно обеспечивать совместимость с чужим кодом, наследовать/настраивать его, использовать навязанные парадигмы...
Программа на FORTH - это, по-сути, объяснение программиста самому себе решения задачи в свободной форме.
(Однако, когда FORTH-метод реализуется не на "голом железе", возникает проблема: жертвовать долей простоты, явно предоставляя программе интерфейсы с чужим кодом, либо спрятать эти интерфейсы внутрь FORTH-машины, жертвуя "всемогуществом" программиста).
* А как быть со сложностью интерфейса "машина-пользователь"? Мы же привыкли, что "только жутко тормозная и заумно навороченная ОС Windows обладает всеми необходимыми драйверами и визуальными инструментами для обеспечения пользователю хоть какого-то комфорта".
А, никак! Простейший интерпретатор на то и простейший, что сводит общение программы с пользователем до необходимого минимума. А его обеспечить просто.

Сколько слов, а о FORTH еще ничего и не сказано! Что же это такое?

Фортеры обычно говорят: во-первых, создаем некоторую структуру данных (СТЕК) предназначенную для обмена данными между процедурами-СЛОВАМИ. Теперь нам не надо долго описывать параметры и возвращаемые значения функций. Любое СЛОВО берет со СТЕКА то, что ей надо, и запихивает туда же результат. Второй плюс - теперь не надо изобретать имена для локальных переменных - кидаем на СТЕК значение, а когда понадобится - снимаем.
Во-вторых, создаем другую структуру данных (обычно, список) - СЛОВАРЬ, в которую вписываем код процедур СЛОВ в некотором определенном (называется ШИТЫМ КОДОМ) формате. Так как списка параметров нет, то единственное, что нужно знать компилятору о СЛОВЕ - адрес процедуры в памяти. Так, что ШИТЫЙ КОД, обычно,- просто последовательность адресов процедур СЛОВ.
В-третьих, механизмы доступа к обоим структурам ПРОШИВАЮТСЯ согласно пункту "во-вторых" и объявляются общедоступными.
Все!

FORTH ли это?
Вернемся к общей теории интерпретаторов. Интерпретатор читает откуда-то (здесь и далее ПОТОК) текст программы (СЛОВА) и, по мере прочтения, законченных команд, последние исполняет (процедура ВЫПОЛНИТЬ).
Прочтенная информация в общем случае накапливается в жуткой древообразной структуре (ср. дерево грамматического разбора). А процедура ВЫПОЛНИТЬ занимается тем, что в этом дереве производит какие-то "свертки и развертки".
Например, "ВЫПОЛНИТЬ выражение" означает взять всю "ветку", на которой "висят" все операции и операнды выражения, и свернуть ее в один несчастный "лист" - значение полученное при вычислении.
А в FORTH? Как мы заменили дерево на СТЕК? Очень просто: отказались от грамматики, т.е., грубо говоря, от "забегания вперед".
Нельзя вводить СЛОВА, которых интерпретатор еще не знает, нельзя вводить имя вычисляемой функции раньше значений параметров, нельзя, наконец, вводить арифметические операции раньше чисел, над которыми они выполняются.
И назвали это "обратной польской записью"... (И поняли, что это хорошо, что бы ни говорили любители "нормальных" языков).
Но как будет ориентироваться в СТЕКЕ процедура ВЫПОЛНИТЬ? Никак! Она может всего две вещи - помещать на стек значения и выполнять "СЛОВА по адресу" (значение от СЛОВА она отличить способна).
Т.е. любая обработка значений на СТЕКЕ должна быть явно прошита в СЛОВАРЕ. Но, т.к. грамматики нет, то вариант обработки всего один: взять со СТЕКА параметры, обработать, положить результат на СТЕК. О том, чтобы результаты одной обработки были правильными параметрами для следующей, должен заботиться сам программист (и/или пользователь).
Примерно это и изложил Дейкстра за 8 лет до официального явления FORTH. (Понятно, гораздо литературнее меня). Причем, он установил три железных принципа, которые нельзя нарушать без того, чтобы FORTH перестал быть самим собой.
* Во-первых, ячейка СТЕКА должна быть способна содержать значение любого из "системных" типов, минимум - числовые значения и адреса СЛОВ.
* Во-вторых, каждое известное FORTH-системе СЛОВО (в смысле - строка литер) однозначно переводится в адрес его кода в СЛОВАРЕ.
* В-третьих, процедура ВЫПОЛНИТЬ должна уметь различать адреса СЛОВ, которые надо обработать, от СЛОВ, которые надо исполнить немедленно.

"А какого уровня должен быть язык FORTH?"
"Дурацкий вопрос",- отвечают фортеры: "Он позволяет, как напрямую работать с железом, так и понимать практически человеческую речь".
Это не совсем правда. В зависимости от того, на каком A написан F и насколько фортер понимает высокоуровневость P, заявленный диапазон может быть как широким, так и очень узким. (Сейчас очень часто нижняя граница - библиотеки языка C, а верхняя - C++ -подобный текст).
Но, зато, уникальное отсутствие синтаксиса (просто СЛОВА/литералы, разделенные пробелами) позволяют на FORTH естественно говорить о самых разных вещах: запуске программных процессов, машинных кодах, грамматическом разборе, документировании, "капусте, королях"...
avatar
Gudleifr
Admin

Сообщения : 912
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Что такое FORTH?

Сообщение автор Gudleifr в Пт Мар 31, 2017 10:02 am

КОМПИЛЯТОР КОМПИЛЯТОРОВ
* Обычно фортеры очень любят рассуждать о том, что FORTH "на самом деле" компилятор.
И что он умеет "расти" и "самообучаться"...
Как будто другие интерпретаторы не умеют определять функции и подпрограммы.
И как будто мало интерпретаторов умеют "компилировать" программы в байт-код.
И как будто они не умеют это делать, не прерывая диалога с пользователем...
Отличие FORTH-компиляции от "обычной для интерпретаторов" только в одном - он это делает простейшим образом (ШИТЫМ КОДОМ), пытаясь всю работу переложить на средства A.
* Увлечение языковыми нюансами FORTH часто приводит к идее построения для FORTH "правильного" компилятора. И сведения языка P к одному единственному СЛОВУ - "GO" (и даже целевой компиляции FORTH-системы вместе с программой в исполняемый файл).
В этом случае теряется сама идея метода - игра "программист-пользователь" превращается в игру программиста самого с собой. Интересно, забавно, но непродуктивно...
* Компиляция FORTH существует в трех ипостасях: во-первых, сборка новых СЛОВ как "макросов" из уже определенных, во-вторых, создание низкоуровневых "кодовых" СЛОВ на языке A (некоторые фортеры терпеть этого не могут), в третьих, создание СЛОВ, которые могут создавать другие СЛОВА.
Последнее позволяет несколько разнообразить примитивный F-язык замысловатыми грамматическими "оборотами" и "предложениями", но может вконец запутать начинающего фортера этакой "рекурсией": что происходит в период компиляции СЛОВА, создающего компилирующие СЛОВА?
avatar
Gudleifr
Admin

Сообщения : 912
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Что такое FORTH?

Сообщение автор Gudleifr в Пт Мар 31, 2017 10:21 am

МОЯ ИСТОРИЯ  
Когда мне в первый раз показали FORTH (на Spectrum), мне показалось, что это та самая простота, которая хуже воровства.
Вскоре свалился с простудой и от нечего делать прочел книгу Броуди (для начинающих) - зацепило. Оказалось, что я могу написать компилятор сам, а не пользоваться убожеством, доступным мне сейчас (1989 год - в моем распоряжении польский клон IBM XT с установленным Basic, затем добавился Turbo Pascal).
Попробовал писать прямо в кодах (в DOS debug). Получалось, но муторно. Раздобыл masm. Работа пошла быстрее и скоро моя FORTH система (FOBOS), являющаяся неким клоном системы, предложенной в книге Баранова и Ноздрунова, была готова.
Больших проектов я на FOBOS не писал, но, играя с ним, получил массу удовольствия.
Затем проект был надолго заброшен.
***
В начале 2000-х столкнулся с проблемой. Создав свою Internet-страницу, понял, что, кроме текстов и картинок, хочу выкладывать и некоторые алгоритмы и программы. Правилами бесплатного хостинга обычно запрещается выкладывать исполняемые файлы и архивы. Значит, готовые к употреблению win-exe-файлы выложить не удастся.
Перешел к созданию CGI-файлов. Неудобно - играть с моими программками можно только в режиме online, тратя свой Internet-трафик. Плюс, правила выкладывания CGI-программ на бесплатных хостингах имеют свойство "плавать", что приводит к необходимости постоянно отслеживать их работоспособность и, даже, иногда переписывать их с языка на язык.
Гнаться за новыми версиями Internet-browser-ов, используя все возможности Java-script, Flash и прочих встроенных Basic-ов? Это значит а) ограничивать свою аудиторию только "продвинутыми" пользователями и б) погрузиться в изучение этих убогих языков.
***
Решил следующее. Написать минимальное FORTH-ядро и откомпилировать его в win-exe. Остальную часть FORTH-системы оформить в виде обычного текстового файла. Exe-ядро превратить в текстовый файл (содержащий текстовое представление бинарных кодов), из которого можно собрать исполняемый при помощи простейшего DOS-овского debug. Выложить оба текстовых файла (плюс файл с исходным текстом ядра на языке ассемблера) в Сеть.
Плюс такого подхода очевиден - полная свобода просмотра и редактирования кода пользователем. Дополнительно, доведя до ума свой FORTH, я смогу больше не мучиться с выбором: быстренько слепить что-то в Borland или MS Studio, или лучше - на Perl под Tcl/Tk?
Минус тоже вполне очевиден. Я заведомо ограничил себя Win-32. Сначала хотел переписать и под Linux. Но, там проблема стоит не столь остро - исходные тексты на C, Perl и Tcl/Tk понимаются всеми nix-ами однозначно. Да и способов создать проблемно-ориентированный язык там пруд-пруди.
***
Постепенно создание красивого интерфейса с Win32 превратилось в самоцель.
***
Когда-нибудь, это войдет в третий том моих заметок о старых играх...


Последний раз редактировалось: Gudleifr (Пт Июн 30, 2017 5:40 pm), всего редактировалось 2 раз(а)
avatar
Gudleifr
Admin

Сообщения : 912
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Что такое FORTH?

Сообщение автор Gudleifr в Пт Июн 30, 2017 11:56 am

ПРИЛОЖЕНИЕ. ВВЕДЕНИЕ ИЗ КНИГИ
PROGRAMMING A PROBLEM-ORIENTED-LANGUAGE
CHARLES H.MOORE
written ~ June 1970

Я не знаю, зачем вы читаете эту книгу. Зачем тогда я ее пишу? Давайте прочтем название: "Программирование проблемно-ориентированного языка". Ключевое слово здесь "программирование". Я написал много программ за эти годы. Я пробовал писать хорошие программы, и я достаточно критически относился к своему стилю. Хотелось уменьшить затраты на писание и повысить качество написанного. Заметил, что определенные ошибки совершаю неоднократно. Ошибки, очевидные при повторном чтении программы, но трудно избегаемые в контексте писания. Я подумал, что мог бы составить сам для себя предписание, напоминающее об этих проблемах. И если оно будет полезно для меня, то должно быть полезно и другим: если вы не знакомы с предметом - узнаете что-то новое, если знакомы - познакомитесь с новой точкой зрения.

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

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

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

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

ОСНОВНОЙ ПРИНЦИП

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

Итак я определяю Основной Принцип:
ПУСТЬ БУДЕТ ПРОСТО
При увеличении возможностей программы ее сложность растет по экспоненте. Согласованность составляющих или даже внутренняя логика программы может легко выйти из-под контроля. Основной Принцип нужен для того, чтобы избежать этой проблемы. Все знакомы с операционной системой, которая его игнорировала.

К ней очень трудно приноровиться. Большая часть вашей программы нужна для соблюдения соглашений операционной системы и соглашений вашего языка. В конце концов, требуется всего полдюжины операций, так зачем же писать лишнее? Единственная ваша возможность противостоять росту сложности под давлением внешних соглашений - Основной Принцип.

Чтобы облегчить применение Основного Принципа, я собираюсь предложить вам несколько инструкций. Увеличит ли их применение размер программы? Нет, размер программы зависит только от сложности задачи. За это я могу поручиться, т.к. проверил на себе. Все, о чем мы будем говорить, прекрасно

Основной Принцип имеет следствие:
НЕ ПРЕДПОЛАГАЙТЕ!
Не пишите код, который может пригодиться когда-то в будущем. Не оставляйте заплаток для будущих расширений. Вещей, которые вы можете захотеть сделать, бесконечное множество; это означает, что каждая из них имеет нулевую вероятности осуществления. Если вам что-то понадобится позже, вы это и запрограммируете позже - и, вероятно, лучше, чем сделали бы это теперь. И если кто-нибудь будет расширять вашу программу, он заметит оставленные вами для этого заплатки? Все ли из них вы аккуратно задокументируете?

Основной Принцип имеет еще следствие:
СДЕЛАЙТЕ ЭТО САМИ!
Теперь мы спускаемся на уровень практики. Это - наш первый вызов сообществу. Общепринято, что вы должны использовать стандартные подпрограммы. Я говорю, что вы должны писать ваши собственные подпрограммы. Конечно, вы должны уметь это делать. Т.е. надо научиться, а это трудно. Хотя бы, попытайтесь. По прошествии лет перебора языков и компьютеров станет легче. Если вы не собираетесь уделять программированию столько времени, эта книга не для вас.

Какие подпрограммы вы должны писать сами? Я уважаю подпрограмму SQRT. Она написана хитро и талантливо. Вы можете использовать библиотечные подпрограммы с большим успехом. А подпрограммы ввода? Они тупы до безобразия. Я не могу поверить, что последнее слово в этом вопросе было сказано изобретением 15 лет назад оператора FORMAT.

Как я разъясню позднее, подпрограммы ввода - наиболее важный код вашей программы. В конце концов, никто не видит вашу программу, но каждый видит ваш ввод. И разрешать заниматься этим стандартным подпрограммам - глупо. Тот же самое можно сказать о подпрограммах вывода и доступа к диску.

Более того, задача не такая уж и сложная. Хотя требуются сотни инструкций, чтобы написать общую подпрограмму, вам - для написания частной - понадобятся только десятки. Я, вообще, против написания подпрограмм длиннее сотни инструкций.

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

Но что будет, если каждый будет писать свои подпрограммы? Это шаг назад; скоро миллениум, когда программы станут машинно независимы, когда все мы будем писать на одном и том же языке, возможно, даже на одном и том же компьютере? Что сказать? Я не могу решить все проблемы мира. Если повезет, я могу написать хорошую программу.

ОБЗОР

Я собираюсь рассказать вам, как написать программу. Это - определенная программа; т.е. программа с определенной структурой и возможностями. В частности, это - программа, которая может быть строго определенным способом расширена до целого комплекса, и, соответственно, стать способной решать комплексные проблемы. Одна из проблем, которые придется рассмотреть - проблема сложности. Как вы можете управлять вашей программой так, чтобы она осталась простой? Сначала я попробую абстрагироваться от проблем ввода. Правда, так как эти проблемы очень важны, долго рассматривать программы без ввода не получится.

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

Следующий шаг - проблемно-ориентированный язык. Разрешая программе динамически изменять свой язык управления, мы получаем качественное изменение способностей. Так мы переключаем наше внимание с программы на язык управления. Это и важно, и опасно. Здесь очень легко потерять из виду проблему, увлекшись красотой решения.

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

Проблемно-ориентированный язык может описать любую проблему, из тех, с которыми я сталкивался. И помните, мы занимаемся не языком, но программой, которая реализует язык. Изменяя язык, мы можем применять ту же самую программу для других целей. Однако имеется класс расширений языка, которые дают новое качество. Они не увеличивают применимость программы, но расширяют способности языка. Делают язык более выразительным. Мы рассмотрим некоторые из таких расширений в Главе 8. Я собрал их вместе, в основном, потому, что одинаково их недопонимаю. Например, я думаю, что язык нужно обсуждать в концепциях человеческих языков.

Наконец, я хочу описать процесс реализации программы на языке машины. Т.е. процесс загрузки и саморазвертывания программы.

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

Пытаясь говорить просто, я затянул свои объяснения. Я надеюсь, что вы не сочтете это злостным нарушением Основного Принципа. Легче было сказать обо всем этом сейчас, чем возвращаться потом. Если вам действительно удобно, вы можете использовать мои подпрограммы. Но, если вы путаете то, что полезно, с тем, что необходимо, ваши программы будут расти бесконечно.

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

Целиком книга тут - TXT, 0.4Мб


Последний раз редактировалось: Gudleifr (Ср Дек 06, 2017 12:13 pm), всего редактировалось 3 раз(а)
avatar
Gudleifr
Admin

Сообщения : 912
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Что такое FORTH?

Сообщение автор Gudleifr в Вт Авг 29, 2017 6:59 pm

Раз уж, разговор зашел о первоисточниках, то:

Это альфа и омега. Читать обязательно. Все что я встречал, кроме этого - в лучшем случае, рассуждения "а я бы сделал вот так".

1. Э.В.ДЕЙКСТРА - 1962 -- Математическое обоснование (ТЕМА #38).
2. CHARLES H.MOORE PROGRAMMING A PROBLEM-ORIENTED-LANGUAGE -- Первый работающий вариант (см. предыдущий пост - ТЕМА #3, АБЗАЦ #222).
3. LEO BRODIE STARTING FORTH -- Учебник для начинающих (CHM, 1.47Мб).
4. LEO BRODIE THINKING FORTH -- Философское обоснование (DOC, 3.98Мб).
5. С.Н.БАРАНОВ И Н.Р.НОЗДРУНОВ ЯЗЫК ФОРТ И ЕГО РЕАЛИЗАЦИИ -- Техническое описание (DJVU, 1.32Мб).

Как я их читал сам? Сначала (5) и остался в недоумении. Зачем все это нужно? В чем смысл?
Потом попалась (3). Понял, что FORTH это - здорово. Срочно надо его где-то брать. Как где?! В (5) есть же полный рецепт изготовления! Потом читал много разного, но ничего особо интересного не попалось.
Вдруг нашел (4). Надо же! Я всегда это говорил! Автор связно и логично изложил то, что мне только смутно мерещилось. (Это позднее я понял, что автор остановился слишком рано).
Затем попалось (2). Вот, откуда ноги растут! Все эти модные рассуждения всего-лишь смутные тени того, что планировалось изначально. Но, чего-то не хватает. Как-то странно автор пропускает обоснование своих основных решений.
Наконец, нашлось (1). Вот, чьи это уши! Вот о чем в (2) скромно умалчивалось!
avatar
Gudleifr
Admin

Сообщения : 912
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Что такое FORTH?

Сообщение автор Спонсируемый контент


Спонсируемый контент


Вернуться к началу Перейти вниз

Вернуться к началу


 
Права доступа к этому форуму:
Вы не можете отвечать на сообщения