Что делает Tcl уникальным по отношению к другим скриптовым языкам (Python, Ruby, etc)? Есть ли у него какие-то неоспоримые преимущества, из-за чего стоит отдать ему предпочтение? Это не holy war, хочется конструктивных ответов, если такое возможно.

Здравствуйте, frontsquat, Вы писали:

F>Что делает Tcl уникальным по отношению к другим скриптовым языкам (Python, Ruby, etc)? Есть ли у него какие-то неоспоримые преимущества, из-за чего стоит отдать ему предпочтение? Это не holy war, хочется конструктивных ответов, если такое возможно.

Синтаксический минимализм a-la lisp. Что облегчает стиль с использованием мета-программирования.
Преимущество это или недостаток — зависит от задачи.

F>Что делает Tcl уникальным по отношению к другим скриптовым языкам (Python, Ruby, etc)? Есть ли у него какие-то неоспоримые преимущества, из-за чего стоит отдать ему предпочтение? Это не holy war, хочется конструктивных ответов, если такое возможно.

Добавлю к предыдущему докладчику ещё легкость интеграции с Си и командно-ориентированный синтаксис.

Код расширений тикля (со второй попытки пишется очень просто.

Здравствуйте, thesz, Вы писали:

F>>Что делает Tcl уникальным по отношению к другим скриптовым языкам (Python, Ruby, etc)? Есть ли у него какие-то неоспоримые преимущества, из-за чего стоит отдать ему предпочтение? Это не holy war, хочется конструктивных ответов, если такое возможно.

T>Добавлю к предыдущему докладчику ещё легкость интеграции с Си и командно-ориентированный синтаксис.

T>Код расширений тикля (со второй попытки пишется очень просто.

Ага. А можно интересных примеров кода, чтобы на практике посмотреть всю эту красоту? Интересует мета-программирование. Как там обстоит дело с алгебраическими типами и паттерн матчингом? Легко ли это реализуется? Вообще посмотреть на реализацию какого-нибудь компилятора, какого-нибудь простого языка, для какой-нибудь простой виртуальной машины, ну или просто ассемблера — было бы замечательно. Есть такое?

Здравствуйте, mkizub, Вы писали:
M>a-la lisp

Зачем использовать что-то a-la lisp, если можно использовать lisp?

F>>>Что делает Tcl уникальным по отношению к другим скриптовым языкам (Python, Ruby, etc)? Есть ли у него какие-то неоспоримые преимущества, из-за чего стоит отдать ему предпочтение? Это не holy war, хочется конструктивных ответов, если такое возможно.
T>>Добавлю к предыдущему докладчику ещё легкость интеграции с Си и командно-ориентированный синтаксис.
T>>Код расширений тикля (со второй попытки пишется очень просто.
F>Ага. А можно интересных примеров кода, чтобы на практике посмотреть всю эту красоту? Интересует мета-программирование.

Реализуется двояко:
— можно кодогенерацией
— можно абстракцией, наподобие моих алгебраических типов или goto

F>Как там обстоит дело с алгебраическими типами и паттерн матчингом? Легко ли это реализуется?

http://wiki.tcl.tk/9547

F>Вообще посмотреть на реализацию какого-нибудь компилятора, какого-нибудь простого языка, для какой-нибудь простой виртуальной машины, ну или просто ассемблера — было бы замечательно. Есть такое?

Ассемблер делается просто, как у всех:

set r {} ;# Наша программа из пар "адрес+слово"
set addr 0
array set labels {}
proc asm_word {cop} {
    global r addr
    lappend r $addr $cop
}

array set regs {
  zero 0
  r0 0
  sp 29
  r29 29
}

proc asm_regi {r shift} {
    global regs
    return [expr $regs($r) << $shift]
}

proc asm_arith_reg {op d a b} {
    asm_word [expr ($op<<20) | [asm_regi $d 15] | [asm_regi $a 10] | [asm_regi $b 5] ]
}

proc add {d a b} {
    asm_arith 0 $d $a $b
}

# Зарегистрируем [url=http://wiki.tcl.tk/795]unknown[/url] для распознавания меток.
set old_unknown_code [info body unknown]
proc unknown {args} {
    set cmdName [lindex $args 0]
    if {[regexp -- {([a-zA-Z_$][a-zA-Z_$0-9]*)\:} $cmdName _ labelName]} {
        global labels addr
        set labels($labelName) $addr
        return ""
    }
    global old_unknown_code
    eval $old_unknown_code
}

Дальше делаешь так:

source asm.tcl
start: ;# пройдёт через unknown и станет меткой.
  asm_add r0 r1 r2
loop:
  asm_jump loop # Понятно, как сделать? ;)

unknown
regexp
синтаксис регулярных выражений
array set

Плюс-минус, у меня под рукой Tcl нет.

Здравствуйте, frontsquat, Вы писали:

F>Ага. А можно интересных примеров кода, чтобы на практике посмотреть всю эту красоту? Интересует мета-программирование. Как там обстоит дело с алгебраическими типами и паттерн матчингом? Легко ли это реализуется? Вообще посмотреть на реализацию какого-нибудь компилятора, какого-нибудь простого языка, для какой-нибудь простой виртуальной машины, ну или просто ассемблера — было бы замечательно. Есть такое?

XOTcl можно посмотреть для примера.

Здравствуйте, frontsquat, Вы писали:

F>Что делает Tcl уникальным по отношению к другим скриптовым языкам (Python, Ruby, etc)? Есть ли у него какие-то неоспоримые преимущества, из-за чего стоит отдать ему предпочтение? Это не holy war, хочется конструктивных ответов, если такое возможно.

У Фридла нашел что-то про регулярные выражения в TCL: якобы не хуже, чем в Perl. Но это так, Рабинович по телефону напел.
Простой синтаксис.
Развитая система namespace аналогичная C++.
Виртуальная файловая система, к которой не нужно добираться через библиотеки, как в Perl и Python.
Манипуляции контекстом выполнения (перевожу: можно любой скрипт, какой нравится, выполнить в любом доступном namespace, посмотреть список переменных в конкретном namespace ит.д.).

А вот минусы:
Очень критичен к лишним или недостающим пробелам, причем, в отличие от Python, где ident error возникает при компиляции, в TCL ты на него нарываешься только при исполнении.
Корявая система путей (нет переменных, аналогичных @INC или sys.path). И не спрашивайте меня, что же есть. Мне не удалось понять, как можно самому добавить в путь поиска мою собственную библиотечную директорию.
Убогий набор типов данных: хэш, который, в отличие от Perl, нельзя передавать в/из функции, строка, массив. Правда, в отличие от Perl, массивы могут быть вложенными.
Главный минус: язык помирает. Нет того числа дополнительных библиотек, которые есть в Perl или Python. А жаль, все-таки первый скриптовый язык в моей жизни. Так скать, первая любовь

Здравствуйте, Аноним, Вы писали:

А>А вот минусы:
А>Очень критичен к лишним или недостающим пробелам, причем, в отличие от Python, где ident error возникает при компиляции, в TCL ты на него нарываешься только при исполнении.
Что-то не сталкивался, а есть примеры? Или имеются в виду случаи типа if{... ? Так тут очевидно, что если рассматривать все языковые конструкции как команды, то аргументы должны быть разделены пробелами и отделены от команды.
А>Корявая система путей (нет переменных, аналогичных @INC или sys.path). И не спрашивайте меня, что же есть. Мне не удалось понять, как можно самому добавить в путь поиска мою собственную библиотечную директорию.

lappend auto_path /my/mega/library/dir

А>Убогий набор типов данных: хэш, который, в отличие от Perl, нельзя передавать в/из функции, строка, массив. Правда, в отличие от Perl, массивы могут быть вложенными.
хэш это array? можно передавать в функцию по имени, например:

proc array.contains {arr key} {
    global $arr
    return [list.contains [array names $arr] $key]
}

А>Главный минус: язык помирает. Нет того числа дополнительных библиотек, которые есть в Perl или Python. А жаль, все-таки первый скриптовый язык в моей жизни. Так скать, первая любовь
Тут не знаю, по-моему до смерти ему далеко, пока его пользуют Cisco, Aptixia, Agilent, Spirent и др.

Здравствуйте, komaz, Вы писали:

K>Что-то не сталкивался, а есть примеры? Или имеются в виду случаи типа if{... ? Так тут очевидно, что если рассматривать все языковые конструкции как команды, то аргументы должны быть разделены пробелами и отделены от команды.

for {set i 0} {$i < 5} {incr i} {puts $i}

Попробуй убери любой из пробелов между блоками в фигурных скобках, или перенеси последний блок (без escape) на новую строку, или поставь escape, а после него на той же строке пробел.... Могу до бесконечности перечислять, хотя Python-у проблемы такого рода тоже свойственны. Но даже в Python нет требования, чтобы в закомментированных блоках число открывающих и закрывающих скобок было одинаково:

for {set i 0} {$i < 5} {incr i} \
{

#{
    puts $i
}

А в результате:

missing close-brace: possible unbalanced brace in comment
while executing
"for {set i 0} {$i < 5} {incr i} \
{

#{
puts $i
}"
(file "1.tcl" line 1)

K>

K>lappend auto_path /my/mega/library/dir
K>

auto_path дает путь поиска библиотеки, на работу команды source она не влияет, насколько я помню. В Python или Perl есть возможность задать путь для поиска обыкновенного определенного пользователем модуля. Отдельного модуля, не входящего ни в какую библиотеку. А тут требуется создать библиотеку. Зачем мне это? Ну вот создаю я приложение из нескольких отдельных файлов (чтоб мухи отдельно, котлеты отдельно). На Python или Perl можно обойтись без библиотек, тупо задать, где файлы лежат — для того существуют на Perl @INC, а в Python — sys.path. В TCL меня понуждают создавать для этих целей библиотеку, используя соответствующие утилиты ит.п. Не очень, ИМХО, удобно. То есть, пока ты запускаешь приложение из того же каталога, где лежат файлы — нет проблем, он их всех видит. А попробуешь из другого.....


K>хэш это array? можно передавать в функцию по имени, например:
K>

K>proc array.contains {arr key} {
K>    global $arr
K>    return [list.contains [array names $arr] $key]
K>}
K>

Ну да, верно, в TCL это называется array, в Perl — hash, в Python — dictionary. Еще его можно передавать с помощью array get / array set. А в Python и Perl он передается как любая другая переменная, глобальная или локальная, без всякого рода перверсий с видимостью, сборкой/разборкой ит.п.

K>Тут не знаю, по-моему до смерти ему далеко, пока его пользуют Cisco, Aptixia, Agilent, Spirent и др.

А еще Mentor Graphics (ModelSim), Actel (Designer), как язык макросов. О жизнеспособности и перспективах языка я сужу по: количеству литературы по нему, количеству обсуждений в форумах, количеству проектов, количеству дополнительных модулей и библиотек. Увы, TCL, пока (или уже?) — экзотика.
Например, даже на OZONе я не сумел достать даже англоязычную TCL Pocket Reference издательства O'Raily (я эти покет-буки коллекционирую )
Повторяю, мне жаль его, это был неплохой язык, по-своему интересный. Я его очень любил.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, komaz, Вы писали:

А>

А>for {set i 0} {$i < 5} {incr i} {puts $i}
А>

А>Попробуй убери любой из пробелов между блоками в фигурных скобках, или перенеси последний блок (без escape) на новую строку, или поставь escape, а после него на той же строке пробел.... Могу до бесконечности перечислять, хотя Python-у проблемы такого рода тоже свойственны.
Ну, тут, по-моему, ошибиться сложно, т.к. for — команда, принимающая 4 аргумента. В командной строке же никто не забывает аргументы пробелами разделять, аналогично с переводами строк. С комментариями, конечно, да, дали маху они

А>auto_path дает путь поиска библиотеки, на работу команды source она не влияет, насколько я помню. В Python или Perl есть возможность задать путь для поиска обыкновенного определенного пользователем модуля. Отдельного модуля, не входящего ни в какую библиотеку. А тут требуется создать библиотеку. Зачем мне это? Ну вот создаю я приложение из нескольких отдельных файлов (чтоб мухи отдельно, котлеты отдельно). На Python или Perl можно обойтись без библиотек, тупо задать, где файлы лежат — для того существуют на Perl @INC, а в Python — sys.path. В TCL меня понуждают создавать для этих целей библиотеку, используя соответствующие утилиты ит.п. Не очень, ИМХО, удобно. То есть, пока ты запускаешь приложение из того же каталога, где лежат файлы — нет проблем, он их всех видит. А попробуешь из другого.....

создаем папку, кладем туда нужные сорц-файлы и рядом с ним pkgIndex.tcl с одной строчкой:

package ifneeded mymegalib 1.0 [list source [file join $dir mymegalib.tcl]]

и в mymegalib.tcl-файле написать:

package provide foo 1.0
set my_dir [file dirname [file join [pwd] [info script]]]
source [file join $my_dir file1.tcl]
source [file join $my_dir file2.tcl]
...

А>Повторяю, мне жаль его, это был неплохой язык, по-своему интересный. Я его очень любил.
Соглашусь, с этой точки зрения мертв. Мне вот пришлось по работе изучить его, сначала плевался, а теперь так очень нравится. Радует что реально удобно писать кросплатформенные скрипты, поскольку я его знаю гораздо лучше чем какой-нибудь там batch или bash. Еще есть всякие полезные команды в стандартной поставке, например я привык создавать на Tcl симлинки — поскольку у меня он стоит и под виндой, и под линуксом, то можно не париться и под любой платформой писать:

 
file link -symbolic video e:/video

Здравствуйте, Аноним, Вы писали:

А>Корявая система путей (нет переменных, аналогичных @INC или sys.path). И не спрашивайте меня, что же есть. Мне не удалось понять, как можно самому добавить в путь поиска мою собственную библиотечную директорию.

Попробуйте так:

lappend ::auto_path {c:\my-tcl-libs}
package require my_tcl_package
... type your code here ...