> tcl

Ah, I see you're a man of culture aswell.

Ну хоть кто-то вспомнил божественный тсл, за зря похуенный столманом.

(Reply to this) (Thread)

я его (тикль) вполне уважаю. у меня в эмуляторе спектрума, например, он вмонтирован (в виде jim-tcl), обслуживает внутреннюю консоль и вообще всем там управляет.

просто «главный» Tcl как-то умудрился вырасти до размеров пиздецомы, жимтцл тоже уже толстеет — куды податься, если хочется поменьще, и желательно self-contained?

(Reply to this) (Parent) (Thread)

Есть ещё picol из более-менее живых тиклей

https://chiselapp.com/user/dbohdan/repository/picol/home

(Reply to this) (Parent) (Thread)

его давно испортили: он размерами больше TH1, а толку примерно столько же.

я, конечно, немного увлёкся и TH1 тоже подрихтовал (хэш-таблички переписал, сделал memory leak prevention, case insensitivity, и такое вот), но он всё ещё меньше.

чота думаю: может, написать свой с нуля? а то у всех остальных же Фатальный Недостаток…

(Reply to this) (Parent) (Thread)

>чота думаю: может, написать свой с нуля?

Это, кстати, у меня первая мысль была: как так случилось, что Кетмар не стал свою реализацию языка делать? Тем более, что тикль не самый сложный в этом плане.

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent)

ну, ты типа пиздец охуительный пророк, чо.

set a global-a
set c global-c

proc test {a b} {
  puts "test:a=<$a>"
  puts "test:b=<$b>"
  set c goo
  puts "test:c=<$c>"
}

test foo boo
puts "c=$c"
test zoo doo

================

(string loaded from file 'ztest_00.elle', first line is 1)
test:a=<foo>
test:b=<boo>
test:c=<goo>
c=global-c
test:a=<zoo>
test:b=<doo>
test:c=<goo>
DONE: (12)<test:c=<goo>>

"expr" ещё нет, но это отдельный язык в языке, тупо матэвалюатор по строке. в остальном — движок поддерживает усерские типы объектов с деструкторами (чтобы всякие хэндлы хранить), прозрачное кэширование разбиения строки в список (у TH1 обеих этих фич нет; а прозрачное кэширование позволяет избавиться от постоянного репарзинга проков), жрёт меньше памяти, чем TH1, работает быстрее.

(Reply to this) (Parent) (Thread)

Красота-то какая! Лепота!

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

(Reply to this) (Parent) (Thread)

писать скриптовые языки прельстиво, да!

вообще, жаль, что tcl как-то fell in some crack. для большинства случаев это почти идеальный встраиваемый язык: на нём и конфиги выглядят ок, и система «команда аргументы» отлично подходит для управления из консоли (внешней и внутренней), и ты пы.

но авторы «большого tcl», по-моему, пошли куда-то не в ту сторону, пытаясь сделать из него standalone монстра. как по мне, их главная страница должна выглядеть как-то так:

котаны! Tcl — это пиздато! встраивайте его в свой софт! вот вам список движков — от тормоза, зато всего на 20 кб сырцов, и до монстра с прекомпиляцией expr'ов! не проходите мимо, разбирайте!

(Reply to this) (Parent) (Thread)

Поздно. В командной строке его сначала съел перл, а теперь бидон.
А во встраивалке жабоскрипт все юзают.
Я сначала хотел стырить готовую реализацию тикля, но jtcl тоже благополучно помер, ибо кто будет возиться с подключением ещё одной зависимости, если прям в рантайме жабоскриптовый интерпретатор дают.

Жаль конечно. An elegant tool for a more civilized age.

(Reply to this) (Parent) (Thread)

дык я и говорю: я считаю, что это от неправильного позиционирования изначально. в принципе, никогда не позно «отребрендить» обратно, но хардкорные тикелевцы же изойдут в говнину от воплей: «ВЫ НИЧИВО НИПАНИМАИТИ! НАШ ТИКОЛ НАСТАЯЩИЙ ЯЗЫК А НИ ВСТРАИВАИМАЯ ХУИТА!!»

(Reply to this) (Parent)

пилю, кстати, вот тут. она ещё не готова для продукшон, конечно, но вся основная механика уже сделана, и даже валгринд говорт, что мемликов нет (а там внутри refcounted GC, да).

(Reply to this) (Parent)

Прости, а зачем ты так сделал?

(Reply to this) (Parent) (Thread)

что именно?

(Reply to this) (Parent) (Thread)

Видимость глобальных переменных в процэдурах.

(Reply to this) (Parent) (Thread)

а разве в тцл не так? set создаёт новую, а пока set не сделан — видно. не?

(Reply to this) (Parent) (Thread)

Нет, в tcl никакого автоматического проброса глобальных переменных нет.
Если хочешь доступ к глобальной -- то global или upvar #0

(Reply to this) (Parent) (Thread)

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

с одной стороны, у меня есть синтаксис `::varname` для глобалов, и даже фича передачи аргументов by reference. а с другой — плохие привычки…

(Reply to this) (Parent) (Thread)

Стоит.

Откровенно жопа и писать и тэстировать, когда туда текут переменные и ты никогда не можэшь сказать, что тебе на самом деле сменит set Port 0 какой-нибудь.

(Reply to this) (Parent) (Thread)

ну, set всегда создаёт локал, без вариантов (если это не `set ::foo boo`, конечно).

но в принципе ты прав: для глобалов есть шорткат `::`, а на небъявленых локалах лучше падать. немного расхождение с поиском cmd/proc, но фиг с ним.

а byref да, должны указываться явно и в объявлении, и по месту вызова:

proc boo {&a} { set a 69 }
set n 96
boo &n

так понятно, что куда.

(Reply to this) (Parent)

самое смешное то, что где-то в процессе чистки кода к Elle2 я таки это убрал, и теперь обращение к неустановленой переменной не мапится наверх, а падает с "variable not found".

(Reply to this) (Parent)

И да, в сишэчке полегче -- оно всё-таки compile-time хотя бы частично проверяется. Здесь вообще непонятно, что по итогу приедет в runtime.

(Reply to this) (Parent)

Мне, кстати, передача аргументов tcl очень нравилась.

Да, требуется прямо указывать -- или value или lvalue, но это по сути и удобно.

(Reply to this) (Parent)

p.s.: а ещё на это завязана фича команд — которые не особый список, а просто переменные в глобальном скопе, рядом с обычными проками. соответственно, я подумал, что если для вызова поиск идёт local, global (угу, есть nested procs, и можно перекрыть глобальные определения), то логично будет не делать исключений и для обычных переменных.

(Reply to this) (Parent) (Thread)

Заодно и нэймспейсы сделаешь!

Не то, чтобы очень полезная вещь -- но таки пусть будет, кто-то ведь пользуется.

У команд, в оригинале, кстати, локального для процэдуры скоупа нет.

(Reply to this) (Parent) (Thread)

>Заодно и нэймспейсы сделаешь!
для них, кстати, в коде сразу была заготовка. но я не придумал красивого апи и пока забил.

>У команд, в оригинале, кстати, локального для процэдуры скоупа нет.
да, это я в курсе. просто мне стало лениво для них отдельную табличку делать, и я их положил в обычные переменные (движок только запрещает им что-то присваивать, чтобы нечаянно команду не похерить). а потом сделал такой поиск, почему бы и да. за этим была какая-то идея, но я её забыл.

>Вообще, мне не до конца понятно -- зачем нужны nested procs, если уж так.
ну, они просто работают. proc тупо создаёт переменную, а создание переменных идёт в локальный скоп.

ламбды, кстати, есть вполне полноценные: это ж просто proc без автоматического создания переменной. поскольку внутри движка значения типизированы, то оно Просто Работает.

[lambda {a} { puts "lambda: a=$a" }] boo

(Reply to this) (Parent) (Thread)

>proc тупо создаёт переменную,

И у меня довольно много кода рассчитано на то, что proc создаёт глобальную процэдуру.

Ну, то есть просто есть несколько всяких обёрток, которые создают разные proc под разные условия.

> но я не придумал красивого апи и пока забил.

Стандартный -- вот https://www.tcl.tk/man/tcl8.4/TclCmd/namespace.html

(Reply to this) (Parent) (Thread)

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

а в принципе, для создания глобала — опять-таки `::` работает.

>Стандартный -- вот
я про сишный апи, у меня ж упор на то, чтобы это было удобно использовать из сишного кода. при этом я принципиально не хочу светить наружу внутренностями: все объекты просто opaque pointers.

впрочем, щаз поменяю, наверное, пусть прок создаёт глобал. если надо nested — есть ламбды, которые внутри ничем от проков не отличаются всё равно.

(Reply to this) (Parent)

Вообще, мне не до конца понятно -- зачем нужны nested procs, если уж так.

(Reply to this) (Parent) (Thread)

Ну, в смысле -- при наличии полулямбды из текста зачем они нужны.

(Reply to this) (Parent)

> tcl — хорошо!
Да. Это так.