wizzard: (Default)
wizzard ([personal profile] wizzard) wrote2009-09-14 06:42 pm

naive typing ©

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

[identity profile] dark-aurel.livejournal.com 2009-09-14 03:54 pm (UTC)(link)
Почему?

[identity profile] http://users.livejournal.com/_winnie/ 2009-09-14 07:48 pm (UTC)(link)
Например, такое рассуждение:

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

Впрочем, я не до конца согласен с автором поста. 90% объектов-контейнеров использующихся в коде - это одномерный список, который хочется фильтровать, итерироваться, склеивать, надеятся на помощь оптимизатора, использовать сжатый удобный синтаксис для всего этого.

[identity profile] dark-aurel.livejournal.com 2009-09-14 08:39 pm (UTC)(link)
Вам не кажеться, что: "наличие массивов в языке как встроенных типов, а не библиотеки" != "язык не позволяет создать эффективный и удобный массив как библиотеку"?

[identity profile] http://users.livejournal.com/_winnie/ 2009-09-14 08:48 pm (UTC)(link)
Если можно без потерь библиотекой, то лучше не встраивать - легче работать с таким, когда всякие множества-очереди-стеки-хешмапы-массивы-двусвязные списки-сортировки отделены от внутренностей транслятора. И автору транслятора (авторам трансляторов), и пользователям транслятора (трансляторов).

[identity profile] dark-aurel.livejournal.com 2009-09-14 09:15 pm (UTC)(link)
легче работать с таким, когда всякие множества-очереди-стеки-хешмапы-массивы-двусвязные списки-сортировки отделены от внутренностей транслятора

Всё-равно не вижу противоречия. Как изменится реализация от множеств-очереди-etc в зависимости от наличия/отсутствия встроенного типа "массив" (кстати, если будет встроенный список -- тоже нормально)?

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

(with-troll-mode (:fat t)
Хотя в правильных языках мы всегда можем добавить нужную нам языковую конструкцию средствами самого языка... )

[identity profile] thedeemon.livejournal.com 2009-09-15 10:15 am (UTC)(link)
А можно примеров таких языков?

[identity profile] thedeemon.livejournal.com 2009-09-15 06:20 pm (UTC)(link)
И в них массивы - "это единственный "особенный" тип данных, ака тип с параметрическим полиморфизмом"?

[identity profile] nponeccop.livejournal.com 2009-09-15 07:58 pm (UTC)(link)
наоборот - в них массивы реализуются библиотекой и не имеют встроенного синтаксиса. Все остальные языки - языки, в которых массивы - "особенный" тип. Скажем, в традиционных алголообразах есть два особенных типа - структура и массив.

[identity profile] thedeemon.livejournal.com 2009-09-16 04:18 am (UTC)(link)
Вот я и просил примеры языков, где массивы - "это единственный "особенный" тип данных". Я таких не знаю. Не вижу, чем массив в этом аспекте отличается от, например, ссылки (полиморфизм присутствует, спец синтаксис тоже). А нередко кроме массивов есть встроенные в язык хэши и списки.

[identity profile] ev-genus.livejournal.com 2009-09-14 09:45 pm (UTC)(link)
тем временем я все более и более прихожу к выводу что наличие в языке встроенных типов, есть жуткая ересь

[identity profile] nponeccop.livejournal.com 2009-09-14 11:09 pm (UTC)(link)
Тут можно пойти дальше - наличие в языке встроенной фиксированной системы типов есть жуткая ересь. Т.е. в правильных языках мы всегда можем определить нужную нам систему типов средствами самого языка.

Как простейший вариант подобной системы, можно сделать язык, позволяющий использовать в качестве систем типов произвольные Pure Type Systems. Это колоссальная свобода - можно в каждом модуле декларировать, какую именно PTS он использует. Где-то можно ограничиться импредикативным полиморфным ЛИ (System F):

S * #
A * #
R (* *) (# *)

А где-то понадобится calculus of constructions с зависимыми типами:

S * #
A * #
R (* *) (# *) (* #) (# #)

А где то вообще простым типизированным ЛИ даже без констант типов:

S *
A 0 *
R (* *)

Т.е. на основе обобщенных систем типов (PTS я привел как пример системы, в которой выражается множество разных систем типов) можно сделать весьма универсальный (и простой!) тайпчекер, покроющий огромное количество известных систем типов.

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

[identity profile] nponeccop.livejournal.com 2009-09-15 02:09 pm (UTC)(link)
> a must чтобы типы были first-class citizens

отнюдь. В сложных универсальных системах типов пропадают важные свойства - например, principal typing.

> Иначе скучно и никакой meta-extensibility

Meta-extensibility можно достичь и без мудрёной системы типов, путем quoting в стиле лиспа.

Поэтому в принципе для разных задач оптимальны разные системы типов и разные средства метапрограммирования.

[identity profile] nponeccop.livejournal.com 2009-09-14 11:37 pm (UTC)(link)
В бекенде нужно что-то подобное typed assembly language с адресной арифметикой. Во фронт-энде - возможность безопасной реализации чего-то (в том числе, скажем, unboxed-unchecked arrays) поверх этого TAL.

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

[identity profile] nponeccop.livejournal.com 2009-09-15 01:39 pm (UTC)(link)
читайте литературу