[quote="Majestio"][quote="KPG"]... если только Perl не ощущается на кончиках пальцев:) [/quote]Ощущается. С 1997 года )[/quote]Кто подскажет самую красивую реализацию на Perl Машины Тьюринга (автомата Мили, других конечных автоматов)? Желательно, с учетом того, что "символы" сами по себе могут быть сложными регулярными выражениями. (lex и yacc не предлагать).

[quote="Хищник"]
Я могу осторожно предложить подумать над следующими вопросами:
1. Стек и работа с памятью. Как с этим в Perl? Конкретнее - как это будет решаться при текущей постановке задачи, и с учетом кроссплатформенности?
[/quote]
И просто ... и сложно. В плане Perl'а я имею возможность разместит что угодно и когда угодно ... вопрос - где и как решает Perl. Тут засада №1.
[quote="Хищник"]2. Словарь. Он несколько вытекает из п.1, поскольку размещен в памяти. Какой тип кода предполагается (машинный или ШК), какова будет структура словарной статьи?
[/quote]
Я пока не знаю, честно. Но логика подсказывает - два варианта. Для "закрытых" систем - машинный код, соответственно для "открытых" - ШК. По идее - этот головняк разработчика, что решил (продать, предоставить, подарить), то и должно быть.
[quote="Хищник"]
3. Интерфейс с ОС. Как выглядит типовое приложение?[/quote]
[/quote]
Хрен его знает ....сперва возможно консоль, мот так легче....

[quote="Majestio"] Мне интересна концепция, ее базовая реализация, попытки стандартизации, "разброд и шатание" вокруг всего этого ... хочется чтобы чужая идея стала частичкой меня.[/quote]
Замечательно! Серьезно. Зубрить синтаксис действительно ни к чему - существующий синтаксис ведь тоже придуман живыми людьми, у которых были свои соображения... а еще свои условия, в которых они находились, и свои задачи. Под реальные задачи собираются реальные Форты. Под выдуманные - ну, "что выросло, то и выросло".

Я могу осторожно предложить подумать над следующими вопросами:
1. Стек и работа с памятью. Как с этим в Perl? Конкретнее - как это будет решаться при текущей постановке задачи, и с учетом кроссплатформенности?
2. Словарь. Он несколько вытекает из п.1, поскольку размещен в памяти. Какой тип кода предполагается (машинный или ШК), какова будет структура словарной статьи?
3. Интерфейс с ОС. Как выглядит типовое приложение?

[quote="gudleifr"]Пока мы не забыли с чего начали, рискну предположить: перед коллегой [b]Majestio[/b] сейчас два пути:
1. Реализовать на Perl квази-Forth, худо-бедно соответствующий стандарту.
2. Сразу перейти к 4-му этапу и написать "хоть что-то работающее".
И я боюсь, что и то, и то отсечет какие-то возможности и интересности. Единственный выход - сразу готовиться к тому, что результат придется выкинуть и начать заново. Не тянуть "хвосты" ошибочно принятых решений с этапа на этап.[/quote]
Однозначно п.1 - ибо "первый заяц" моего убийства - изучения Forth. Только не поймите меня превратно - я не собираюсь зубрить синтаксис. Мне интересна концепция, ее базовая реализация, попытки стандартизации, "разброд и шатание" вокруг всего этого ... хочется чтобы чужая идея стала частичкой меня.

Дальше я куда-то пойду. Однозначно не в сторону ANSI 94.

Причин несколько:

1) Форт на подиуме языков программирования - не красивее бабы Яги, я против статистики не боец
2) Перспективы развития - типа сестры фата Могран'ы (эт я так образно), я еще учусь
3) "Ошибочно принятые решения" - это жИ ценнейший багаж!!! Вы же не собираетесь жить вечно?

Мои нынешние подходы, их скромно два:

1) Все что понимаю, или верю что разобрался - исследую на предмет соответствия нескольким критериям - полнота, непротиворечивость, однозначность, эффективность ... ну вот как-то так
2) Все что не понимаю - пытаюсь делить на субсистемы (субпонятия)

Не тороплюсь. Эта тема для меня - вместо ТиВи. Я так отдыхаю :D

Пока мы не забыли с чего начали, рискну предположить: перед коллегой [b]Majestio[/b] сейчас два пути:
1. Реализовать на Perl квази-Forth, худо-бедно соответствующий стандарту.
2. Сразу перейти к 4-му этапу и написать "хоть что-то работающее".
И я боюсь, что и то, и то отсечет какие-то возможности и интересности. Единственный выход - сразу готовиться к тому, что результат придется выкинуть и начать заново. Не тянуть "хвосты" ошибочно принятых решений с этапа на этап.

[quote="in4"]- основанное на простых понятных принципах
- с хорошей документацией и примерами
- функционально полное, но не переусложненное
- программируемое
- с красивой внутренней моделью (моделями)
- под DOS, Windows, Linux, Android[/quote]
А все это не выглядит несколько противоречивым?

[quote="in4"]целевая задача - получить универсальное решение, то при некоторых подходах может появится разветвленное дерево условий[/quote]Причем, без всякого метапрограммирования...
[quote="in4"]А если у вас есть "красивое визуальное средство"[/quote]У меня тоже все застопорилось из-за отсутствия красивого решения... Но это совсем другая история.
[quote="in4"]У меня как раз другие запросы - мне сложный конструктор надо, а не форму с кнопкой "сделай что мне нужно!".[/quote]Обычное оправдание создателей дурацких интерфейсов. Каждый из нас постоянно упирается в то, что используемый графический интерфейс не позволяет или затрудняет визуализацию очередного гениального видения... Тут надо понять, что же действительно надо, а что - только хочется, либо потратиться на частное решение (которое станет таким же неудобным для следующей задачи, как то, что имеем сейчас).
[quote="in4"]То, что мне нужно, есть по частям в нескольких системах, но я нигде не видел это вместе.[/quote]Если, например, Вы не понимаете, почему их нельзя объединить, значит Вы не понимаете, зачем они нужны. Или еще как-то... Бросайте эту маниловщину...

P.S. Пока писал, понял, почему у меня не получается то самое "красивое решение"...

to in4 гляньте пожалуйста [url=http://jforthblocks.appspot.com/static/code/index.html]сюда,[/url] китаец делает интересные вещи.

[quote="gudleifr"][quote="in4"]...высокоуровневым...[/quote]Вопрос был риторическим. Но, в Вашей трактовке, боюсь он стал просто нерешаемым.[/quote]Вроде как раз и решаю... ;) Пока принципиальных трудностей не замечено.
[quote="gudleifr"]Вы очень близко подошли к грани: "Не знаю, как решить задачу, но если мне дадут красивое визуальное средство, она сразу решится сама собой". [/quote]Как решать дальше - знаю.... ;) Сама задача не решится, надо много чего добавлять до действительно хорошего решения. Но простые решения получить можно без больших объемов работ. ;)

А если у вас есть "красивое визуальное средство":
- основанное на простых понятных принципах
- с хорошей документацией и примерами
- функционально полное, но не переусложненное
- программируемое
- с красивой внутренней моделью (моделями)
- под DOS, Windows, Linux, Android
скажите, я его обязательно попробую! Возможно, оно решит мои текущие проблемы и можно будет заниматься действительно интересными вещами! :) Кстати, автору темы тоже поможет! ;) Я такого пока не нашел. Обычно или функционально не полные - нельзя [b]простым[/b] способом сделать нужные вещи, или плохая документация/внутренние модели/переусложненное, или и то, и другое.
OFFTOPIC
[quote="gudleifr"]Принцип всегда был один: "Создайте интерфейс, которым может пользоваться и дурак, и только дурак захочет им пользоваться". И, на примере Винды, мы видим, что он работает.[/quote]У меня как раз другие запросы - мне сложный конструктор надо, а не форму с кнопкой "сделай что мне нужно!". ;) Для меня (в данном случае) компьютер - просто инструмент для исследований. И я учитываю его ограничения на текущий момент. То, что мне нужно, есть по частям в нескольких системах, но я нигде не видел это вместе. Я пояснил этот момент?
/OFFTOPIC

[quote="gudleifr"][quote="in4"]делать систему с кучей проверок различных условий (по результатам метапрограммирования)[/quote]Как бы метапрограммирование и придумано для избежания "кучи проверок"...[/quote]Если под метапрограммированием понимать программирование задачи построения программы решения целевой задачи и целевая задача - получить универсальное решение, то при некоторых подходах может появится разветвленное дерево условий, чего, собственно и хочется избежать. И, соответственно изменить целевую задачу на построение не одного универсального решения, а набора специализированных решений. Другой акцент. И это кажется важным.

[quote="in4"]делать систему с кучей проверок различных условий (по результатам метапрограммирования)[/quote]Как бы метапрограммирование и придумано для избежания "кучи проверок"...

[quote="in4"]...высокоуровневым...[/quote]Вопрос был риторическим. Но, в Вашей трактовке, боюсь он стал просто нерешаемым.

НЕНУЖНЫЕ ПОУЧЕНИЯ (можно не читать):

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

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

[quote="Majestio"][quote="in4"]- м. не делать одну универсальную систему, лучше сделать несколько специализированных[/quote]Не согласен. Как пример, приведу пересборку ядра *nix систем. Есть все что надо "под все". Но когда делаем под себя - конфигурируем. Что есть по себе - мета-программирование. В результате получаем ядро с нужными встроенными модулями (мы знаем что они будут дергаться в работе постоянно) + получаем отдельно загружаемые модули (редкого использования).[/quote]Рассмотрим, как проще - делать систему с кучей проверок различных условий (по результатам метапрограммирования) либо заменить фрагменты исходника(например, выбрав другой набор включенных файлов). Например, проверять разрядность данных при каждой операции с ними или подключать разные файлы с реализацией алгоритма для разной разрядности - 64, 32, 24, 18, 16, 8...
А еще для разной разрядности и endian-овости могут быть разные оптимизации алгоритма.

Так что или имеем один файл со сложными проверками условий либо несколько файлов, специализированных для каждого варианта. Я за второй вариант. А еще лучше - за систему, которая выделяет сходства и отличия разных вариантов, поддерживая их [b]все[/b]. И речь идет не о текстовой конфигурации. При сборке используются не тексты, а нужные части внутреннего представления.

[quote="Majestio"][quote="in4"]--- но тогда как удобно перемещать между ними хорошие специализированные решения? - Мой ответ - более высокоуровневая среда разработки[/quote]Мне кажется дело не столько в среде разработки, сколько в возможностях подстройки (в ее реализации) кода к условиям эксплуатации. К примеру, взбредет кому в голову написать библиотеку по тензорному анализу. Будет преступлением - игнорировать наличие какого-нить GPU Ati Radeon'а.[/quote]Среда - это просто удобное место работы, где вся нужная документация, фрагменты кода, схемы и доп. информация под рукой. Где можно создать части схемы и таскать их по экрану, размещая так, чтобы было удобно видеть нужные связи. И где можно было бы допрограммировать взаимодействия созданных экранных элементов. Где можно работать с фрагментами алгоритмов как с экранными объектами.

А если добавить поддержку Raspberry Pi (GPU VideoCore) и CubieBoard(GPU Mali400), то луше в ту библиотеку добавить условий для оптимизации под каждый вариант, или сделать несколько вариантов(свою реализацию набора примитивов для каждого GPU) ? ;)

Среда должна помочь одновременно поддерживать [b]все[/b] эти GPU.

[quote="Majestio"][quote="in4"]- при специальном представлении исходников - в прекомпилированном виде - можно значительно увеличить скорость компиляции ценой усложнения редактора и возможностей легкой передачи текстов исходников[/quote]У меня вообще шальная идея )) Исходники хранить только в ипостаси дампа (обычного читаемого). А все рабочее - загнать в SQlite, обеспечить норм индексацией. По сравнению с работой с файловой системой - ускорение будет на порядки. Только не забывать периодически сбрасывать снимки базы на диск. Вон люди уже [url=http://www.nongnu.org/libsqlfs/]давно извращаются[/url].[/quote]А это уже вопросы реализации! ;)
- читаемость внутреннего представления не обязательна
- аналогичные возможности может обеспечить хорошая система контроля версий
Вот я сейчас рассматриваю, подходит ли Git для некоторых работ. Мне кажется, нужна бОльшая интеграция системы разработки и системы контроля версий, но это вопрос удобства и будущего.

[quote="gudleifr"][quote="in4"]Мой ответ - более высокоуровневая среда разработки[/quote][quote="in4"]при специальном представлении исходников - в прекомпилированном виде[/quote][quote="in4"]разместить полноценную, но упрощенную Forth-систему в микроконтроллере AVR Mega8 в 1кБ памяти[/quote]Почему на этом Форуме "высокоуровневость" постоянно превращается в аппаратно-ориентированность?[/quote]В моем случае это несколько разные направления - система, в которой программист даже может не видеть код (по желанию ;) - он будет работать не с текстом, а с графическим представлением частей программы - это и есть более высокий уровень - хотя технически просто такой лексикон со своими операциями, графическим внешним представлением и специальным внутренним с возможностью преобразования в текст) - это одно направление. А другое - мелкий контроллер для простых задач, программируемый на языке высокого уровня. С [b]текстовым[/b] представлением исходников для программиста. При хранении - прекомпилированное представление, которое можно преобразовать в текст программно.
И речь идет не об аппаратной ориентированности, а о специальной версии, оптимизированной по каким-то критериям для определенной аппаратуры. Методы программирования сохраняются, даже часть исходников тоже. Но может поменняться набор операций Виртуальной Машины, коды операций вплоть до упаковки в адресуемые ячейки, ширина данных, адресуемое пространство, способ работы с внешними устройствами (системные вызовы, регистры, устройства как память...), набор внешних устройств.
Очевидно же (или нет? ;) ), что в этих случаях способы решения задач (и даже алгоритмы!) [b]могут[/b] отличаться при сохранении некоторой общности решений. И зачем в таком случае тащить полную совместимоть и универсальность? Делаем набор примитивов и используем [b]подходящие[/b] лексиконы, а что не подходит - пишем аналоги - специализированные лексиконы.

[quote="gudleifr"]P.S. И какой же вы новичок? Уже три года здесь. Не отсылать же Вас обратно к Дейкстре, Муру, Броуди и Баранову/Ноздрунову...[/quote]

Говорят " с годами одни становятся мудрее, другие - старше". Увы, в плане форта - я второе :( Другим был занят плотно.