Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
Владимир писал(а): Что касается диалектов, то Форт сам по себе настолько гибок, что вместо того, чтобы разрабатывать очередной диалект, можно просто реализовать нужную функциональность в виде словаря.
Да, функционально можно сделать то же самое. У меня даже пара версий есть... А при реализации, которую нужно "поджать" для микроконтроллера или ПЛИС - прийдется таки переработать всю Форт-систему...
[quote="Владимир"]Что касается диалектов, то Форт сам по себе настолько гибок, что вместо того, чтобы разрабатывать очередной диалект, можно просто реализовать нужную функциональность в виде словаря.[/quote]
Да, функционально можно сделать то же самое. У меня даже пара версий есть... ;) А при реализации, которую нужно "поджать" для микроконтроллера или ПЛИС - прийдется таки переработать всю Форт-систему... :)
|
|
|
|
Добавлено: Пн июн 25, 2007 18:25 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: Форт развивается. Стоит ли использовать новые диалекты?
Если это кому-либо необходимо, то почему бы и нет? Главное, чтобы польза была.
А вот лично мне нужен голый ANS-Forth. И доп.словари, делающие из такого минимального Форта нужный мне DSL. Всё. Мне этого хватит "за глаза".
Что касается диалектов, то Форт сам по себе настолько гибок, что вместо того, чтобы разрабатывать очередной диалект, можно просто реализовать нужную функциональность в виде словаря.
Имхо
[quote]Форт развивается. Стоит ли использовать новые диалекты?[/quote]
Если это кому-либо необходимо, то почему бы и нет? Главное, чтобы польза была.
А вот лично мне нужен голый 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-зависимых слов в том, что получается неожиданное поведение. Ты хочешь прикомпилировать слово, а оно почему-то выполняется...
И сложность - больше анализа, больше сложность, меньше эффективность, больше код...
[quote="Хищник"]Думается, state-smart все же терпимы.... Но все равно интересно, как без них.[/quote] STATE задает как бы контекст, в котором слова имеют другой смысл, разный для разного значения STATE - либо интерпретировать, либо компилировать, и оно общее для всех слов. В CF цвет задает способ использования конкретного слова - то ли его использовать как [color=red]имя [/color]нового определения (реально - как начальный адрес), то ли [color=green]компилировать[/color], то ли [color=yellow]исполнить[/color]. Еще можно компилировать [color=cyan]макрос[/color]. Ну, есть и несколько вариантов комментариев. Мур(еще с cmForth), убрал STATE (вернее, IMMEDIATE), используя разные словари для компиляции и интерпретации. Я убрал STATE , сделав отдельно цикл интерпретации и цикл исполнения. А слова [b][ ] ], [/b]переключают эти циклы. Систему планировалось использовать в виде простых текстов, поэтому о разных цветах и шрифтах речь даже не шла. Префиксы перед каждым словом мне тоже не понравились. Поэтому я продлил действие состояний. Т.о. у меня все же используется аналог STATE , но не флагом, а сразу значением - соответствующим состоянию циклом обработки - циклом интерпретации или циклом компиляции. Потом уже я увидел пример [b]profit[/b]-а с суффиксами, он мне понравился. ;) [quote="profiT"]И вообще, у меня уверенность что кто-то из "классиков" однозначно выразил своё "фи" state-smart словам.[/quote] Да: [quote="Броуди, глава 8."] СОВЕТ Слова не должны зависеть от переменной STATE, если программист собирается когда-либо использовать их для вызова из высокоуровневого определения и при этом ожидает получить от них такое же поведение, как и при интерпретации.[/quote]
А неприятность STATE-зависимых слов в том, что получается неожиданное поведение. Ты хочешь прикомпилировать слово, а оно почему-то выполняется... ;)
И сложность - больше анализа, больше сложность, меньше эффективность, больше код...
|
|
|
|
Добавлено: Пн апр 16, 2007 03:45 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
rvm писал(а): По моему, дело более даже в признаке IMMEDIATE rvm писал(а): А упомянутое POSTPONE анализирует у аргумента как раз признак IMMEDIATE, а не STATE.
кстати да!
Действительно проблема у POSTPONE не столько в анализе STATE сколько в анализе типа слова. Этой проблемы нет у слов однозначно выполняющих свои действия над другими словами, как TO IS COMPILE ['] [COMPILE] и что там еще
[quote="rvm"]По моему, дело более даже в признаке IMMEDIATE[/quote] [quote="rvm"]А упомянутое POSTPONE анализирует у аргумента как раз признак IMMEDIATE, а не STATE. [/quote]
кстати да!
Действительно проблема у POSTPONE не столько в анализе STATE сколько в анализе типа слова. Этой проблемы нет у слов однозначно выполняющих свои действия над другими словами, как TO IS COMPILE ['] [COMPILE] и что там еще 8)
|
|
|
|
Добавлено: Вс апр 15, 2007 22:31 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: вызванного открытым ящиком Пандоры -- state-smart словами
По моему, дело более даже в признаке IMMEDIATE (который жестко привязан к слову), а не в анализе STATE. Например, photonInterpreter анализирует признак, заданный отступами, а startColorSPF добавляет анализ признака, представленного суфиксом слов. STATE — это аналогичный признак, он лишь по другому задается и абстрагирован от синтаксиса.
А упомянутое POSTPONE анализирует у аргумента как раз признак IMMEDIATE, а не STATE.
В свою очередь, признак IMMEDIATE — это лишь одно из возможных решений задачи маскировки для "мультиплексирования" входного потока, совмещения в нем "обычного" и "управляющего" потоков. Цвета — другое решение той же задачи. XML — еще одно решение, очень емкое в силу естественных иерархичности и возможностей маскировки. Оно позволяет легко мультиплексировать произвольно много под-потоков, лишь бы структура оставалалсь "деревом".
[quote]вызванного открытым ящиком Пандоры -- state-smart словами[/quote]
По моему, дело более даже в признаке 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 переменная очень проста и понятна, а главное надежна - т.к. она одна - пусть даже имеющая много состояний. А вот когда контексты начинают выполнять ее роль, то может получиться очень даже неудобная штука.
[quote="profiT"]mOleg писал(а): И дело не в том, что оно STATE SMART !
Оно сделано "шибко вумным" потому что вообще есть "шибко вумные" слова, анализирующие STATE. Если есть хотя бы одно state-smart слова -- будут хаки, будут "обходы", будут глюки, будут нестыковки в логике. [/quote] оно сделано слишком умным - оно получается умнее меня - а это не порядок. Других таких слов в стандартном форте к счастью нет
[quote="profiT"]mOleg писал(а): [COMPILE] TO - должно работать, нет, даже обязано!
Э-э, нет.. Тут вам не здесь.. Мне нужно скомпилировать слово TO, а не компилировать слово компилирующее слово (TO) (например, зависит от реализации). [/quote] поясни! какая разница?
[quote="profiT"]И за [COMPILE] спасибо -- это как раз ярчайший пример идиотизма вызванного вызванного открытым ящиком Пандоры -- state-smart словами.[/quote] а мне нравится именно пара [compile] compile а не гадкий POSTPONE
[quote="Хищник"]Думается, state-smart все же терпимы.... Но все равно интересно, как без них. Видимо, я сильно упустил начало обсуждения.[/quote]
вообще тут по-моему просто раздутая проблема. STATE переменная очень проста и понятна, а главное надежна - т.к. она одна - пусть даже имеющая много состояний. А вот когда контексты начинают выполнять ее роль, то может получиться очень даже неудобная штука.
|
|
|
|
Добавлено: Вс апр 15, 2007 02:09 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Думается, state-smart все же терпимы.... Но все равно интересно, как без них. Видимо, я сильно упусти л начало обсуждения.
Думается, state-smart все же терпимы.... Но все равно интересно, как без них. Видимо, я сильно упусти л начало обсуждения.
|
|
|
|
Добавлено: Вс апр 15, 2007 01:19 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): И дело не в том, что оно STATE SMART ! Оно сделано "шибко вумным" потому что вообще есть "шибко вумные" слова, анализирующие STATE. Если есть хотя бы одно state-smart слова -- будут хаки, будут "обходы", будут глюки, будут нестыковки в логике. mOleg писал(а): [COMPILE] TO - должно работать, нет, даже обязано!
Э-э, нет.. Тут вам не здесь.. Мне нужно скомпилировать слово TO, а не компилировать слово компилирующее слово (TO) (например, зависит от реализации).
И за [COMPILE] спасибо -- это как раз ярчайший пример идиотизма вызванного вызванного открытым ящиком Пандоры -- state-smart словами.
[quote="mOleg"]И дело не в том, что оно STATE SMART ![/quote] Оно сделано "шибко вумным" потому что вообще есть "шибко вумные" слова, анализирующие STATE. Если есть хотя бы одно state-smart слова -- будут хаки, будут "обходы", будут глюки, будут нестыковки в логике.
[quote="mOleg"][COMPILE] TO - должно работать, нет, даже обязано![/quote]
Э-э, нет.. Тут вам не здесь.. Мне нужно скомпилировать слово TO, а не компилировать слово компилирующее слово (TO) (например, зависит от реализации).
И за [COMPILE] спасибо -- это как раз ярчайший пример идиотизма вызванного вызванного открытым ящиком Пандоры -- state-smart словами.
|
|
|
|
Добавлено: Вс апр 15, 2007 01:12 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
profiT писал(а): mOleg писал(а): Мне нравятся эти самые StateSmart слова.
Противоречивые нравилки. С одной стороны -- ругаем (справедливо) POSTPONE за его сложность, с другой -- в открытую говорим что любим "шибко-вумные" слова, тогда как второе как раз и определяет, мягко говоря, непрямую логику работы POSTPONE. POSTPONE - это действительно гадость. Но это редкое исключение. И дело не в том, что оно STATE SMART ! profiT писал(а): Попробуй скомпилировать слово TO. [COMPILE] TO - должно работать, нет, даже обязано! profiT писал(а): Или попробуй однозначно, чётко, надёжно и без побочных эффектов поймать момент компиляции слова DUP/SWAP/(подставь-любое) например. Без хаков.
а зачем?
[quote="profiT"]mOleg писал(а): Мне нравятся эти самые StateSmart слова.
Противоречивые нравилки. С одной стороны -- ругаем (справедливо) POSTPONE за его сложность, с другой -- в открытую говорим что любим "шибко-вумные" слова, тогда как второе как раз и определяет, мягко говоря, непрямую логику работы POSTPONE. [/quote] POSTPONE - это действительно гадость. Но это редкое исключение. И дело не в том, что оно STATE SMART !
[quote="profiT"]Попробуй скомпилировать слово TO. [/quote] [COMPILE] TO - должно работать, нет, даже обязано!
[quote="profiT"]Или попробуй однозначно, чётко, надёжно и без побочных эффектов поймать момент компиляции слова DUP/SWAP/(подставь-любое) например. Без хаков. [/quote]
а зачем?
|
|
|
|
Добавлено: Вс апр 15, 2007 00:46 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Мне нравятся эти самые StateSmart слова.
Противоречивые нравилки. С одной стороны -- ругаем (справедливо) POSTPONE за его сложность, с другой -- в открытую говорим что любим "шибко-вумные" слова, тогда как второе как раз и определяет, мягко говоря, непрямую логику работы POSTPONE.
Попробуй скомпилировать слово TO.
Или попробуй однозначно, чётко, надёжно и без побочных эффектов поймать момент компиляции слова DUP/SWAP/(подставь-любое) например. Без хаков.
И вообще, у меня уверенность что кто-то из "классиков" однозначно выразил своё "фи" state-smart словам.
[quote="mOleg"]Мне нравятся эти самые StateSmart слова.[/quote]
Противоречивые нравилки. С одной стороны -- ругаем (справедливо) POSTPONE за его сложность, с другой -- в открытую говорим что любим "шибко-вумные" слова, тогда как второе как раз и определяет, мягко говоря, непрямую логику работы POSTPONE.
Попробуй скомпилировать слово TO.
Или попробуй однозначно, чётко, надёжно и без побочных эффектов поймать момент компиляции слова DUP/SWAP/(подставь-любое) например. Без хаков.
И вообще, у меня уверенность что кто-то из "классиков" однозначно выразил своё "фи" state-smart словам.
|
|
|
|
Добавлено: Вс апр 15, 2007 00:07 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): Это называется инволюцией(антиэволюция). По мне так у STATE нужно увеличить количество состояний. Вроде pinka к этому пришел(вводит режим текстовой компиляции).
до этого у меня была система со многими состояниями
[quote="chess"]Это называется инволюцией(антиэволюция). По мне так у STATE нужно увеличить количество состояний. Вроде pinka к этому пришел(вводит режим текстовой компиляции).[/quote]
до этого у меня была система со многими состояниями 8)
|
|
|
|
Добавлено: Сб апр 14, 2007 23:57 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
profiT писал(а): Цитата: В СПФ все это делается без преффиксов, суффиксов и т.п. Зачем вводить лишние понятия.
State-smart слова. И вообще шибко "вумные" слова. Это такое злобнейшее и несомненное зло, которое лично я расцениваю не иначе как бичом традиционного Форта.
State-smart слова, кстати, являются главной причиной усложнения оптимизаторов Форта. Если их вырезать под корень (как в CF) оптимизаторы пишутся на бесконечно порядков проще.
не понимаю я вас.
Мне нравятся эти самые StateSmart слова.
И достаточных причин, чтобы от них отказаться я не слышал
[quote="profiT"]Цитата: В СПФ все это делается без преффиксов, суффиксов и т.п. Зачем вводить лишние понятия.
State-smart слова. И вообще шибко "вумные" слова. Это такое злобнейшее и несомненное зло, которое лично я расцениваю не иначе как бичом традиционного Форта.
State-smart слова, кстати, являются главной причиной усложнения оптимизаторов Форта. Если их вырезать под корень (как в CF) оптимизаторы пишутся на бесконечно порядков проще.[/quote]
не понимаю я вас.
Мне нравятся эти самые StateSmart слова.
И достаточных причин, чтобы от них отказаться я не слышал :cry:
|
|
|
|
Добавлено: Сб апр 14, 2007 23:53 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): По мне так у STATE нужно увеличить количество состояний. Вроде pinka к этому пришел(вводит режим текстовой компиляции).
Прямо собрание заблуждений какое-то... сolorForth-то как раз и построен на увеличении кол-ва состояний!.. "Цвета" -- это явно выраженные в коде программы состояния. Если в обычной системы состояний два, то в CF их как минимум -- пять-шесть and still counting.
(Остапа понесло)
Тезис о что сложное "лучше" простого (лучше в каких обстоятельствах, лучше когда, лучше за какие деньги, будет лучше до каких пор?) и представления об эволюции как о постепенном структурном усложнении организмов, на мой взгляд, мертвым-мертвя лежат в одном пласте с динозаврами и прочими монстрами морей и суши. 97% всей биомассы что составляет?.. Правильно, дети, простые одноклеточные в коре Земли. А из оставшихся копеечных процентов кто подавляюще многочисленен, успешен и живуч?.. Правильно, дети, насекомые.
А приматы что?.. Эскалация средней руки конфликта до мирового ядерного противостояния (хотя это уже менее актуально), бездумное уничтожение своей же среды обитания, истощение минеральных запасов, вторжение с Альдебарана более "правильных" жуков на Землю, пандемия какая-нибудь -- вот и конец всем обезьянам (в худшем случае -- заодно со всеми позвоночными).
(Остап совсем куда-то улетел не туда..)
[quote="chess"] По мне так у STATE нужно увеличить количество состояний. Вроде pinka к этому пришел(вводит режим текстовой компиляции).[/quote]
Прямо собрание заблуждений какое-то... сolorForth-то как раз и построен на увеличении кол-ва состояний!.. "Цвета" -- это явно выраженные в коде программы состояния. Если в обычной системы состояний два, то в CF их как минимум -- пять-шесть and still counting.
(Остапа понесло)
Тезис о что сложное "лучше" простого (лучше в каких обстоятельствах, лучше когда, лучше за какие деньги, будет лучше до каких пор?) и представления об эволюции как о постепенном структурном усложнении организмов, на мой взгляд, мертвым-мертвя лежат в одном пласте с динозаврами и прочими монстрами морей и суши. 97% всей биомассы что составляет?.. Правильно, дети, простые одноклеточные в коре Земли. А из оставшихся копеечных процентов кто подавляюще многочисленен, успешен и живуч?.. Правильно, дети, насекомые.
А приматы что?.. Эскалация средней руки конфликта до мирового ядерного противостояния (хотя это уже менее актуально), бездумное уничтожение своей же среды обитания, истощение минеральных запасов, вторжение с Альдебарана более "правильных" жуков на Землю, пандемия какая-нибудь -- вот и конец всем обезьянам (в худшем случае -- заодно со всеми позвоночными).
(Остап совсем куда-то улетел не туда..)
|
|
|
|
Добавлено: Сб апр 14, 2007 14:41 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
М. выделить раздел для этой темы и еще пары связанных, которые появятся? Или еще тут побудем?
М. выделить раздел для этой темы и еще пары связанных, которые появятся? Или еще тут побудем?
|
|
|
|
Добавлено: Сб апр 14, 2007 11:33 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
chess писал(а): Вырезание таких слов еще один шаг к упрощению транслятора. Последним шагом на этом пути будет связывание каждого слова с одной командой процессора, таким образом мы перейдем к ассемблеру и оптимизатор уже сразу создан - читай: теряет всякий смысл.
Нет никакой связи между упрощением интерпретации (именно интерпретации, а всей не трансляции в целом) и удалением/приближением исходных текстов к конечному маш. коду.
Как вообще можно говорить подобные мня-мня.. ерунды если только страницу назад я показал два, работающих, ColorForth'а на SPF?.. Которые оба-два (а скорее -- все три) никак не влияют на уровень отдалённости исходного текста от генерируемого маш. кода, так как слой оптимизатора для них прозрачен.
Разве если на одном конце вместо большого сложного пульта получили простой, гибкий и расширяемый интерфейс, это разве что-то может сказать о сложности на другой стороне производственной линии?.. Ничего это не говорит.
Не надо связывать тип коробки (ручная/автоматическая) с наличием в машине АБС, GPS, и пепельницы.
[quote="chess"]Вырезание таких слов еще один шаг к упрощению транслятора. Последним шагом на этом пути будет связывание каждого слова с одной командой процессора, таким образом мы перейдем к ассемблеру и оптимизатор уже сразу создан - читай: теряет всякий смысл.[/quote]
Нет никакой связи между упрощением интерпретации (именно интерпретации, а всей не трансляции в целом) и удалением/приближением исходных текстов к конечному маш. коду.
Как вообще можно говорить подобные мня-мня.. ерунды если только страницу назад я показал [b]два[/b], работающих, ColorForth'а на SPF?.. Которые оба-два (а скорее -- все три) никак не влияют на уровень отдалённости исходного текста от генерируемого маш. кода, так как слой оптимизатора для них прозрачен.
Разве если на одном конце вместо большого сложного пульта получили простой, гибкий и расширяемый интерфейс, это разве что-то может сказать о сложности на другой стороне производственной линии?.. Ничего это не говорит.
Не надо связывать тип коробки (ручная/автоматическая) с наличием в машине АБС, GPS, и пепельницы.
|
|
|
|
Добавлено: Пт апр 13, 2007 23:10 |
|
|
|
|