Выбор языка для простого интерпретатора

Gudleifr> Нужно решить, какой простой интерпретатор некоторого языка реализовать для простого программирования некоторой фичи.
[...]
Gudleifr> Ограничение: размер [ядра] интерпретатора - не более 100к символов на JavaScript.

Или я чего то не понял ...
Или почему бы прямо на JavaScript и не писать, а не заниматься онанизмом на деньги заказчика? Лучше чем JS (да хоть V8) в одиночку вряд ли сделаешь...

Но ты меня не слушай, я из "кровавого Ынтерпрайза", а не из "свободных художников", либо не понял о чём ты.

<удалено по просьбе администрации>

Gudleifr> По условию задачи. Я спрашиваю, не видел ли кто-то более элегантный интерпретатор...

Эээээ ... ты написал "реализовать", а не "использовать".

Определись уже, что тебе надо.

Sandro> ... ты написал "реализовать"
Да.

Sandro> Определись уже, что тебе надо.
Между моей задачей и Ващими хотелками? Разумеется, первое.

Sandro>> Определись уже, что тебе надо.
Gudleifr> Между моей задачей и Ващими хотелками? Разумеется, первое.

Зря ругаетесь, пока не вижу повода. Ну кроме осени

Gudleifr - ты поставил вопрос довольно странно.
Поэтому что я, что Sandro (ну я так думаю) всё же решили что это очередной Junior изобретает DSL вместо закрытия issues в Jira-e ©

Ну смотри сам - если тебе реально нужен какой то DSL - то на вход для его выбора ты почти ничего не дал. Вот это:

Имеющий удобный набор строковых примитивов...
Имеющий компактную запись вещественных вычислений...

 

ни о чём. "Удобный" - это кому? и это как? А кроме "компактной записи вещественных вычислений" ещё какие бывают? Ну хоть бы написал прямая или польская или чего ещё ты имел ввиду ...
В результате - единственный чёткий лимит: "не более 100к символов на JavaScript"

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

А как по мне, на твоих скудных вводных и плюс вот это:

2. На нем нельзя "просто взять и написать", надо искать объекты, которые "делают примерно то, что надо

 

то и выходит - сделай такие объекты для JS и юзай уже их! Вместо!©

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

Или, в который раз уже - расскажи о задаче, мыж нихчего не поняли

Ну ... как то так!©

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

Заранее спасибо.

Gudleifr> Нужно решить, какой простой интерпретатор некоторого языка реализовать для простого программирования некоторой фичи. Условия - операции с плавающей точкой и работа с текстами.
Задача некорректна:

Gudleifr> Основное требование: программирование фичи должно проводиться быдло-способом: с максимальным использованием библиотек фичи, без модульностей и абстракций.
Это как ?
Как использовать библиотеки если нет модульности ???

Библиотеки - это как раз расширение языка, модульность.

Sandro правильно написал - определись с тем что нужно.

Пример: имеем текстовый редактор, можно реализовать скажем язык описания в виде фортрана или Бейсика и доступ к содержимого в формате встроенного оператора ( а не библиотеки ) get (x,y) - получить символ по позиции.

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

Язык выбирается по задаче, а не по простоте реализации

yacc> Как использовать библиотеки если нет модульности ???
Как в классическом BASIC - операторы вместо функций.

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

Заранее спасибо.

Gudleifr> Как в классическом BASIC - операторы вместо функций.
Так это оператор

Gudleifr> Да, напишите десяток первых пришедших в голову интерпретируемых языков, где были бы эти две фичи, и не заморачивайтесь, кто, где и как это реализует...
Бейсик - проще некуда
Можно Фокал

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

Gudleifr> Ограничение: размер [ядра] интерпретатора - не более 100к символов на JavaScript.

Т.е. сам интерпретатор написан и работает на жабоскрипте? Или к чему это условие?

yacc> Бейсик - проще некуда
Очевидно, но засчитываю.

yacc> Можно Фокал
Пожалуй, красивее BASIC (если не считать спектрумовского, где тоже "по первой букве").

yacc> Форт
Я его уже поминал.

Кто больше?

digger> Т.е. сам интерпретатор написан и работает на жабоскрипте?
По крайней мере, ядро. Остальное, возможно, будет подгружаться в текстовом виде из библиотечного файла или самого документа.

digger> Или к чему это условие?
По правилам моего форумного "хостинга" есть возможность создания только ограниченного числа html-файлов ограниченного размера.

Gudleifr> Основное требование: программирование фичи должно проводиться быдло-способом: с максимальным использованием библиотек фичи, без модульностей и абстракций. В идеале все должно сводиться к двум "операторам": "взять значение в этой точке [обработки] текста" и "вставить ранее запомненное значение
Gudleifr> в эту точку текста". Т.е. нужно уметь рассчитывать сами "значения", так и "области текста, рассчитанные на получение/вставку значений".
Gudleifr> Ограничение: размер [ядра] интерпретатора - не более 100к символов на JavaScript.
Видимо, просто не понимаю условий задачи.

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

Если необходимо отсечь избыточную функциональность (ну, чтобы лишнего не понаписали), то брать и именно отсекать всё кроме вызова этих двух функций и манипуляций переменными при "компиляции" искомого в ЯваСкрипт. Не нужна объектность? Ну, при проверке скрипта убираются все строчки с определениями классовм, обращением к методам/данным объектов и т.п.
При этом непосредственно исполняемый ЯваСкрипт будет на десятичный порядок, а то и два быстрее интерпретатора, написанного на нём. А синтаксис ЯС предельно прост, да и вообще, с таким подходом от него остаётся почти только делимитер ";" между операторами.

<удалено по просьбе администрации>

Gudleifr> Так что проще написать простой "язык", который позволит, хотя бы, избежать избыточности в повторных вызовах одних и тех же функций для одних и тех же структур.
Ну так а я о чём сразу сказал?
Для подобного любой существующий язык слишком универсален (соотвественно, потребует избыточной для задачи нагрузки синтаксисом). В смысле, ЛЮБОЙ существующий язык универсальный будет избыточен. Зачем спрашивать "какой?"?

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

А без точного знания задачи никто оптимальный "удобный"© синтаксис, ессно, посоветовать в принципе не может.

Gudleifr> Кто больше?
Т.е. здесь ветка о том, кто сколько знает ЯП интрепретаторов для среды исполнения с малыми ресурсами ( не более 100 кб текста ) ?
И более эрудированный тот, у кого пи больше кто вспомнит большее их количество ?
От широко известных - типа Бейсика, до академических типа
NODAL

или
Pilot

В этом смысл ветки ?

Татарин> Зачем спрашивать "какой?"?
Татарин> А без точного знания задачи никто оптимальный "удобный"© синтаксис, ессно, посоветовать в принципе не может.
Пардон, повторяю. Вопрос чисто на эрудицию. Я тупо перебрал все пришедшие на ум языки интерпретаторов и понял, что нуждаюсь в новой мысли.

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

yacc> NODAL
yacc> Pilot
Еще раз спасибо. От размера можете абстрагироваться. Мне нужны идеи.

Gudleifr> Еще раз спасибо. От размера можете абстрагироваться. Мне нужны идеи.
Приехали...

То размер важен, то не важен

А что, написать СВОЙ на той же LL-грамматике - не судьба ? - поставить задачу да написать.
Не надо объяснять какие языки по синтаксису для нее подходят ?

yacc> То размер важен, то не важен
Важен мне. От вас - только идеи.

yacc> А что, написать СВОЙ
Я и собираюсь писать свой. Я разве об этом не упомянул в нульпосте?

Gudleifr> Пример 2.
Gudleifr> Приведу программу на очень простом языке разбиения структурного текста на "нужную" и "ненужную" часть:

До боли напоминает конфигурационные файлы парсеров EDI. Вы бы уточнили задачу вам нужен язык общего назначения или проблемно ориентированный?

tarasv> Вы бы уточнили задачу вам нужен язык общего назначения или проблемно ориентированный?
Еще раз. Нужны примеры интерпретаторов, имеющих удобные/оригинальные/забавные средства работы со строками и арифметики вещественных чисел. Другие характеристики (кроме желательной/опциональной простоты) не интересуют.

tarasv>> Вы бы уточнили задачу вам нужен язык общего назначения или проблемно ориентированный?
Gudleifr> Еще раз. Нужны примеры интерпретаторов, имеющих удобные/оригинальные/забавные средства работы со строками и арифметики вещественных чисел. Другие характеристики (кроме желательной/опциональной простоты) не интересуют.
Вот что люди делают с помощь распаковщика гифок:

>>JBIG2 не имеет функций скриптинга, но в сочетании с уязвимостью он имеет возможность эмулировать цепи произвольных логических вентилей, работающих с произвольной памятью. Так почему бы просто не использовать его для создания собственной компьютерной архитектуры и выполнять скриптинг уже в ней? Именно это и делает эксплойт. При помощи более 70 тысяч команд сегментов, определяющих логические операции с битами, он определяет небольшую компьютерную архитектуру с такими особенностями, как регистры и полный 64-битный сумматор и блок сравнения, которые эксплойт использует для поиска в памяти и выполнения арифметических операций. Он не так быстр, как Javascript, но фундаментально является его вычислительным эквивалентом.

>>Разработчиками эксплойта написаны операции бутстреппинга для побега эксплойта из песочницы, выполняемые в этой логической цепи, и вся эта система работает в такой странной эмулируемой среде, созданной из одного прохода распаковки потока JBIG2. Это невероятно и одновременно пугающе.

Странно перекликается с этой и соседними темами, а так же вопросами, задаваемыми Gudleifr. Собственная виртуалочка построенная из распаковщика JBIG2 и собственный скриптовый язык в ней - это круто.

a.p.> Странно перекликается с этой и соседними темами
Дальше будет хуже. Это пока для нормального информационного обмена можно лишь использовать дыры, ускользнувшие от внимания маркетоидов. Скоро, действительно, придется шифровать, т.к. программирование станет уголовно наказуемым.