Julia: сумасшедшая идея: изменить ключевое слово `type`

Было бы здорово сделать слово type пригодным для использования в других контекстах.

Мне нравится mutable за последовательность.

Если это будет сделано, это нужно сделать как можно скорее, чтобы его можно было включить в 0.6

Если это произойдет, используйте то, что все узнают, прежде чем подумать: struct

Я также считаю, что type немного неудобно. Когда я объясняю это другим людям, я обычно говорю «как структура», так что +1 за это.

Если это произойдет, используйте то, что все узнают, прежде чем подумать: struct

Я думал, что immutable похоже на структуру?

+1 за mutable

immutable имеет макет памяти структуры C
type имеет изменчивость структуры C

Таким образом, структура связана с обоими. Я думаю, что mutable вместо struct лучше прояснить это.

Любая переменная изменчива. Присвоение этой метки общепризнанному имени ( struct ) для меня почти очевидно.

Для тех, кто пришел из Фортрана, ключевое слово type уже естественно.
Для кого-то из C ключевое слово struct было бы естественным.
Для тех, кто много использует immutable , противоположное ключевое слово mutable будет естественным.

Так что, возможно, нам стоит оставить все как есть.

struct{mutable}
struct{immutable}

или же

record{mutable}
record{immutable}

если желательна более описательная форма.

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

Я подозреваю, что программисты на Фортране знакомы с термином «структура».

+1 за mutable из-за согласованности. Если бы были выбраны struct , разве согласованность не потребовала бы изменения неизменяемого на что-то вроде const struct ? ;)

Я думаю, что struct и immutable struct самом деле были бы неплохими; struct - очень знакомый термин, и нам нужно добавить только одно новое ключевое слово. Разрешение mutable struct тоже может иметь смысл, хотя это и не обязательно.

Я должен пояснить, что, по моему мнению, существительное struct является преимуществом. Было бы лучше не использовать только прилагательные для обозначения этих вещей.

Добавление struct к immutable struct добавляет ненужный линейный шум, тем более, что привыкание не набирать это.

Ото, я считаю, что в Фортране есть ключевое слово type которое делает нечто очень похожее на то, что делает наше. Однако я не прочь изменить это.

@KristofferC выше прав: я также говорю "структура", объясняя, что это такое. Даже во внутренних обсуждениях type было проблемой; кто-то скажет «предположим, что x - это тип», и неясно, означает ли это «объект, объявленный ключевым словом type » или «тип» в другом смысле.

Если эти имена действительно есть в таблице ( s/type/new name/ кажется несколько неприятным), я бы посоветовал нам максимально использовать эту возможность, чтобы сделать объявление по умолчанию неизменным.
Таким образом, struct заменит immutable , а mutable [struct] заменит type.

В качестве мысли, еще один возможный термин для изменчивого может быть Ref .

Другое возможное имя - composite , поскольку общий термин CS для этого типа является составным . Но я по-прежнему предпочитаю mutable Foo и immutable Foo вместо mutable struct Foo и immutable struct Foo - struct (или composite , или class или что-то еще) кажется лишним.

: +1: к существительным

Мне всегда нравился type больше, чем struct в Джулии (хотя у меня был опыт _C_), потому что типы данных Джулии гораздо более мощные и тонкие, и я думаю, что "struct" может быть немного упрощенным за идею. Я также чувствую, что, поскольку это новый язык, мы не должны быть связаны соглашениями, к которым привыкли опытные программисты - вам также следует подумать, «какое слово лучше всего объяснить человеку, чей первый язык - Джулия».

Я также говорю "структура", когда объясняю, что это

Представьте, что вы знакомите новичка с struct T затем сообщаете им T::DataType и вы можете отправлять сообщения с помощью ::Type{T} , при этом объясняя «мощную систему типов» Джулии. Я думаю, что это просто ударит по дороге в будущем.

быть существительным - преимущество

: +1: к существительным

Вероятно, стоит отметить, что прилагательные латинской семьи, такие как «изменчивый», грамматически также могут быть существительными в своем родном языке. Вот почему, когда мы спрашиваем «какова существительная форма изменчивого?», Мы пожимаем плечами. Но мы всегда говорим «переменная», и на языке Джулии я бы сказал: «Давайте для этого введем неизменяемый». К сожалению, сначала это кажется неудобным из-за германских корней английской грамматики - но это действительно часто случается в английском (потому что мы также основываемся на французском и латыни), но со временем к этому привыкаешь.

Наконец, поскольку тема - «сумасшедшая идея», эти ключевые слова более или менее образуют новый DataType поэтому можем ли мы полностью удалить ключевые слова и просто использовать конструктор?

# Similar-ish to current
MyType = DataType(
    a::Int,
    b::Float64
)

# A DataFrame-like constructor
MyType = DataType(a = Int, b = Float64)

Я предполагаю, что они должны быть специально (статически) проанализированы, как ccall , и на данный момент они могут быть вызваны только на верхнем уровне. (Также - не уверен, понадобятся ли нам Mutable <: DataType и Immutable <: DataType и BitsType <: DataType чтобы охватить все возможности, и, вероятно, const для привязки).

Я думал, что неизменяемый - это как структура?

неизменяемый имеет макет памяти структуры C
Тип имеет изменчивость структуры C

Верно ... Мне кажется, я думал о Swift, где:

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

что звучит как immutable vs type , и это только ссылка, которая допускает изменчивость в контексте семантики привязок Julia.

DataType включает все номинальные типы: abstract , битовые типы, неизменяемые и изменяемые структуры. Так что замена type на DataType не добавляет большой ясности. Я также делаю другой вывод из сценария «новичок»: ::Type и ::DataType выбирают надмножества вещей, определенных в type T , поэтому для них не безумие иметь разные имена. . « struct - это один из видов Type » имеет больше смысла, чем « type - это один из видов Type ».

Я согласен, что прилагательные на практике могут служить существительными. Можно сказать, например, «это неизменный». Я просто считаю, что они недостаточно информативны. Вместо того, чтобы говорить вам, что это за вещь, она просто говорит вам, что чем бы она ни была, вы можете / не можете ее видоизменить.

Мне нравятся типы structure и mutable structure . возможно a = 1 и mutable a = 1 для присвоения переменных. Отказ от идеи согласованности, отсутствия сокращений и неизменности по умолчанию.

Изменить: возможно, constant вместо const в случае изменчивости по умолчанию

Или версия с меньшим количеством ключевых слов: struct vs. const struct . Я думаю, что создание всех переменных по умолчанию будет слишком разрушительным.

Я просто считаю, что они недостаточно информативны. Вместо того, чтобы говорить вам, что это за вещь, он просто говорит вам, что что бы это ни было, вы можете / не можете его видоизменить.

Это хороший момент, но я считаю, что поведение ссылки и поведение «значение» намного важнее и интереснее для описания, чем «это структура или битовый тип?» (в основном потому, что bitstype появляется не очень часто - каждый созданный мной тип Julia является структурой). Неизменяемость - это просто следствие семантики привязки и передачи по значению.

Чтобы полностью исключить необходимость использования struct vs bitstype мы могли бы также включить эту идею из @quinnj, который был

immutable 32 Int32 <: Integer

или у вас могут быть неукрашенные поля как количество бит

immutable Int32 <: Integer
   32
end

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

Тогда это просто выбор между типом значения (что в настоящее время неизменяемым) и ссылочным типом (что в настоящее время является изменяемым, но потенциально с полями const в будущем, что является еще одной причиной не называть его mutable ) и соответствующие имена необходимы, чтобы различать их. И , наконец, используя struct для ссылочного типа значения смутит Swift программистов ...

Это правда, что bitstype почти исчез с тех пор, как был введен immutable . Но есть еще кое-что, что нужно различать, чем структура и биты: есть абстрактные типы, кортежи (также неизменяемые) и, вероятно, неизменяемые записи в будущем.

Первоначально мы выбрали immutable так как считали, что это будет наиболее заметная отличительная черта: в отличие от других объектов, вы не можете их изменять. Фактически, они _не_ всегда передаются по значению; неизменность означает, что вы не заметите разницы. Некоторые immutable встроены в массивы и другие объекты, а некоторые нет. Неизменяемость означает, что различие не вызывает проблем для простого кода julia; это становится проблемой только тогда, когда структура памяти действительно имеет значение, например, для взаимодействия C.

Фактически, они _не_ всегда передаются по значению

Хорошая точка зрения! Хотя есть планы изменить это, верно?

Думаю, я говорю, что вам понадобится набор ключевых слов, пригодных для будущего, который отражает некоторые перспективные концепции, поскольку мы приближаемся к версии 1.0. Когда неизменяемые объекты встроены, кажется, что сейчас самое время переименовать их во что-то полезное с точки зрения итоговой семантики (и если эта семантика помогает с FFI, это даже лучше).

Я не думаю, что люди будут путать новые ключевые слова определения типа с abstract , Tuple s и "записями" (что, если вы имеете в виду предлагаемую подобную кортежу вещь с именами полей, я думаю Я также слышал, что раньше меня называли «структурами» ...).

Настоящая цель понятия «передача по значению» - ответить на вопрос о том, что происходит, когда f(x) модифицирует (в некотором смысле) x : модифицирует ли он тот же x передал вызывающий абонент, или модификация только локальная? У Джулии никогда не было и никогда не будет (я надеюсь) типов, аргументов или функций, которые отличаются таким поведением. Все проходит по принципу обмена. Для нас передача по значению существует только на уровне ABI, но это обсуждение относится только к разделу FFI руководства. Я не уверен, что у нас когда-нибудь будет тип, который всегда передается по значению или всегда встраивается, поскольку это может хуже работать с большими объектами.

В любом случае, я действительно думаю, что immutable и mutable - приемлемые варианты ключевых слов.

Это правда, что bitstype почти исчез с тех пор, как был введен immutable.

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

FWIW, поскольку не было большой поддержки того, чтобы ничего не менять, я думаю, что type и immutable в порядке, так как они есть.

(Синтаксис do меня действительно беспокоит ... ;-)

Все проходит по принципу обмена.

Я могу это уважать - и спасибо за обсуждение.

Все проходит по принципу обмена.

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

type Complex{T}
    const re::T
    const im::T
end

(компилятор может определить, что этот тип неизменяем автоматически, и пользователи могут понять, что типы const позволяют нам компилировать более быстрый код). Тогда type или struct имеют смысл. setfield! можно отключить для полей const в смешанном случае.

А как насчет type и const type ? - Ключевое слово type для меня звучит более элегантно, чем struct, и со структурой я как бы ассоциирую техническую схему памяти, а не объект ~, имеющий, например, внутренние конструкторы. Поскольку составной тип - это «... наиболее часто используемый пользовательский тип в Джулии ...», может быть, не так уж плохо, если «тип - это один из типов Типа»? В общении с использованием «составного типа» следует уточнить, как я бы сказал «абстрактный тип». Что касается линейного шума, «константный тип» не хуже, чем «неизменяемый».

Я не уверен в (небольшой) разнице в значении const с переменными и типами. - В любом случае тип и неизменность всегда давали мне небольшую душевную икоту. Приятно видеть здесь эту проблему!

Основная проблема с использованием struct заключается в том, что люди могут естественным образом делать предположения, к которым они привыкли, из C / C ++, которые не обязательно верны в Julia, например, изменяемый составной тип не сохраняется по значению в массиве, тогда как неизменный.

Какие парадигмы immutable представляют более элегантно, чем type ? Например, атомарный «переход» состояния нескольких полей одновременно без необходимости использования примитивов синхронизации путем создания экземпляра нового неизменяемого объекта из исходного с обновленными желаемыми полями.

Почему тип должен быть разделен на две отдельные категории в точке их определения, а не в точке их отправки / использования (больше как const в C ++)? Используя только type / struct / composite для определения составных типов и введя конструкцию Immutable{T} для преобразования изменяемых в неизменяемые, мы могли бы получить:

type CompositeType end
f(x::Immutable{CompositeType}) = x
a = f(CompositeType())
b = f(a)

Кроме того, можно ли здесь рассмотреть изменения в abstract и bitstype ? AFAICT слово «абстрактное» употребляется как прилагательное, а не как существительное. Должна быть по крайней мере лингвистическая согласованность ключевых слов типа: все существительные, все прилагательные и т. Д. bitstype можно было бы лучше сформулировать как bits или primitive .

Пожалуйста, давайте не будем превращать это в открытую ветку для обсуждения изменений в написании (или семантике!) Ключевых слов Julia. На данный момент корабль плывет по базовому _повведению_ type и immutable . Единственный вопрос, который здесь возникает, - можем ли мы иметь такое написание type и immutable которое лучше отражает их сходство.

Я продолжаю поддерживать mutable против immutable или просто оставляю как есть, как два наиболее разумных варианта на данный момент. Все остальное было бы бессмысленно разрушительным.

@andyferris Мне очень нравится эта идея; некоторая комбинация struct и const была бы хорошей. Если мы пойдем этим путем, я бы также хотел иметь возможность сказать const struct или const type , (1), чтобы не писать const в каждом поле, (2 ), поэтому нам не нужно сразу добавлять новую функцию неизменяемости для каждого поля. Если мы когда-нибудь захотим добавить эту функцию, было бы хорошо, если бы для нее был постоянный словарный запас.

При общении с использованием «составного типа» следует уточнить

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

Почему тип должен быть разделен на две отдельные категории в точке их определения, а не в точке их отправки / использования (больше как const в C ++)?

Это просто: предоставить глобальные гарантии. В C ++ объект "const" все еще может изменяться под вами, если у кого-то есть неконстантная ссылка на него.

Кроме того, можно ли здесь рассмотреть возможность изменения абстрактного и битового типа?

Сделайте предложение. Что касается bitstype , ключевое слово используется очень редко, поэтому я бы не хотел украсть для него такое маленькое полезное слово, как bits .

immutable -> const type мне тоже кажется нормальным. В сочетании с type -> composite или struct , если мы действительно хотим освободить type .

Я не очень доволен всем оттоком кода, который это вызовет, особенно потому, что он не может поддерживаться @compat . Если мы должны это сделать, я думаю, что путь обновления должен быть примерно таким: (1) вводить новые синонимы ключевых слов в 0.6, но _не _ не осуждать старые (из-за отсутствия @compat ), затем (2) не рекомендовать старые в 0.7.

Для bitstype , как насчет того, чтобы назвать это типом primitive ? Текущее имя немного раздражает из-за его сходства с an isbits composite type

Мне нравится, как Джулия часто избегает некоторых сокращений в стиле "def / func / elif" некоторых других языков. (Сокращения Dn w, kthx.) Итак, mutable выигрывает у меня struct .

FWIW, OCaml использует type для записей и вариантов (структур и объединений) и псевдонимов. Я думаю, что в стандартном ML используется datatype .

Симметрия - это хорошо, но я считаю mutable недостаточно описательным; immutable тоже, если на то пошло (мне нравится идея const type ).

Как указывает Стив, это вызовет отток кода в сообществе. И польза сомнительная.

Я определенно вижу случай для const type ; это будет ключевое слово net -1, разъясняющее взаимосвязь между типом и неизменяемым. Было бы действительно неплохо иметь возможность использовать type по-другому. Без этой выгоды гораздо труднее оправдать изменение. Однако обновление кода для этого должно быть очень простым; синтаксис type таков, что его нельзя использовать ни в каком другом контексте.

+1 за composite / const composite .

Мне кажется, что primitive vs composite - отличное отличие, с добавлением ключевых слов const мере необходимости.

Нужно ли нам const primitive чтобы отличать некоторые биты, которые могут измениться (и для согласованности)? Таким образом, симметрично мы имели бы

primitive        # something new... 
const primitive  # bitstype
composite        # type
const composite  # immutable

Проблема с изменяемым примитивным типом должна быть реализована ... (конечно, это могло произойти позже, но мы бы хотели bitstype -> const primitive _now_, если бы это было Проще говоря, это может быть хорошей "практической" целью для внесения изменяемых в стек, но я не эксперт в этом).

Точно так же идея добавления const к отдельным полям композита может быть легко реализована позже, и, что еще лучше, это не критическое изменение.

Если мы пойдем по этому пути, я бы также хотел иметь возможность сказать const struct или const type, (1) чтобы избежать необходимости писать const в каждом поле, (2) поэтому нам не нужно добавлять новую функцию неизменяемость по полю сразу. Если мы когда-нибудь захотим добавить эту функцию, было бы хорошо, если бы для нее был постоянный словарный запас.

Для меня это имеет смысл.

Я просмотрел тип данных composite и обнаружил, что по крайней мере Ada и Visual Basic также включают в него типы массивов. (В противном случае, немного случайным образом, найдено: Haskell: списки и кортежи (однако определение было запрошено); Python: списки, кортежи, dicts; Lisp: списки, вектор, хеш-таблицы, определяемые пользователем классы, структура).

Таким образом, теперь я задаюсь вопросом, насколько точен состав для довольно структурно-подобного type ? (Но я не компьютерный ученый, мне не хватает словарного запаса / обширного видения).

Хм, это может быть правильно: этот конкретный тип типа всегда, кажется, называется структурой, структурой или записью (или классом или объектом), причем термин «составной» является более широким. На http://rosettacode.org/wiki/Compound_data_type есть много примеров.

Было бы неплохо восстановить type в качестве идентификатора и использовать более конкретное имя. Поломка почти каждого тривиального пакета, написанного до ~ 0.6, была бы очень прискорбной, я не знаю, как это взвесить.

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

Что касается имен для замены type , struct похоже, довольно хорошо избегает двусмысленности (я часто нахожу фразы "изменяемый тип" и "неизменяемый тип" слишком похожими).

Полагаю, следующее выглядит неплохо:

struct A
    a::Float64
end

const struct B
    b::Float64
end

Было бы неплохо восстановить тип как идентификатор и использовать более конкретное имя.

Я разделяю это мнение.

Если мы собираемся изменить имена, как мы будем справляться с устареванием? Будут ли type и immutable прежнему действовать в версии 0.6 и, возможно, 1.0 с предупреждениями? Может ли Compat.jl обрабатывать это прозрачно. Немало литературы в сети (сообщения в блогах, учебные пособия и т. Д.) Покажут предупреждения - незначительные неприятности для новичка.

Мы все еще можем зарезервировать type и immutable на более длительный срок, чем обычно, чтобы облегчить переход.

Мы до 1.0: время менять это сейчас или никогда. Наличие более длинного старого ключевого слова, безусловно, хорошо для обеспечения плавного перехода. Я бы не стал путать обсуждение фактического именования с болью, связанной с переходом.

Лично я полностью за то, чтобы называть это struct . Было сказано, что

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

Если изменение будет слишком болезненным, я проголосую против него. Несмотря на то, что изменение pre1.0 оправдано, оценка его с учетом любых вызванных сбоев - это правильный поступок ИМО.

У @stevengj было хорошее предложение о том, как сделать устаревание, и похоже, что @amitmurthy пришла к такому же выводу (держите ключевые слова дольше, чем обычно). Хотя мы все уже давно использовали этот язык, это еще не все, и мы не должны бояться вносить изменения. Это просто простой поиск и замена.

Я пойду и проголосую за struct . Я думаю, что это одно из тех изменений, которые вызовут много шума и жалоб, но на самом деле исправить пакеты / код пользователя не так уж и сложно ... просто сделайте это, и люди поймут это.

immutable -> const type кажется путем наименьшего сопротивления, и IMO определенно следует выполнить. Я думаю, это объясняет вещи намного лучше.

type -> composite более точен, чем type но менее точен, чем struct , но менее жаргонизирован, чем struct (для новые программисты). Он проходит тест Джеффа "написать предложение, чтобы объяснить это новичку" и восстанавливает ключевое слово type . С другой стороны, я не думаю, что composite появляется на других языках, поэтому мы бы идти в одиночку.

type -> struct является наиболее точным, но, возможно, structure будет красивее, чем аббревиатура (я пытаюсь представить аббревиатуру столь же уродливую, как struct другом месте языка и оказался пустым - я полагаю, eye() - довольно отвратительная традиция с точки зрения английского языка).

bitstype -> primitive имеет смысл, если изменить type .

@tbreloff верен - основные разработчики в прошлом демонстрировали хороший вкус, и, в конце концов, люди последуют их примеру. Сделай это скорее!

Интересно, если immutable должен быть стандартом, если вам явно не нужно изменять, должно ли переименование:

• immutable -> struct
• type -> mutable

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

Мне тоже нравится bitstype -> primitive ...

Я не думаю, что const должно быть значением по умолчанию. Оптимизация, снижающая функциональность, не должна использоваться по умолчанию.

+1 за struct и const struct .

Термин composite немного более нагляден, но struct является коротким и очень широко известен как составной тип.

Я бы предпочел не красть реальное слово для чего-то столь редко используемого, как bitstype . Может быть, primtype или primitivetype ?

Если мы не собираемся менять bitstype на явно лучшее имя, например primitive то я думаю, что лучше оставить его как есть.

От -1 до struct . Я не использую этот термин для объяснения того, что такое определение типа, если я не разговариваю с программистом на C, а затем только для того, чтобы упомянуть, что макет совместим, и сравнить / сопоставить их свойства.

От -1 до const . C пошел в этом направлении, используя минимальное количество ключевых слов, и теперь мы застряли со многими ключевыми словами, которые имеют контекстно-зависимое значение. Я действительно не думаю, что const является ключевым свойством этих типов, а скорее, что они являются типами значений (в отличие от ссылочных типов).

Но если пойти в другом направлении, как насчет использования ключевого слова new ?

new abstract Abstract
new value Value <: Abstract
    Value() = new()
end
new primitive 8 BitsByte <: Abstract
new record Object <: Abstract
    Object() = new()
end
new function WhyNot # equivalent to `function WhyNot end`

Проблема с «типом значения» состоит в том, что его могут понять только люди, которые достаточно глубоко знают язык. Для новых пользователей тот факт, что поля неизменяемы, - это _semantic_ факт, с которым они сразу же сталкиваются; все остальное - деталь реализации. Поэтому я предпочитаю const .

Я вижу, куда вы идете с записью , но, честно говоря, я думаю, что эта терминология даже менее распространена, чем struct (даже если вы погуглите «рубиновый тип записи» против «рубинового типа структуры», или замените python или perl, или другой язык, отличный от C). Также существует проблема, заключающаяся в том, что record - довольно полезное английское слово, которое было бы стыдно зарезервировать в качестве ключевого слова, тогда как struct вряд ли понадобится для чего-либо еще в программе.

struct очень часто используется; просматривая rosettacode, его используют:

algol, C, C #, C ++, lisp, D, elixir, вперед, go, maxima, racket, rust, seed7, swift, visual basic ( structure )

record используется:

ada, clojure, delphi, pascal, erlang, icon, modula-2, некоторые схемы

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

Интересно, что seed7 использует new struct .

Немного грустно видеть, что struct (действительно ли лишние три буквы для завершения слова настолько плохи?) Превратились в язык, который до сих пор имел function вместо func , и так далее. Никто не собирается отказываться от языка, но все же ...

structure фактически используется в PL / I и Visual Basic. В VB также есть structure immutable . Однако struct настолько распространен, что я чувствую, что это почти само по себе новое слово.

Интересно, есть ли здесь проблема с родным языком. Я очень привык к слову struct в этом контексте structure , что кажется более странным. По той же причине func звучит ужасно, а function естественно.

Разве struct стал самостоятельным термином из-за его использования в различных языках программирования? Слово structure (по крайней мере, для меня как уроженца Германии) гораздо более абстрактно. Например, эта иерархия типов имеет определенную «структуру».

func для меня не самостоятельный термин, а просто аббревиатура.

func для меня не самодостаточный термин, а просто аббревиатура.

Как структура - это не просто аббревиатура? Разве это не буквально сокращение от структуры, или я просто неправильно понял этот термин? Ты просто больше к этому привык, чем func . Многие вещи являются «самодостаточными терминами» и являются общими для многих языков, но это не обязательно означает, что Джулия должна следовать традиции, если лучше не делать этого. Тогда это просто борьба за то, что лучше или хуже, и это в значительной степени вопрос вкуса.

В любом случае, я бы предпочел mutable , поэтому меня _слишком глубоко_ не волнует, является ли это структура или структура. mutable не будет постоянно писать const для того, что сейчас является immutable .

Но даже если это окажется struct или даже strct или stct или strctr очень маловероятно, что я бы поменял Джулию на любой другой язык для моя работа, так что ... :)

Извините, если это не имеет смысла на английском языке: но не struct является сокращением от construct . По крайней мере, на немецком языке слово Konstrukt имеет гораздо больше смысла для описания составного типа.

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

struct - это собственное слово, точно так же, как TV, ASAP и LOL - слова. Я редко слышу, как люди говорят «структура». По моему опыту, слово «структура» произносится и пишется.

Кстати: Matlab использует слово struct , если это имеет значение.

OTOH, как отмечалось выше, в C # и Swift struct соответствует типу значения (в отличие от class ). Таким образом, использование одинаковой терминологии как для изменяемых, так и для неизменяемых типов вряд ли поможет людям, знакомым с этими языками. Не уверен, что это решающий момент ....

mutable / immutable звучит как наиболее явный выбор, который должен быть очевиден для новичков.

Учитывая большое количество разных языков, которые используют struct , я не думаю, что для использования этого имени требуется идентичная семантика.

Мне больше всего нравятся type и const type , но это не освобождает ключевое слово type . Поскольку я не знаю, что запланировано на type , я не знаю, насколько велика эта стоимость.

Но поскольку часть type уже подразумевается в abstract , возможно, использование mutable и immutable само по себе имеет наибольший смысл. И меньше набирать, что immutable struct и небольшое изменение (type -> mutable).

структура слова (по крайней мере, для меня как уроженца Германии) гораздо более абстрактна.

Пока мы спорим о языке, все недооценивают количество сокращений, которые составляют struct . Это сокращение от «структура данных». Точно так же я бы сказал, что type - это сокращение от «тип данных». Осмелюсь сказать, что массив или буфер также являются структурой данных, как и связанный список и т. Д., Но struct имеет ранние корни как одна из первых общих структур данных, и в вычислительной среде он получил более конкретное значение (и, следовательно, для программистов, владеющих английским или другим языком, это не звучит так абстрактно, как structure ).

От -1 до struct . Я не использую этот термин для объяснения того, что такое определение типа, если я не разговариваю с программистом на C, а затем только для того, чтобы упомянуть, что макет совместим, и сравнить / сопоставить их свойства.

Я думаю именно так насчет struct . Я думаю, мы введем новый термин для Джулии без какой-либо конкретной причины.

От -1 до const . C пошел в этом направлении, используя минимальное количество ключевых слов, и теперь мы застряли со многими ключевыми словами, которые имеют контекстно-зависимое значение. Я действительно не думаю, что const является ключевым свойством этих типов, а скорее, что они являются типами значений (в отличие от ссылочных типов).

Джефф объяснил мне (очень любезно) выше, что семантически нам все равно, являются ли вещи значениями, ссылками или чем-то еще - это детали реализации, а не семантика, и в будущем золотом веке нам просто все равно. Вещи "передаются путем совместного использования" любым способом, которым хочет компилятор (с некоторыми гарантиями FFI, если это необходимо). В последние несколько дней я уже стал называть это «делением по волшебству», и я чувствую, что это было для меня откровением, которое снимает кучу психического давления, о котором (в идеале) мне просто не нужно думать ( @vtjnash, вы видели, как я боролся со значениями и ссылками, и как они реализованы компилятором,

Привязки могут меняться или быть постоянными (мы используем const но constant тоже довольно симпатичный). Точно так же привязки полей внутри составного типа данных могут либо изменяться, либо быть постоянными. Вот почему я ранее предлагал явно привязать const к каждому полю - это сделало семантику кристально ясной (по крайней мере, для меня).

ИМО, нам не нужно использовать причудливые слова, такие как «изменчивость» и «неизменяемый», чтобы говорить об этом. Что-то может отскочить к новому объекту, иначе оно будет постоянным. Устранение необходимости в сложных английских словах, таких как struct и immutable полностью из нашего дискурса о Джулии (а не только кода) должно рассматриваться как хорошее (даже цель).

Мне также кажется, что «структура» - это отдельное слово (то есть то, что оно означает в C), тогда как «структура», вероятно, является «структурой данных», потому что если бы вы имели в виду тип записи, вы бы сказали «структура». Но здесь я показываю свои корни C.

Это также обычная шепелявка; defstruct .

Вероятно, более тривиально, чем большинство других пунктов здесь, но пока мы ведем велосипедную распродажу: когда произносятся вслух, фразы immutable object и a mutable object звучат раздражающе похожими. Это сделало бы разговор о системе типов Джулии более трудным, чем нужно. РЕДАКТИРОВАТЬ: Похоже, это уже поднималось в этой теме .

+1 к type -> struct и immutable -> const struct . Не думаю, что когда-либо встречал кого-нибудь, кого это смутило бы, особенно после беглого объяснения.

Замена type реалистична для v0.6 и нереальна для v0.8. Мы должны это сделать. Это возможность сделать более плавным и улучшить врожденный талант Джулии к четкому общению и быстроте выражения. Типы очень хорошо работают, создавая работающее программное обеспечение. Лучшее наименование типичных вещей вызывает сильный резонанс и несет для Джулии более легендарное будущее.

Я предлагаю оставить неиспользованными struct . В C структура - это синтаксический контейнер для фиксированной последовательности полей фиксированного типа. Джулия - не Си, и включение C-изма в дискурс Юлиана вытеснит эпифемерный характер Джулии за пределы серьезного обсуждения наилучшего использования и лучших способов концептуализации аспектов Джулии.

Кроме того, «неизменяемый» и «изменчивый» слишком визуально согласованы. Мы можем лучше.

  immutable ComplexNumber ... end

  alterable MethodTable   ... end

@JeffreySarnoff Кроме того, согласно стандартам сообщества , Юлию предпочитают называть «она». Просто подумал, что упомяну об этом. 🙂

@ararslan Стандартное руководство сообщества по Джулии, похоже, изменилось, теперь оно избегает использования литературных местоимений. Спасибо, что обратили на это мое внимание. :крикет:

Использование местоимения женского рода само по себе неплохо (и неизбежно во многих языках), но кажется, что многие считают непреодолимым прыжок от использования термина «она» к разговору о Джулии как о горячем свидании, поэтому кажется лучше как можно больше избегать соблазна.

Спасибо

В четверг, 3 ноября 2016 г., в 16:29, Стефан Карпинский [email protected]
написал:

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

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258264451,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABmqxopTX8oWKbwnLxfCBtIv-Ih7l-nXks5q6kRFgaJpZM4KkN_g
.

Что касается рассматриваемой проблемы, я лично не уверен, что я считаю лучшим изменением. Но мне действительно кажется странным говорить об удивительной системе _type_ Джулии, а затем указывать, что ключевое слово, используемое для создания типа, на самом деле struct а не type . Я думаю, что это могло бы побудить людей вместо этого говорить о типах как о структурах, что в конечном итоге приведет к сдвигу в языке, используемом для описания Джулии, например, к обсуждению удивительной системы _struct_ Джулии.

ключевое слово, используемое для создания типа, на самом деле является структурой, а не типом

Но ключевое слово на самом деле не относится к построению типов - например, выражение Tuple{Int} также создает тип. Было бы замечательно, если бы вещи, которые в настоящее время определены с помощью type всегда назывались struct s, поскольку тогда не было бы путаницы относительно того, как Real является типом, а Union{Int8,Int16} - это тип и т. Д.

да, я редактирую свою предыдущую заметку и только что написал об этом. Это было бы
наносит серьезный ущерб "заботе и кормлению" Джулии и
будущее развитие выразительной силы и лаконичности. Если дверь будет
открыт, чтобы сделать законным рассмотрение системы типов Джулии как
строительные леса на C-структурах, война проиграна.

В чт, 3 ноября 2016 г., в 16:38, Алекс Арслан [email protected]
написал:

Что касается рассматриваемой проблемы, я лично не знаю, что мне
рассмотрел бы лучшую замену. Но мне кажется странным говорить о
Удивительная система _type_ Джулии, а затем укажите, что ключевое слово использовалось для
Построение типа на самом деле является структурой, а не типом. Я думаю это могло бы
побуждать людей говорить о типах как о структурах, что в конечном итоге приводит
к изменению языка, используемого для описания Джулии, например, к обсуждению ее
потрясающая _struct_ система.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258266857,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ABmqxsZ_rXkn6GpVFxhd6TZnkkao9plWks5q6kZggaJpZM4KkN_g
.

Было бы здорово, если бы вещи, определенные в настоящее время с помощью type всегда назывались struct s, поскольку тогда не было бы путаницы относительно того, как Real является типом, а Union{Int8,Int16} - это тип и т. Д.

Есть ли в настоящее время путаница по этому поводу? Думаю, это казалось мне очевидным, хотя, возможно, я пропустил обсуждение этого вопроса.

@ararslan : Термин type является очень общим для того, что создается в настоящее время. В настоящее время мы создаем с помощью ключевого слова type структуру, состоящую из составных типов. Но в Julia есть много других типов, которые не созданы с использованием ключевого слова type .

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

Хорошо, хорошее замечание.

а Union {Int8, Int16} - это тип

Ах. Я забыл, что Union тоже существует. Что делает аргумент в пользу struct ( Struct ?) Более убедительным, ИМО. Все еще не нравятся mutable и immutable .

Я нахожу _struct_ позорным и действительно верю, что привлечение к нему Джулии со временем потянет меняющийся дух времени вниз. Принцип - это антагонизм между представлением битов в движении и выражением вычислительных возможностей в виде слияний более высокого порядка и более глубоких гештальтов. То, что использование struct не заставит всех задуматься о типах структур, не имеет значения. ... позвольте мне драматизировать ...

Я не могу спорить с тем, что описание Эйнштейна как патентного служащего снижает оценку его вклада. Из этого не следует, что в курсе, где ссылки на Альберта Эйнштейна подчеркивают важность его времени в качестве патентного клерка, более чем несколько студентов выразят некоторое понимание этого в будущих разговорах. То, что вещь so , не гарантирует, что она будет вести себя только so после перехода в новую школу.

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

a structure - осмысленная взаимосвязь частей, осознанная композиция
construct - это полезное структурирование релевантностей, дизайн, повышающий ценность

неизменяемый structure - это перманентный состав
изменяемый structure - это нефиксированный предварительный выбор
неизменный construct - это установленная возможность
изменяемый construct - это намеренное ограничение контекста

Нам нужен как способ речи «биты в местах и ​​через ворота», так и «структурирование данных выявляет онтологическую информацию», и это можно сделать доступным как способ речи модификатора преобразования. Участники сообщества, обладающие талантами в области CS, и большинство других экспертов в предметной области, которые занимаются программированием, хорошо разбираются в байтах, памяти, логике, инструктируемых операциях и т. Д. Другим способом реализации желания, творчества, возможностей и воображения становится программное обеспечение, которое хорошо работает и стоит работы - тем меньше делится. Любое решение об именовании терминов должно поощрять этот разговор.

А как насчет class и immutable ?

Я знаю класс из Delphi и думал, что здесь это невозможно, но в языке Nice, в котором есть мультиметоды, он используется как ключевое слово ( ссылка ). И - если я правильно прочитал руководства - также на Haskell и Dylan. Он проходит тест «класс - это один из видов типа» и все еще довольно расплывчатый (как «тип» сегодня), что мне нравится. В видеоролике «Обзор массивов и итераций» в 15:00 - 15:20 мин Тим Холи (случайно) говорит «класс», что является неважной деталью, но, тем не менее, может показывать, что класс не был бы полностью чужим в контексте Джулии.

В противном случае reftype и immutable ? Термин reftype был упомянут в начальном комментарии и с тех пор игнорируется. Почему? На мой взгляд, это звучит неплохо, освобождает шрифт и передает значение ссылки.

(Я не понял цель ключевого слова 'new'. Нельзя ли исключить 'new' во всех строках без изменений? Термины 'value' и 'record' будут ключевыми словами и заменят используемые в настоящее время 'неизменяемые' и "тип", верно?)

@swissr единственное различие (о котором должно знать большинство пользователей) между этими двумя типами состоит в том, что поля в одном могут изменяться, а в другом - нет. Было бы логично, если бы их имена указывали на их единственное смысловое различие. (Как уже упоминалось, реализации, использующие значения и ссылки, являются гибкими - например, улучшенный компилятор может автоматически передавать большие isbits типы по ссылке в качестве оптимизации, и, наоборот, небольшие изменяемые объекты могут перемещаться в стек в определенных ситуациях).

Что касается type vs struct , я действительно вижу, что могу создавать абстрактные типы данных с abstract , Union{} , typealias и так далее ( в случае Tuple{} это спорно , если это новый тип или просто параметризованный тип), но на самом деле только _user определенный бетон types_ созданы bitstype , type и immutable . Синтаксис для них безошибочен относительно абстрактных определений, поскольку они каким-то образом определяют данные, которые они содержат, а абстрактные - нет. Изменение immutable на const type , казалось бы, проясняет мне ситуацию.

Я действительно беспокоюсь о языке и распространении технического слова struct по единственной причине - традиции, когда у нас есть возможность создать язык программирования, который обсуждается в условиях непрофессионала. Я думаю, что это не поможет, например, когда я создаю обертку типа Symmetric{Matrix{T}} - я не хочу, чтобы мои обсуждения были: "Я создал этот struct всего с одним полем. который ... "когда я могу сказать" Я создал Symmetric wrapper type для Matrix "(обратите внимание, что половина этого предложения является фактическим синтаксисом). «Структура-оболочка»? Звучит глупо - а кто делает структуру с одним полем? Если на то пошло, как насчет синглтонов без полей? Значительная часть types и immutables не определены для создания какой-либо (нетривиальной) структуры данных, а скорее предназначены для использования мощной системы типов и диспетчеризации с оболочками и синглетонами. ИМО, это самый интересный, мощный и выразительный аспект Юлии (в сочетании с тем, что он _быстрый_).

Я чувствую, что вся мощь struct сразу станет очевидной только для опытных метапрограммистов шаблонов C ++, которые знают, что могут реализовывать черты и т. Д. С помощью структур, и это немного стыдно.

«Добрый» имеет довольно специфический технический смысл в теории типов.

Если цель / преимущество - освободить type тогда как насчет:

const datatype  # immutable
datatype        # type

Это конкретные типы, поэтому они, вероятно, содержат данные, и это один (из многих) способов создания DataType .

«Добрый» имеет довольно специфический технический смысл в теории типов.

Введение в вики звучит точно так же, как Type{} (который принимает DataType и TypeConstructor , Union и т. Д.) (РЕДАКТИРОВАТЬ: я не думаю, что такое изменение стоит срыва)

kind здесь не то слово.

Я считаю, что чаще всего лучший подход - это просто выучить
стандартный словарь вместо того, чтобы пытаться заменить его чем-то, что вы
догадаться будет проще.

Это решение не влияет на неформальную речь. Вы все еще можете разумно сказать "Я
определил тип ". Использование более конкретного ключевого слова упрощает, когда
вам нужно быть точным.

Справедливо, Джефф. Обратите внимание, что я _do_ думаю, что const struct и struct будут улучшением по сравнению с immutable сравнению с type (но это не значит, что мы не должны искать что-то даже лучше).

Когда вы думаете, что структура - это восприятие больше как структура или как конструкция, ни то, ни другое?

@andyferris мой const struct и struct будут улучшением. Это была еще одна попытка найти возможные термины, когда вы хотели избежать 'const', сохранить 'неизменяемый' и не допускать 'struct' (знал об упомянутой реализации, но думал, что если это правильно, скажем, в 80% случаев, это нормально) .

Как насчет fieldtype (или fieldstype )? Он параллелен bitstype и соответствует fieldnames() .

Глен,
Мне нравится правдоподобие. fieldstype - лучший выбор, потому что правильное использование формы множественного числа, где что-то может быть в единственном или множественном числе.
--Джеффри

class может быть в порядке; изначально мы отвергли его из-за его связи с объектно-ориентированным объектом на основе классов с методами внутри объектов. Я бы сказал, что struct более точен.

Я не считаю struct сокращением чего-либо; это просто то, что эти типы структур данных называются на данный момент. Довольно забавно, что в lisp есть cons , которое изначально могло быть аббревиатурой для construct , но люди довольно быстро забыли об этом и просто начали говорить о «cons-ячейках».

Я думаю, что мы должны продолжать отклонять class . Использование этого термина вызвало бы целый ряд ожиданий ООП, которые противоречат стилю Джулии.

Я не считаю struct сокращением для чего-либо, но меня беспокоит, что неявная ссылка на структуры C подразумевает, что Julia будут типами значений, а это, конечно, не так. С этой целью я сейчас немного склоняюсь к record поскольку он имеет гораздо меньше непосредственных коннотаций.

Чтобы прояснить момент, который может быть неясным, я думаю, что использование const record или const struct только в том случае, если оно интерпретируется как сокращение для отображения const по всем полям , подразумевая, что мы хотели бы поддерживать пометку отдельных полей как const . Я хочу сказать, что у нас может быть следующее:

record T0
    f::A
    g::B
end

record T1
    const f::A
    g::B
end

record T2
    f::A
    const g::B
end

record T3
    const f::A
    const g::B
end

const record T4
   f::A
   g::B
end

Здесь T3 и T4 фактически описывают эквивалентные типы - т.е. запись const record - это просто сокращение для всех полей, являющихся const . Если это не интерпретация, то я думаю, что объединение неизменяемости с константностью в некотором роде опасно, поскольку это уже общий источник концептуальной путаницы, и если мы добавим к этой терминологической путанице, мы не собираемся помогать делу.

Здесь T3 и T4 фактически описывают эквивалентные типы - т.е. запись const - это просто сокращение для всех константных полей.

Если мы сделаем const record означающим то, что сейчас означает immutable , это может быть неверно. const record будет описывать ссылочный тип, для которого нельзя изменить ни одно из полей. В то время как текущий immutable - это тип значения.

См. Https://github.com/JuliaLang/julia/issues/19157#issuecomment -257942059 и следующий комментарий для обсуждения record .

@vtjnash Это хороший момент, но он похож на то, что происходит сейчас, когда immutable становится «ссылочным» типом, если он содержит какие-либо ссылки.

Я думаю, что тот факт, что record встречается реже, - это нормально, но тот факт, что это полезное слово как существительное, так и глагол, более проблематичен.

Как насчет nuple ? Это, конечно, сокращение от "named tuple".

Мне нравится предложение, сделанное выше

const datatype  # immutable
datatype        # type

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

Есть ли планы изменить терминологию для объяснения этого в документации, а точнее изменить названия глав, как эта ? Если нет, я думаю, мне больше всего нравятся composite и immutable composite или const composite . Поскольку const также используется для глобальных констант, я бы выбрал const или immutable для обоих из них, с небольшим предпочтением const потому что это короче. По крайней мере, слово «составной» не покажется знакомым большинству новичков, что заставит взглянуть на документацию и избежать ложных предположений из-за сходства с именем C. Ложные предположения относительно const кажутся менее вероятными, поскольку любой, кто привык к этому в C ++, знает, что ничего не следует предполагать.

Также преимущество использования двух слов для обозначения неизменяемости освобождает возможные будущие const abstract и const bitstype если в этом возникнет необходимость.

Если мы сделаем const record означающим то, что сейчас означает неизменяемый, это может быть неверно. Запись const будет описывать ссылочный тип, для которого нельзя изменить ни одно из полей. В то время как текущий неизменяемый - это тип значения.

Ой ой. Я думал, что значение или не-суть immutable было определено на уровне реализации, и все, что пользователь должен учитывать, - это то, что поля не могут быть повторно связаны. В этом случае передача по значению (или нет) является чистой проблемой ABI, при которой компилятор в принципе должен иметь право выбирать то, что более эффективно. Для меня видимая пользователем семантика неизменяемого кажется в точности эквивалентной применению текущей семантики const ко всем полям типа.

Я все еще смущен предполагаемой семантикой неизменяемого на уровне пользователя, или вы здесь говорите о деталях реализации?

Как насчет nuple? Это, конечно, сокращение от "named tuple".

Можно также использовать record , верно? Например, именованный кортеж - это то, что record в Erlang. И я думаю, что в мире баз данных тоже.

Но если у Джулии больше общего с людьми, которые также знают C , struct - более подходящее изменение.

Лично мне record кажется странным и непонятным. В мире баз данных запись - это строка в таблице; похоже, что это был бы сбивающий с толку конфликт с чем-то столь же общим, как тип Джулии (неизменный или иной).

Перечитав эту ветку, я склоняюсь к composite за type . Он придерживается «правила одного предложения» Джеффа, и за него не было так много отрицательных голосов. То, что этот термин не так часто используется в других языках, на мой взгляд, не проблема. И composite - действительно самое описательное слово, которое можно найти для этого. Вот почему в документации эти вещи называются composite types .

Исходя из Фортрана, я все еще считаю, что ключевое слово type в порядке,
и минимальное разумное изменение будет immutable -> const type .

Но если type действительно нужно уйти,
composite и const composite кажутся следующими лучшими вариантами.

immutable -> const type определенно кажется жизнеспособным: он одновременно позволяет избежать прерывания, удаляет ключевое слово и добавляет ясности в язык.

Было бы грустно не использовать type но, честно говоря, я все равно хочу использовать Type . В девяти случаях из десяти мои переменные типа являются параметрами для статической диспетчеризации, а не переменными DataType для анализа динамического типа (исключение, создаваемое функциями). Это не так для людей, которые пишут inference.jl, но они, если хотите, на самом деле не являются «целевой аудиторией» языка.

Связанный с этим вопрос: возможно ли вообще использовать type на верхнем уровне, но внутри функции (где это всегда недопустимо, в настоящее время) разрешить ему быть именем переменной? Или даже более того, структура определения типа довольно специфична ... можем ли мы определять определения типов как особый синтаксис, позволяя даже глобальные переменные (или функции) быть привязанными к type ?

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

(маловероятно, я думаю) здесь есть большой риск: идиосинкразической лексикографии становится слишком легко отвлекать. И эти недостающие микро-непрерывности разрушительны для облегчения сотрудничества и четкого общения.

@ c42f :

Я все еще смущен предполагаемой семантикой неизменяемого на уровне пользователя, или вы говорите здесь о деталях реализации?

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

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

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

_хотя_

поскольку реальная ситуация такова, что C

хорошо объясняет, почему из возможных терминов struct - мой наименее любимый

Вот история, которую я продаю: «И в C, и в julia struct - это структура данных, которая сопоставляет фиксированный набор имен полей со значениями различных типов. Но когда вы передаете их, C проходит по стоимости, а Джулия - мимоходом ".

Эта информация не обременительна и полностью точна. Все в нем можно успешно погуглить. Ни один теоретик PL не станет на это жаловаться, а не теоретики PL научатся чему-то, услышав это.

Я купился на эту историю. Хотя мне интересно, есть ли здесь упомянутые термины, на которые будет жаловаться теоретик PL? Мне нравится думать, что Джулия отлично вписывается в ту нишу, которая удовлетворяет как теоретиков PL, так и не теоретиков, поэтому достижение баланса между правильностью и общей ясностью здесь кажется решающим.

Ну, я не хочу никому в рот вкладывать слова; Я просто хотел обратиться к мысли о том, что struct может сбивать с толку из-за того, что структуры являются «типами значений».

Я думаю, что immutable должно оставаться ключевым словом из одного слова. Мне не нравятся const type const struct или immutable struct . Я часто использую immutable и я думаю, что было бы довольно неудобно, если бы эти объявления состояли из двух слов, когда почти все остальное - одно слово. Не в смысле набора текста, поскольку это не проблема; но в том смысле, что наличие неизменяемости вроде «тега» делает его второсортным.

@TotalVerb Я не думаю, что это очень совместимо с тем, что

type MyType
    const field::Int
end

должен вести себя точно так

immutable MyType
    field::Int
end

делает сейчас.

Учитывая это, наличие const type (или const struct , const composite или чего-то еще) транслирует const в каждое поле в качестве ярлыка, кажется полезным (хотя не обязательно) особенность. Я бы надеялся, что в будущем компилятор даже не будет знать, какое из них вы набрали ( const type или const перед каждым полем - первое может преобразоваться во второе с помощью синтаксического анализатора). В этот момент зачем хранить immutable ?

наличие неизменяемого типа «тега» заставляет его чувствовать себя второсортным.

Если я правильно понимаю Джеффа и Стефана, то да, immutable - это просто тег, который говорит, что поля типа являются постоянными привязками. Постоянство (_ действительно_ константа, а не C) помогает компилятору выполнять оптимизацию, а если сами поля являются константами или примитивами рекурсивно (например, isbits ), это помогает сделать еще больше оптимизаций. Это полезно знать, но не имеет смысла. Привязка семантики к текущему поведению может затруднить улучшение этого поведения в будущем.

Но есть важное семантическое различие: неизменяемые типы являются значениями, и поэтому можно смело предположить, что идентичность объекта определяется его полями. С точки зрения пользователя, объект неизменяемого типа не имеет специальной «идентифицирующей функции», недоступной из его полей. С другой стороны, любой объект изменяемого типа, не являющегося одноэлементным, явно имеет эту невидимую «идентичность». Тот факт, что многие неизменяемые типы хранятся как упакованные объекты и, следовательно, действительно имеют эту дополнительную идентичность внутри, не имеет отношения к семантике.

На мой взгляд, это не просто оптимизация.

immutable Complex{T} ... end

вместо

type Complex{T} ... end

потому что меняются многие аспекты видимого пользователем поведения: === , == по умолчанию, objectid , hash и т. д. Сказать, что неизменяемые типы предоставляют подмножество функциональности изменяемых типов; Напротив, сам факт их неизменности дает важные гарантии, которые позволяют неизменным типам быть более мощными.

Прежде чем сообщество остановится на const и struct , я просто хотел сделать еще один плагин для constant и structure .

1) Всего три дополнительных буквы для настоящих слов!
2) Несмотря на утверждения, что struct стало идиоматическим
2a) Кто-то, кто переходит с R (например, я), может быть сбит с толку
2b) Кто-то новичок в программировании (те, кто больше всего нуждается в помощи) может быть сбит с толку

Просто ради забавы, глупые слова, за которые можно спутать структуру:
несокрушимость
обструкционизм
постструктурализм
надстройка (о привет Маркс)

и const:
Константинополь
созвездие
удав
неконституционный

Есть ли в PL красота / сила, приобретаемые многоконтекстным неизменяемым и константным такого типа: неизменяемый, никогда не транслируемый (проецирующий свою природу) через / внутри своего разрешенного референта и константный трансляция через встроенные референты, которые не являются неизменяемыми, как если бы это было наречие или герундий?

Другими словами, тот же вопрос:

На данный момент использование переменных в глобальной области видимости проблематично, и обходной путь trick состоит в том, чтобы обернуть изменяющееся значение в константный вектор с одной записью. В этом случае const не транслируется. В широковещательной версии const будет применяться? Подразумевает постоянство как для значения записи в векторе, так и для вектора. Точно так же объявление типа, в котором есть поля, которые могут содержать значения, которые заключают в себя другие типы значений. Неизменяемый тип теперь не наделяет неизменяемостью значения своих полей (и не любое значение, которое может быть косвенно достигнуто через его поля). Есть элегантность и полезная способность, которая поставляется с широковещательной версией ключевого слова, которое означает, что «после создания / инициализации значение, приписываемое этому элементу [или элементам этого типа], не изменяется [не может быть изменено]» .

Немедленная (не широковещательная) сортировка широко используется, и если предположить, что некоторые из того, что люди делают с Джулией, становится намного проще для предварительной компиляции Джулии, чтобы сделать ее лучше / быстрее / проще в использовании или полагаться с введением широковещательной константности, тогда это должно сыграть хорошо с немедленной сортировкой. Интересно, может ли этот способ привнести дополнительную "доброту" теоретического языка программирования (простота выражения, репрезентативная мощь, ...): константность широковещательной передачи транслирует через значения типов, которые имеют встроенные ссылочные типы и / или имеют? Косвенно содержащиеся типы до тех пор, пока (a) достижение значения, которое не имеет внутренних вложений или контейнеров, или (b) достижение значения само (независимо или иначе) относится к типу, который не имеет широковещательной константности.

Если подумать об этом подробнее, то единственное изменение, которое, как мне кажется, стоит того, чтобы его сломать, - это bitstype -> primitive , в основном из-за того, насколько неприятно вызывать что-то isbits .

Что касается реальной сути этого обсуждения, type и immutable , на данный момент вариант, который мне больше всего нравится, - это вообще без изменений; type для создания типа ясно, immutable для создания неизменяемого типа ясно. Тем не менее, я с радостью приму все, что дают нам наши верховные повелители, поскольку я безоговорочно доверяю их мнению о том, что лучше всего для языка в будущем.

Есть ли причина не использовать фиксированный, а не const или constant? По крайней мере, мне кажется, что это более ясное описание.

@JeffreySarnoff Трудно const на то, на что вы можете получить ссылку (т.е. указатель). Семантика «совместного использования» Джулии означает, что все, что компилятор не может доказать, что оно действительно неизменяемое, должно быть ссылочным типом. Когда вы привязываете такую ​​ссылку к полю const type ( immutable ), нет доказательства того, что эта ссылка не существует в другом месте, и, следовательно, нет доказательства того, что данные, на которые ссылаются, являются постоянными.

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

@andyferris Спасибо за четкий ответ.

Есть ли причина не использовать fixed вместо const или constant ? По крайней мере, мне кажется, что это более ясное описание.

Мне было интересно, есть ли что-то лучше, чем const или constant которое отражает постоянство привязки, а не (обязательно) неизменность данных внутри связанного объекта. fixed действительно идет в этом направлении, но я не видел этого на других языках (опять же, я также не заметил семантику привязки / совместного использования Джулии на других языках).

Может быть, что-то вроде bind (например, bind x = 2 ) ... тезаурус предлагает glue ... это становится довольно умозрительным ...

Идея заменить const чем-то более точным заманчива. Однако мы бы хотели, чтобы это разумно применялось как к объявлению типа, так и к назначению отдельной переменной. fixed struct имеет смысл, но фиксируются поля структуры, а не объявление типа. К сожалению, bound struct ( tied struct ?) Кажется довольно неясным. По какой-то причине const мне кажется более понятным в применении к типу.

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

Я считаю, что было бы продуктивно

type A
    const x::Int  # fixed, bind, bound, tied, glue
end

имеет смысл. Наличие ярлыка перед type , struct или чем-то еще будет просто ярлыком, который означает указанное выше.

Возможно, имеет смысл сделать это макросом, как и другие важные украшения, изменяющие характер объекта, например @generated . Это удалило бы еще одно ключевое слово ...

+1 за type -> composite , хотя на самом деле любое изменение от type звучит отлично.

Хотел бы я голосовать по проблемам GitHub, не добавляя новый комментарий в ветку ... Я голосую за mutable и immutable , это довольно аккуратно и чисто. struct чрезмерно используется и не подчеркивает изменчивость.

PS: Кто-нибудь знает или может внести свой вклад в GitHub и добавить функцию голосования? Я спросил их на странице «Связаться с нами», но мой адрес электронной почты, вероятно, был утерян.

Недавно переключившись на Джулию с опытом работы на многих других языках, я бы предпочел, чтобы Джулия не использовала именование в стиле C и вовлекала все запутанные проблемы константности C / C ++. Вместо этого предоставление объявлению типа данных понятия, которое каким-то образом отражает намерение быть типом значения или общим ссылочным типом, значительно помогло бы мне, вместо того, чтобы просто ссылаться на изменчивость.

Моим первоначальным ожиданием от Джулии было бы простое поведение type аналогичное неизменному объекту struct стиле C или Python, поскольку Джулия, похоже, в значительной степени ориентирована на стиль и скорость функционального программирования.
Меня до сих пор смущает асимметрия формулировок type ... и immutable... , но я получаю DataType из typeof(SomeType) или фактическое значение 'bitstype 'и необходимость ключевого слова typealias вместо простого оператора Alias = DataType .

Таким образом, я бы проголосовал за datatype , что соответствовало бы typeof(SomeType) == DataType и нарушило бы раздражающее сходство ::Type{} . Украшение изменяемого типа с помощью composite [datatype] может подчеркнуть его особый и, возможно, более дорогой характер по сравнению с фундаментальными «битовыми типами».

втягивая все запутанные проблемы константности C / C ++

Никакое переименование этого ключевого слова не сделает этого. Эти проблемы связаны со статической проверкой и приведением типов, которые здесь вообще не задействованы.

Намерение быть типом значения или общим ссылочным типом значительно помогло бы мне, вместо того, чтобы просто ссылаться на изменчивость

Я этого не совсем понимаю. Если объект неизменен, невозможно определить, передан ли он по значению или по ссылке, так как же различие между значением и ссылкой может быть фундаментальным?

datatype - неплохой выбор. Но я не думаю, что datatype vs. composite datatype - хороший способ передать различие изменчивости.

@JeffBezanson , с C-подобной const struct .

Относительно «значения или ссылки»: мне потребовалось довольно много времени, чтобы понять, почему неизменяемый тип встраивает члены напрямую и создает красивый и компактный быстрый ассемблерный код, а «тип» - нет и по-прежнему содержит все вызовы объектов. Или, другими словами, почему я обычно хочу использовать NTuple, когда стремлюсь к скорости. Таким образом, при чтении «неизменяемый» и «изменчивый» я ожидал бы значения как «параметра» в Фортране, но не также изменения макета или типа реализации фактического типа данных.
Вероятно, большую часть времени может потребоваться семантика «неизменяемого значения» для небольших составных типов, таких как Complex, но «изменяемая и ссылающаяся / не копирующая» для больших наборов данных, таких как массивы и т. Д.
Тогда основная цель, вероятно, не в изменчивости, а в том, чтобы избежать копирования данных.

Тем не менее, это был мой опыт, когда я изучал низкоуровневую технику Julia для получения быстрого кода ассемблера, но я не знаю, как лучше отразить это при именовании ключевых слов и как объединить или выразить это только с изменчивостью.

Я понял, откуда вы пришли, @mjw, я был там, но я думаю, вам лучше отказаться от всего, что вы знаете о C / C ++. Здесь неизменяемо const -ness, и независимо от того, находится ли что-то в стеке или динамически, и передается ли оно по ссылке или по значению, они могут изменяться и будут вариантами оптимизации для компилятора. Вы можете создать язык, в котором все динамически распределяется и передается по ссылке, и это способ Джулии по умолчанию (для значений в штучной упаковке - он реализует «передачу путем совместного использования», даже если тип неизвестен). Вы (и все мы) замечаете, что небольшие неизменяемые объекты выполняются намного быстрее, потому что именно там в настоящее время реализованы оптимизации. Это результат семантики immutable упрощающей оптимизацию.

Но, на самом деле, я бы предпочел, чтобы большие неизменяемые объекты передавались по ссылке (возможно, указателями стека, где это имеет смысл, но, вероятно, лучше всего выделить кучей NTuple{1_000_000} ), и что небольшие изменяемые объекты известного размера выделяются в стеке (опять же, где это возможно). В некоторых случаях даже сборка мусора может быть определена статически, что позволяет, например, повторно использовать пространство кучи внутри циклов. Я представляю это как будущие возможности оптимизации, требующие анализа выхода (и ни один из них не влияет на семантику языка, а только на производительность).

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

Я имел в виду возможное подразумеваемое ожидание того, что тип Julia будет вести себя так же, как в C / C ++.

Само по себе это может быть достаточно хорошей причиной, чтобы рассмотреть const -> constant , если честно. Я думаю, что const может быть нашим единственным сокращенным ключевым словом на данный момент, что в любом случае делает его необычным.

простой оператор Alias = DataType .

Я почти уверен, что это абсолютно нормально там, где это имеет смысл, но это не позволит более сложные модификации типа, например, typealias RealMatrix{T<:Real} Matrix{T} , и не должно (это простая привязка, а не создание нового Type с новыми TypeVar s). Если вы не хотите определить это наоборот: RealMatrix = Matrix{T <: Real} и обобщить, что apply делает для TypeVar (т.е. делает TypeConstructor ) ... на самом деле это интересная идея (но у нее есть проблемы с синтаксисом, поэтому typealias - это хорошо ...).

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

@mjw Отлично, и я со всем этим согласен. :)

Вот что я вам скажу, давайте попробуем как можно более близкое к опросу, используя лучшую функциональность GitHub: эмодзи реакции.

Здесь я привел _ в произвольном порядке_ те предложения, которые, по-видимому, пользуются наибольшей поддержкой. Реагируйте, используя указанный смайлик, чтобы проголосовать за это предложение. Я считаю, что для этого требуется доступ к GitHub через настольный браузер; Смайлы реакции AFAIK не были реализованы в мобильном интерфейсе. Нажмите на лицо в правом верхнем углу этого сообщения, чтобы открыть меню смайликов.

| type | immutable | реагировать с |
| : -: | : -: | : -: |
| struct | const struct | 👍 (+1) |
| mutable | immutable | 👎 (-1) |
| type | immutable | 😄 (смеется) |
| composite | const composite | : tada: (Ура) |
| datatype | const datatype | 😕 (в замешательстве) |
| type | const type | ❤️ (Сердце) |

Неспособность проголосовать, конечно же, соответствует неявному голосованию за nuple . :Тролль:

Должен сказать, я не большой поклонник принятия подобных спорных решений «демократическим путем». Если обсуждение не привело к консенсусу, я бы просто согласился с решением BDFL.

Справедливый вопрос, @TotalVerb. Как я сказал ранее, я был бы в полном порядке, если бы власть имущие давали нам то, что они считают лучшим. Мне кажется, что ветка немного извилистая, и точка зрения @juliohm по поводу голосования кажется разумной, поэтому я решил попробовать и посмотреть, что произойдет. Я рассматриваю это как способ более четко показать, в чем заключается консенсус, но я определенно считаю, что окончательное решение должно быть оставлено на усмотрение наших властителей, независимо от того, каков консенсус сообщества на самом деле.

Лично я не думаю, что мне нравится использовать два эстетических слова ( const type ). Это также немного семантически диссонирует. Когда мы говорим const x = 1 . Мы имеем в виду, что x постоянно. Когда мы говорим const type; x; end мы имеем в виду, что экземпляры этого типа не меняются после построения. От прямой интерполяции кажется, что что-то является постоянным типом, что означает, что сам тип не меняется (что уже имеет место сейчас). Смотрите также:

type foo
end
const bar = foo

Итак, bar - это const и всегда foo, но все же это не const type . Похоже, что по отношению к существующей семантике const (применительно к привязкам) имена типов уже являются константными.

Я подозреваю, что не существует кратких ключевых слов, передающих предполагаемую семантику и вряд ли желательных в качестве имен переменных. Я считаю, что терминология, наиболее близкая к этим целям, - это mutable datatype , immutable datatype и abstract datatype для трех типов объявленных типов.

Я хочу, чтобы помимо type и immutable был дополнительный изменяемый тип значения.
Я видел несколько дискуссий где-то по вопросам, но в основном на данный момент невозможно эффективно обрабатывать такие сценарии (поправьте меня, если я что-то пропустил):

immutable T
    a::Int
    b::Float64
    ...
end

t = Vector{T}(10)
t[2].a = 5    # error here
# instead
c = t[2]
t[2] = T(5, c.b, ...)   # works  

Код создает аккуратный массив типов значений sizeof(T) * 10 , но для изменения какого-либо поля необходимо переназначить весь T(...) , который обычно состоит из 3-5 полей.
Итак, в основном мои 5 центов:
type - ссылка, собранная сборщиком мусора
immutable - тип значения (выделенного стека), изменить который невозможно
mutable - тип значения, который можно изменять, особенно в массивах

тип значения, который можно изменить

Я думаю, что это недостижимая цель, поскольку именно разрешение изменений дает объекту идентичность.

Возможно, вам нужен этот подход: # 11902

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

abstract Node{T}
immutable Link{T} <: Node{T}
    value :: T
    next :: ref{Link{T}} # next :: Link{T} will be an error: Recursive type
end

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

@Keno делает хорошее замечание

Лично я не думаю, что мне нравится эстетически использовать два слова (тип const). Это также немного семантически диссонирует. Когда мы говорим const x = 1. Мы имеем в виду, что x постоянен. Когда мы говорим константный тип; Икс; end мы бы имели в виду, что экземпляры этого типа не меняются после построения. От прямой интерполяции кажется, что что-то является постоянным типом, что означает, что сам тип не изменяется (что уже имеет место сейчас)

Как я упоминал ранее, я думаю, что "правильная" семантика задается

type Complex{T}
    const re::T
    const im::T
end
z = Complex(1,2)

Здесь z.re ведет себя так же, как когда мы вводим что-то похожее на const z.re = 1 , поэтому нет семантической путаницы в том, какая именно привязка const .

Как заявляет @JeffBezanson , это не совсем удобно для большого количества полей и несовместимо с текущей реализацией типов. Частично изменяемые, частично постоянные структуры могут быть реализованы или не реализованы в будущем. Тем не менее, есть синтаксис , который имеет смысл , как в настоящее время и в будущем:

<strong i="19">@const</strong> type Complex{T}
   re::T
   im::T
end

В текущем способе реализации макрос может изменить значение с type на immutable в AST. В будущем, если будут реализованы частично-постоянные структуры, макрос все еще сможет выполнять манипуляции с AST, добавляя const к каждому полю, и всем будет ясно, что это привязки полей которые постоянны. С эстетической точки зрения это лучше, чем два ключевых слова подряд - мы делаем аналогичные вещи для функций ( @generated , @inline , @proagate_inbounds и т. Д.).

@const легко может быть @immutable или что-то подобное ( <strong i="31">@immutable</strong> type Val{T}; end читается ОК, ИМО), и идея макроса совместима с struct , composite , и так далее.

@ be5invis да, это обычный способ для многих языков, например, в C # есть struct , который ведет себя во многих отношениях как immutable : он передается копией в функции, явно выделяется в массивы (не ссылки на объекты, управляемые сборщиком мусора, как в случае class | type ). Однако он _mutable_, и в массивах может быть изменен одним полем.
Я действительно считаю, что в случае immutable есть сочетание двух свойств:

1. Неизменяемость (для правильного функционального программирования)
2. Вести себя как ценностный тип на нижнем уровне

В общем, мне бы хотелось увидеть введение типа только со свойством 2. Это не нарушит существующую кодовую базу (осталось immutable ), но для тех, кто пишет что-то быстро с минимальным участием GC, это было бы полезно .

@johnmyleswhite спасибо за # 11902, все еще считаю, что это не должно быть так уродливо

@wgreenr Как упоминалось ранее и много раз обсуждалось, это невозможно. Это тоже не имеет отношения к обсуждению в этом выпуске.

Возможно все, но введение изменяемых типов значений было бы дико разрушительным и очень плохой идеей. Я могу понять, почему это на первый взгляд простая и привлекательная идея, но добавление нового, совершенно другого типа семантики объекта и раздвоение графа типов на семантику ссылок и значений не улучшат язык. Это сделает невозможным безопасное написание универсального кода, поскольку один и тот же код будет делать очень разные вещи в зависимости от неизвестной семантики. Там же широкое обсуждение с примерами здесь . Смысл # 11902 - восстановить преимущества изменяемых типов значений без ущерба для вещей.

Я не уверен, стоит ли это вообще упоминать; но в C / C ++ «структура» также подразумевает кое-что о структуре данных. С другой стороны, часто имеет смысл переупорядочить элементы структуры, чтобы улучшить структуру памяти. Если вы подумываете о критическом изменении синтаксиса, возможно, стоит иметь механизм, чтобы как-то различать «структуры» (упорядоченное -> взаимодействие с C) и «неизменяемые» (потенциально могут быть упорядочены любым способом).

Я новичок в Джулии, поэтому извиняюсь, если пропустил что-то очевидное.

Лично у меня нет реальных предпочтений в отношении имен; однако меня удивляет, что никто, похоже, не предложил «конкретное», учитывая, что «абстрактное» уже существует.

Чтобы добавить еще одно предложение, мне лучше всего кажется следующее:

• Используйте struct вместо immutable .

• Используйте struct! вместо type . Говоря по-английски, это следует называть «изменяемой структурой».

  • (Возможно) разрешить помечать некоторые поля внутри struct! как const .

Некоторые оправдания и мысли:

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

2) Я думаю, что неизменяемые типы обычно должны быть предпочтительнее изменчивых, поскольку они подвергаются большему количеству оптимизаций и имеют более предсказуемое поведение для программиста.

3) Для того, чтобы это работало, вероятно, предварительным условием является реализация оптимизаций, чтобы сделать неизменяемые типы не менее эффективными, чем изменяемые типы, почти во всех случаях. В частности, компилятор должен уметь передавать большие неизменяемые типы по ссылке.

ОБНОВЛЕНИЕ : раньше у меня было record вместо struct , но record! слишком похоже на глагол. Некоторые другие варианты, которые приходят на ум: newtype , typedef (что запутает программистов C на 10 секунд), composite или concrete как предложил кто-то выше. .

Вероятно, что-то произойдет в этом пространстве до того, как функция v0.6 заморозит?

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

Я не следил за этим внимательно, но один комментарий заключается в том, что если / когда это изменится, я хотел бы попросить, чтобы у нас сначала был действительно хороший отчет о проблемном файле / номере строки. Или хотя бы модуль; в версии 0.5 все еще иногда сложно даже понять, какой пакет имеет @deprecate d _binding .

xref https://github.com/JuliaLang/julia/pull/20418#issuecomment -277475415