чет ты стал огромные посты постить, аки я.
осилим утром пред-ий и этот.

запости на своём "родном" эльфячем (находила какие-то твои ранние посты то ли тут, то ли на еще тогда живом твоем личном блоге)

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

aive

Когда я обдумывал свой лиспоподобный (или смолтолкаподобный язык), я придумал интересное решение этой проблемы.

Сделать вызов методов правильным-виртуальным, сделать всё объектами, а для быстродействия сделать набор (произвольно расширяемый, а не зашитый в язык, конечно же) DSL-ей.

И вот внутри математического DSLя будет инфикс, будут примитивные типы, разные размеры целых и так далее.
И это уже исключительно забота DSLя, в какие инструкции скомпилировать свои внутренности. Его задача - принять переменные, выдать переменные. Чёрный ящик.

То есть, напишешь ты (calc (x * 3) << 2)
А дальше уже calc знает, что умножение - это всегда умножение.
Но если ты вдруг захочешь другую арифметику, то тебе не надо будет перегружать все операции на всех типах по отдельности (это неудобно и хрупко), а просто напишешь (matrix-calc) или (vector-calc) или там (gpu-calc)
И внутри себя у него будет полностью свой набор правил, методов, договорённостей, типов и нотаций.

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

(Reply to this) (Thread)

дело в том, что основное назначение языка — таки «скриптовый», а не all-purpose. что подразумевает небольшие размеры, отсутствие подобных наворотов (bwah! it IS DSL alreay!) и простое встраивание в ся. при этом хочется не растерять основной красоты и не стать диким тормозом.

впрочем, в нормальной версии компилятор mist планируется написать на самом mist, так что можно будет просто «врезаться» в компилятор.

(Reply to this) (Parent) (Thread)

В скриптовом языке тебе нужен ровно один тип числа - беззнаковое 64-битное целое. Оно же счётчик, оно же индекс в массиве. А больше тебе никакие не нужны. И арифметика не нужна. А нужны функции sum и inc.

(Reply to this) (Parent) (Thread)

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

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

только не надо путать этот подход с «а вот сейчас мы напишем платформу, привинтим к ней язык, и дальше уже каждый на этой платформе сделает себе то, что ему надо». это похожий подход, но не такой: просто программа сразу делится на две части. первая — низкоуровневые операции. и вторая — собственно, вся программная логика. написание оной логики сразу планируется в том виде, в каком оно будет, и сразу планируется на некоем встроеном языке, с поэтами и замыканиями.

именно для подобных целей мне и нужен скриптовый язык. и да: он должен быть простым, но при этом мощным. и не превосходить в объёме код самой низкоуровненой прокладки на несколько порядков.

(Reply to this) (Parent)

хотя, конечно, сделать что-то вроде #((…)), где юзер пишет ту же математику и разрешает компилеру читерить, соглашаясь, что при этом перегрузка методов идёт побоку — где-то вариант. но неизящный. и вопросов с перегрузкой тех же ifTrue:[ifFalse:] никак не снимает — а такая перегрузка вполне корректная операция.

допиленый мной LittleSmalltalk на условиях и циклах читерит атомно, например, попросту кладя болт на эти перегрузки (в смысле, оригинал тоже читерил, это не моя допилка). и умеет простые «свёртки» типа 'a isNil ifTrue:' в 'a ifNil:'.

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

(Reply to this) (Parent) (Thread)

Нет, не надо никому читерить. Надо совершенно прозрачно принимать на вход набор символов и генерировать из них код. Просто по другим законам живущий.

Стандартные не обязательно прибивать гвоздями. Просто сказать, что они стандартные, и не менять их. Кто себе прострелит ногу - тот сам себе жертва.

(Reply to this) (Parent) (Thread)

>Просто сказать, что они стандартные, и не менять их
это и есть «прибить гвоздями», вообще-то. указав в документации: «в случае выше/нижеперечисленых стандартных управляющих конструкций и ты пы компилятор читерит. если вам это не нравится — вы можете выставить компилятору флаг 'перестань читерить', и получите в итоге 'честный', но медленный код. выбор за вами.»

так и сделаю, наверное.

(Reply to this) (Parent) (Thread)

Это всё равно не то, что я тебе пытался рассказать.
(Но мой случай не очень подходит для скриптового языка, так как подразумевает большие инвестиции в платформу и VM)
Мой случай - это ты явно заключаешь тот кусок кода, где надо оптимизировать арифметику, в отдельный блок - и в этом блоке действуют принципиально другие законы, чем в остальном обычном коде.

(Reply to this) (Parent) (Thread)

да я понял, я об этом писал же, и сказал, что мне не нравится. это для «взрослого» языка имеет смысл городить метамеханизмы. в моём случае они только раздуют всё, а реально пользоваться этим будет неудобно.

(Reply to this) (Parent) (Thread)

Для скриптового я с тобой согласен.

(Reply to this) (Parent)