naive typing ©

[wizzard]

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

Comments

[dark-aurel.livejournal.com]

Почему?

[http://users.livejournal.com/_winnie/]

Например, такое рассуждение:

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

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

[dark-aurel.livejournal.com]

Вам не кажеться, что: "наличие массивов в языке как встроенных типов, а не библиотеки" != "язык не позволяет создать эффективный и удобный массив как библиотеку"?

[http://users.livejournal.com/_winnie/]

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

[dark-aurel.livejournal.com]

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

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

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

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

[wizzard]

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

[thedeemon.livejournal.com]

А можно примеров таких языков?

[nponeccop.livejournal.com]

lisp, erlang

[thedeemon.livejournal.com]

И в них массивы - "это единственный "особенный" тип данных, ака тип с параметрическим полиморфизмом"?

[nponeccop.livejournal.com]

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

[thedeemon.livejournal.com]

Вот я и просил примеры языков, где массивы - "это единственный "особенный" тип данных". Я таких не знаю. Не вижу, чем массив в этом аспекте отличается от, например, ссылки (полиморфизм присутствует, спец синтаксис тоже). А нередко кроме массивов есть встроенные в язык хэши и списки.

[wizzard]

Ссылки с адресной арифметикой - это и есть пример спец. типа данных. Я, возможно, зря сказал, что "единственный"

Просто смущает, когда у иерархии типов несколько вершин.

Патологический случай - Java, например :) (все value-типы - не обьекты)

В C# вот массивы - это "отдельный" тип данных (там есть concrete types, generic types и arrays)

В питоне списки отдельный тип, но при этом они не претендуют на особое место в системе типов, а вот old-style классы - претендуют.

[ev-genus.livejournal.com]

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

[nponeccop.livejournal.com]

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

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

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

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

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

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

S *
A 0 *
R (* *)

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

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

[wizzard]

Без встроенных типов не совсем очевидно, как из этого генерировать эффективный байткод\нейтив код. А вообще, см. коммент про "особенный тип" - основная претензия именно к этому.

Да, еще a must чтобы типы были first-class citizens, вот. Иначе скучно и никакой meta-extensibility

[nponeccop.livejournal.com]

> a must чтобы типы были first-class citizens

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

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

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

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

[nponeccop.livejournal.com]

В бекенде нужно что-то подобное typed assembly language с адресной арифметикой. Во фронт-энде - возможность безопасной реализации чего-то (в том числе, скажем, unboxed-unchecked arrays) поверх этого TAL.

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

[wizzard]

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

[nponeccop.livejournal.com]

читайте литературу