Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 03:49

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - Новые диалекты Форта. ColorForth и др.
Автор Сообщение
  Заголовок сообщения:   Ответить с цитатой
Владимир писал(а):
Что касается диалектов, то Форт сам по себе настолько гибок, что вместо того, чтобы разрабатывать очередной диалект, можно просто реализовать нужную функциональность в виде словаря.

Да, функционально можно сделать то же самое. У меня даже пара версий есть... ;) А при реализации, которую нужно "поджать" для микроконтроллера или ПЛИС - прийдется таки переработать всю Форт-систему... :)
Сообщение Добавлено: Пн июн 25, 2007 18:25
  Заголовок сообщения:   Ответить с цитатой
Цитата:
Форт развивается. Стоит ли использовать новые диалекты?

Если это кому-либо необходимо, то почему бы и нет? Главное, чтобы польза была.
А вот лично мне нужен голый ANS-Forth. И доп.словари, делающие из такого минимального Форта нужный мне DSL. Всё. Мне этого хватит "за глаза".
Что касается диалектов, то Форт сам по себе настолько гибок, что вместо того, чтобы разрабатывать очередной диалект, можно просто реализовать нужную функциональность в виде словаря. :work;
Имхо :shuffle;
Сообщение Добавлено: Пн июн 25, 2007 14:48
  Заголовок сообщения:   Ответить с цитатой
Хищник писал(а):
Думается, state-smart все же терпимы.... Но все равно интересно, как без них.

STATE задает как бы контекст, в котором слова имеют другой смысл, разный для разного значения STATE - либо интерпретировать, либо компилировать, и оно общее для всех слов.
В CF цвет задает способ использования конкретного слова - то ли его использовать как имя нового определения (реально - как начальный адрес), то ли компилировать, то ли исполнить. Еще можно компилировать макрос. Ну, есть и несколько вариантов комментариев.
Мур(еще с cmForth), убрал STATE (вернее, IMMEDIATE), используя разные словари для компиляции и интерпретации.
Я убрал STATE , сделав отдельно цикл интерпретации и цикл исполнения. А слова [ ] ], переключают эти циклы. Систему планировалось использовать в виде простых текстов, поэтому о разных цветах и шрифтах речь даже не шла. Префиксы перед каждым словом мне тоже не понравились. Поэтому я продлил действие состояний. Т.о. у меня все же используется аналог STATE , но не флагом, а сразу значением - соответствующим состоянию циклом обработки - циклом интерпретации или циклом компиляции.
Потом уже я увидел пример profit-а с суффиксами, он мне понравился. ;)
profiT писал(а):
И вообще, у меня уверенность что кто-то из "классиков" однозначно выразил своё "фи" state-smart словам.

Да:
Броуди, глава 8. писал(а):
СОВЕТ
Слова не должны зависеть от переменной STATE, если
программист собирается когда-либо использовать их для
вызова из высокоуровневого определения и при этом ожидает
получить от них такое же поведение, как и при
интерпретации.

А неприятность STATE-зависимых слов в том, что получается неожиданное поведение. Ты хочешь прикомпилировать слово, а оно почему-то выполняется... ;)
И сложность - больше анализа, больше сложность, меньше эффективность, больше код...
Сообщение Добавлено: Пн апр 16, 2007 03:45
  Заголовок сообщения:   Ответить с цитатой
rvm писал(а):
По моему, дело более даже в признаке IMMEDIATE

rvm писал(а):
А упомянутое POSTPONE анализирует у аргумента как раз признак IMMEDIATE, а не STATE.

кстати да!
Действительно проблема у POSTPONE не столько в анализе STATE сколько в анализе типа слова. Этой проблемы нет у слов однозначно выполняющих свои действия над другими словами, как TO IS COMPILE ['] [COMPILE] и что там еще 8)
Сообщение Добавлено: Вс апр 15, 2007 22:31
  Заголовок сообщения:   Ответить с цитатой
Цитата:
вызванного открытым ящиком Пандоры -- state-smart словами

По моему, дело более даже в признаке IMMEDIATE (который жестко привязан к слову), а не в анализе STATE. Например, photonInterpreter анализирует признак, заданный отступами, а startColorSPF добавляет анализ признака, представленного суфиксом слов. STATE — это аналогичный признак, он лишь по другому задается и абстрагирован от синтаксиса.

А упомянутое POSTPONE анализирует у аргумента как раз признак IMMEDIATE, а не STATE.

В свою очередь, признак IMMEDIATE — это лишь одно из возможных решений задачи маскировки для "мультиплексирования" входного потока, совмещения в нем "обычного" и "управляющего" потоков. Цвета — другое решение той же задачи. XML — еще одно решение, очень емкое в силу естественных иерархичности и возможностей маскировки. Оно позволяет легко мультиплексировать произвольно много под-потоков, лишь бы структура оставалалсь "деревом".
Сообщение Добавлено: Вс апр 15, 2007 16:51
  Заголовок сообщения:   Ответить с цитатой
profiT писал(а):
mOleg писал(а):
И дело не в том, что оно STATE SMART !

Оно сделано "шибко вумным" потому что вообще есть "шибко вумные" слова, анализирующие STATE. Если есть хотя бы одно state-smart слова -- будут хаки, будут "обходы", будут глюки, будут нестыковки в логике.

оно сделано слишком умным - оно получается умнее меня - а это не порядок.
Других таких слов в стандартном форте к счастью нет

profiT писал(а):
mOleg писал(а):
[COMPILE] TO - должно работать, нет, даже обязано!

Э-э, нет.. Тут вам не здесь.. Мне нужно скомпилировать слово TO, а не компилировать слово компилирующее слово (TO) (например, зависит от реализации).

поясни! какая разница?

profiT писал(а):
И за [COMPILE] спасибо -- это как раз ярчайший пример идиотизма вызванного вызванного открытым ящиком Пандоры -- state-smart словами.

а мне нравится именно пара [compile] compile а не гадкий POSTPONE

Хищник писал(а):
Думается, state-smart все же терпимы.... Но все равно интересно, как без них. Видимо, я сильно упустил начало обсуждения.

вообще тут по-моему просто раздутая проблема. STATE переменная очень проста и понятна, а главное надежна - т.к. она одна - пусть даже имеющая много состояний. А вот когда контексты начинают выполнять ее роль, то может получиться очень даже неудобная штука.
Сообщение Добавлено: Вс апр 15, 2007 02:09
  Заголовок сообщения:   Ответить с цитатой
Думается, state-smart все же терпимы.... Но все равно интересно, как без них. Видимо, я сильно упусти л начало обсуждения.
Сообщение Добавлено: Вс апр 15, 2007 01:19
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
И дело не в том, что оно STATE SMART !

Оно сделано "шибко вумным" потому что вообще есть "шибко вумные" слова, анализирующие STATE. Если есть хотя бы одно state-smart слова -- будут хаки, будут "обходы", будут глюки, будут нестыковки в логике.

mOleg писал(а):
[COMPILE] TO - должно работать, нет, даже обязано!

Э-э, нет.. Тут вам не здесь.. Мне нужно скомпилировать слово TO, а не компилировать слово компилирующее слово (TO) (например, зависит от реализации).

И за [COMPILE] спасибо -- это как раз ярчайший пример идиотизма вызванного вызванного открытым ящиком Пандоры -- state-smart словами.
Сообщение Добавлено: Вс апр 15, 2007 01:12
  Заголовок сообщения:   Ответить с цитатой
profiT писал(а):
mOleg писал(а):
Мне нравятся эти самые StateSmart слова.

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

POSTPONE - это действительно гадость. Но это редкое исключение.
И дело не в том, что оно STATE SMART !

profiT писал(а):
Попробуй скомпилировать слово TO.

[COMPILE] TO - должно работать, нет, даже обязано!

profiT писал(а):
Или попробуй однозначно, чётко, надёжно и без побочных эффектов поймать момент компиляции слова DUP/SWAP/(подставь-любое) например. Без хаков.

а зачем?
Сообщение Добавлено: Вс апр 15, 2007 00:46
  Заголовок сообщения:   Ответить с цитатой
mOleg писал(а):
Мне нравятся эти самые StateSmart слова.

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

Попробуй скомпилировать слово TO.

Или попробуй однозначно, чётко, надёжно и без побочных эффектов поймать момент компиляции слова DUP/SWAP/(подставь-любое) например. Без хаков.

И вообще, у меня уверенность что кто-то из "классиков" однозначно выразил своё "фи" state-smart словам.
Сообщение Добавлено: Вс апр 15, 2007 00:07
  Заголовок сообщения:   Ответить с цитатой
chess писал(а):
Это называется инволюцией(антиэволюция). По мне так у STATE нужно увеличить количество состояний. Вроде pinka к этому пришел(вводит режим текстовой компиляции).


до этого у меня была система со многими состояниями 8)
Сообщение Добавлено: Сб апр 14, 2007 23:57
  Заголовок сообщения:   Ответить с цитатой
profiT писал(а):
Цитата:
В СПФ все это делается без преффиксов, суффиксов и т.п. Зачем вводить лишние понятия.

State-smart слова. И вообще шибко "вумные" слова. Это такое злобнейшее и несомненное зло, которое лично я расцениваю не иначе как бичом традиционного Форта.

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


не понимаю я вас.
Мне нравятся эти самые StateSmart слова.
И достаточных причин, чтобы от них отказаться я не слышал :cry:
Сообщение Добавлено: Сб апр 14, 2007 23:53
  Заголовок сообщения:   Ответить с цитатой
chess писал(а):
По мне так у STATE нужно увеличить количество состояний. Вроде pinka к этому пришел(вводит режим текстовой компиляции).

Прямо собрание заблуждений какое-то... сolorForth-то как раз и построен на увеличении кол-ва состояний!.. "Цвета" -- это явно выраженные в коде программы состояния. Если в обычной системы состояний два, то в CF их как минимум -- пять-шесть and still counting.

(Остапа понесло)

Тезис о что сложное "лучше" простого (лучше в каких обстоятельствах, лучше когда, лучше за какие деньги, будет лучше до каких пор?) и представления об эволюции как о постепенном структурном усложнении организмов, на мой взгляд, мертвым-мертвя лежат в одном пласте с динозаврами и прочими монстрами морей и суши. 97% всей биомассы что составляет?.. Правильно, дети, простые одноклеточные в коре Земли. А из оставшихся копеечных процентов кто подавляюще многочисленен, успешен и живуч?.. Правильно, дети, насекомые.

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

(Остап совсем куда-то улетел не туда..)
Сообщение Добавлено: Сб апр 14, 2007 14:41
  Заголовок сообщения:   Ответить с цитатой
М. выделить раздел для этой темы и еще пары связанных, которые появятся? Или еще тут побудем?
Сообщение Добавлено: Сб апр 14, 2007 11:33
  Заголовок сообщения:   Ответить с цитатой
chess писал(а):
Вырезание таких слов еще один шаг к упрощению транслятора. Последним шагом на этом пути будет связывание каждого слова с одной командой процессора, таким образом мы перейдем к ассемблеру и оптимизатор уже сразу создан - читай: теряет всякий смысл.

Нет никакой связи между упрощением интерпретации (именно интерпретации, а всей не трансляции в целом) и удалением/приближением исходных текстов к конечному маш. коду.

Как вообще можно говорить подобные мня-мня.. ерунды если только страницу назад я показал два, работающих, ColorForth'а на SPF?.. Которые оба-два (а скорее -- все три) никак не влияют на уровень отдалённости исходного текста от генерируемого маш. кода, так как слой оптимизатора для них прозрачен.

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

Не надо связывать тип коробки (ручная/автоматическая) с наличием в машине АБС, GPS, и пепельницы.
Сообщение Добавлено: Пт апр 13, 2007 23:10

Часовой пояс: UTC + 3 часа [ Летнее время ]


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB