Вышел Jim Tcl 0.75

Это какой-то форк?

Версия тикля там какая?

словарей (ассоциативных массивов)

Хешей, что ли?

Это независимая реализация местами-обратно-совместимого языка.

dict'ов

Про jim не уверен, что там хеши, могут быть и деревья. Но суть вы уловили. Кстати, в современно Tcl словари сохраняют порядок элементов, а в jim нет.

Нафига их сохранять-то? Это ж хеши (ну или словари).

Так и написали бы.

Он не тождественно совместим с основным Tcl. Текущая версия Jim примерно соответствует 8.5/8.6.

Ассоциативные массивы таки хэши. Но словари это нихрена не ассоциативные массивы, это обычне списки. dict - просто способ работать со списком. Однако если в jim словари не сохраняют порядок, это подводит нас к мысли что в jim словари таки - хэши. Смею предположить что jim будет работать с ними гораздо быстрее чем ванильный тикль или ActiveState. Это хорошо. С другой стороны у меня в одном проекте есть таки функии полагающиеся на то что порядок в словарях не изменяется. ЕМНИП: я сделал это как раз чтобы повысить прозводительность.

Ужо догадлся по dict ;) Но спасибо. Вообще стоит трогать?

Дык так и написали... только по русски ;)

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

В мейнстримном Tcl dict — не просто способ работать со списком, это отдельный objtype. И там внутри... хэши. Да, он сохраняет упорядоченность, и для этого специально вводится двусвязный список hash entries.

Когда в Tcl 8.5 появились dict, в той альфе, где они появились, порядок ключей не сохранялся. Сохранение порядка добавили потом (довольно извращённое решение, но не ужас-ужас, потому что релиза с неупорядоченными dict'ами, по-моему, не было). Добавили именно потому, что стоимость оказалась околонулевой, а польза быть может. Так что едва ли jim будет «гораздо быстрее».

Мне кажется, да. Единственный недостаток — это отсутствие полной обратной совместимости (не страшно, если внешних зависимостей мало) и отсутствие документации на C API, хотя там всё из исходников понятно.

Авторы в 2011 году заявляли, что stable C API отсутствует, но за 1.5 года наблюдений вроде ничего не поменялось.

В мейнстримном Tcl dict — не просто способ работать со списком, это отдельный objtype. И там внутри... хэши.

Это точно? Просто дикт вполне себе обрабатывается как список. Для него ведь не нужно ничего вроде array get

Хотел написать, но LeninGad опередил и он абсолютно прав. Просто переменная типа dict имеет (тащит за собой) параллельное представление в виде списка. Оверхед конечно, но все скриптовые языки так, ничего удивительного. Это ж не си, другие задачи.

Точно. Обратите внимание, что и «списки» притворяются строкой, хотя строковое представление для них генерируется при необходимости, и если список сформирован «списочной» командой, у него строкового представления нет (пока его не попытаются использовать как строку).

Основная идея работы с типами в Tcl8 — именно такое прозрачное преобразование. Традиционно «общим знаменателем» для типов является строка, но преобразование типов не через строку тоже можно обеспечить. Интересно, что «преобразователь» SetDictFromAny использует готовое списочное представление, если оно есть, но если есть только строковое — никакого промежуточного списка не формируется.

переменная типа dict имеет (тащит за собой) параллельное представление в виде списка

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

Hash entries для dict собираются в двусвязный список, но этот «список» ничего общего не имеет со встроенным типом «список» (tclListType). Последний неудобен для вставок и удалений, он сильно тормозил бы при таком использовании.

У Tcl_Obj может быть максимум два представления: строковое и некое «внутреннее». В каждый момент времени у объекта присутствует хотя бы одно, иногда оба. Значение не может одновременно иметь tclListType и tclDictType в качестве внутреннего представления. Тот двусвязный список, который используется для упорядочивания ключей — часть внутреннего представления tclDictType.

Кстати, это означает, что вот так делать не надо никогда:

foreach {key value} $mydict { ... }

По смыслу dict for {key value} $mydict {...} не отличается ничем, но foreach преобразует значение dict'а в список (как минимум это лишнее копирование, но в неудачном случае можно потерять цепочку hash entries, и она будет заново создаваться при использовании $mydict как словаря.

Оки. Спасибо за разъяснение. И анону тоже спс. Век живи - век учись. Но если строку попытаться использовать как список это тоже сработает. И значит есть обратное преобразование. Теперь возникает вопрос в эффективности таких преобразований...

Теперь возникает вопрос в эффективности таких преобразований...

Ещё как возникает. За подробностями можно сходить на http://wiki.tcl.tk/shimmering — там достаточно много возможных неприятностей описано.

Нафига их сохранять-то? Это ж хеши (ну или словари).

1. Реализация ассоциативных массивов может не использовать хеши.

2. Хеши используются не только для реализации ассоциативных массивов.

Нафига их сохранять-то? Это ж хеши (ну или словари).

Это не хэши, а ассоциативные словари. Сохранение порядка может быть удобно.

В jim тоже сохраняют.