Если язык не позволяет создать эффективный и удобный массив как библиотеку, значит он не позволит создать свою структуру данных, эффективную и удобную.
Впрочем, я не до конца согласен с автором поста. 90% объектов-контейнеров использующихся в коде - это одномерный список, который хочется фильтровать, итерироваться, склеивать, надеятся на помощь оптимизатора, использовать сжатый удобный синтаксис для всего этого.
Вам не кажеться, что: "наличие массивов в языке как встроенных типов, а не библиотеки" != "язык не позволяет создать эффективный и удобный массив как библиотеку"?
Если можно без потерь библиотекой, то лучше не встраивать - легче работать с таким, когда всякие множества-очереди-стеки-хешмапы-массивы-двусвязные списки-сортировки отделены от внутренностей транслятора. И автору транслятора (авторам трансляторов), и пользователям транслятора (трансляторов).
легче работать с таким, когда всякие множества-очереди-стеки-хешмапы-массивы-двусвязные списки-сортировки отделены от внутренностей транслятора
Всё-равно не вижу противоречия. Как изменится реализация от множеств-очереди-etc в зависимости от наличия/отсутствия встроенного типа "массив" (кстати, если будет встроенный список -- тоже нормально)?
Понятно, что наличие такого встроенного типа несколько усложняет транслятор. Но есть мнение что профит от краткого синтаксиса оказажется более весомым, нежели это усложнение.
(with-troll-mode (:fat t) Хотя в правильных языках мы всегда можем добавить нужную нам языковую конструкцию средствами самого языка... )
я вообще так далеко не заходил и имел в виду то, что массивы, обычно, это единственный "особенный" тип данных, ака тип с параметрическим полиморфизмом. реализованный как-то сбоку и криво. И еще часто под них забивают спец-операторы вроде квадратных скобок, что все потом очень раздражает т.к. нарушает единообразность системы типов и понятий языка.
наоборот - в них массивы реализуются библиотекой и не имеют встроенного синтаксиса. Все остальные языки - языки, в которых массивы - "особенный" тип. Скажем, в традиционных алголообразах есть два особенных типа - структура и массив.
Вот я и просил примеры языков, где массивы - "это единственный "особенный" тип данных". Я таких не знаю. Не вижу, чем массив в этом аспекте отличается от, например, ссылки (полиморфизм присутствует, спец синтаксис тоже). А нередко кроме массивов есть встроенные в язык хэши и списки.
Reply
Если язык не позволяет создать эффективный и удобный массив как библиотеку, значит он не позволит создать свою структуру данных, эффективную и удобную.
Впрочем, я не до конца согласен с автором поста. 90% объектов-контейнеров использующихся в коде - это одномерный список, который хочется фильтровать, итерироваться, склеивать, надеятся на помощь оптимизатора, использовать сжатый удобный синтаксис для всего этого.
Reply
Reply
Reply
Всё-равно не вижу противоречия. Как изменится реализация от множеств-очереди-etc в зависимости от наличия/отсутствия встроенного типа "массив" (кстати, если будет встроенный список -- тоже нормально)?
Понятно, что наличие такого встроенного типа несколько усложняет транслятор. Но есть мнение что профит от краткого синтаксиса оказажется более весомым, нежели это усложнение.
(with-troll-mode (:fat t)
Хотя в правильных языках мы всегда можем добавить нужную нам языковую конструкцию средствами самого языка... )
Reply
Reply
Reply
Reply
Reply
Reply
Reply
Просто смущает, когда у иерархии типов несколько вершин.
Патологический случай - Java, например :) (все value-типы - не обьекты)
В C# вот массивы - это "отдельный" тип данных (там есть concrete types, generic types и arrays)
В питоне списки отдельный тип, но при этом они не претендуют на особое место в системе типов, а вот old-style классы - претендуют.
Reply
Leave a comment