Какие преимущества есть в разделении списков и кортежей на разные типы ?
Почему эти типы не сделать взаимоменяемыми:
// int * int * int ==> список из 3-х int ==> list[int]
// Положим что и для списков используются круглые скобки
def f(x : int, y : int, j : int) { ... }
def a = (1, 2, 3); // typeof(a) -> int * int * int или list[int]
f(a);
def b = 1 :: (2, 3);
f(b);
Таким образом у нас есть один тип список и нет лишних преобразований.
Здравствуйте, _nn_, Вы писали:
__>Какие преимущества есть в разделении списков и кортежей на разные типы ?
не знаю как в немерле, но в других языках кортежи могут включать элементы разных типов, а списки — только одного. при стат. типизации это две большие разницы. а вот в языках с динамической типизацией вроде перла это действительно одно и то же
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, _nn_, Вы писали:
__>>Какие преимущества есть в разделении списков и кортежей на разные типы ?
BZ>не знаю как в немерле, но в других языках кортежи могут включать элементы разных типов, а списки — только одного. при стат. типизации это две большие разницы. а вот в языках с динамической типизацией вроде перла это действительно одно и то же
Это я знаю.
Вопрос почему нельзя объединить это в один тип ?
Здравствуйте, _nn_, Вы писали:
BZ>>при стат. типизации это две большие разницы. а вот в языках с динамической типизацией вроде перла это действительно одно и то же
__>Это я знаю. __>Вопрос почему нельзя объединить это в один тип ?
Объединить-то можно, но вот только тогда Nemerle перестал бы быть языком со статической типизацией... А зачем это нужно?
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, _nn_, Вы писали:
BZ>>>при стат. типизации это две большие разницы. а вот в языках с динамической типизацией вроде перла это действительно одно и то же
__>>Это я знаю. __>>Вопрос почему нельзя объединить это в один тип ?
N>Объединить-то можно, но вот только тогда Nemerle перестал бы быть языком со статической типизацией... А зачем это нужно?
А вот в рамках статической типизации нельзя разве ?
Здравствуйте, _nn_, Вы писали:
__>Зачем, простой пример: __>
<skipped>
__>А так можно: __>
<skipped>
Честно говоря, не очень "въехал" в пример... Можно подробнее?
Какой-нибудь пример кода (который можно было бы скомпилировать), с пояснениями, что в нем бы улучшилось, если бы кортежи и списки объединились бы в один тип.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, _nn_, Вы писали:
__>>Зачем, простой пример: __>>
<skipped>
__>>А так можно: __>>
<skipped>
N>Честно говоря, не очень "въехал" в пример... Можно подробнее?
Имееься ввижу чтобы не писать матч отдельно для списка и отдельно для кортежей.
N>Какой-нибудь пример кода (который можно было бы скомпилировать), с пояснениями, что в нем бы улучшилось, если бы кортежи и списки объединились бы в один тип.
def a = [1,2];
def f(x : int, y : int) { x + y }
Console.WriteLine($"f(a)");
Здравствуйте, _nn_, Вы писали:
N>>Какой-нибудь пример кода (который можно было бы скомпилировать), с пояснениями, что в нем бы улучшилось, если бы кортежи и списки объединились бы в один тип.
__>
__>def a = [1,2];
__>def f(x : int, y : int) { x + y }
__>Console.WriteLine($"f(a)");
__>
Ну и чем же это лучше, чем нынешний вариант
def a = (1,2);
def f(x : int, y : int) { x + y }
Console.WriteLine($"f(a)");
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, _nn_, Вы писали:
N>>>Какой-нибудь пример кода (который можно было бы скомпилировать), с пояснениями, что в нем бы улучшилось, если бы кортежи и списки объединились бы в один тип.
__>>
__>>def a = [1,2];
__>>def f(x : int, y : int) { x + y }
__>>Console.WriteLine($"f(a)");
__>>
N>Ну и чем же это лучше, чем нынешний вариант
N>
N>def a = (1,2);
N>def f(x : int, y : int) { x + y }
N>Console.WriteLine($"f(a)");
N>
N>?
А так:
def q(w : list[int])
{
f((w[0], w[1]))
}
// или так лучше :)
def q(w : list[int])
{
f(w)
}
Здравствуйте, _nn_, Вы писали:
__>Какие преимущества есть в разделении списков и кортежей на разные типы ? __>Почему эти типы не сделать взаимоменяемыми:
Они разные принципиально. При задании типа кортежа надо указать типы всех его составляющих элементов, при этом эти типы могут быть никак не связаны друг с другом, но их колическто должно быть известно на этапе компиляции.
При задании типа списка надо указать только один общий базовый тип всех его элементов. При этом количество элементов не указывается. Объекты-списки с различным числом элемнтов будут иметь один и тот же тип.
Другое дело, что для кортежей можно было бы определить операции конкатенации, присоединения элемента, а также позволить кортежи из одного элемента и реализовать интерфейс System.Collections.IEnumerable. Это сделало бы синтаксис работы с кортежами более похожим на работу со списками. Я это уже предлагал. Но, как правильно заметили на форуме, эти возможности были бы очень редко востребованы на практике, а иногда бы подталкивали программистов к кривым решениям.
Здравствуйте, _nn_, Вы писали:
__>Какие преимущества есть в разделении списков и кортежей на разные типы ?
Как уже сказали в кортеже могут быть поля разных типов, это легковесная структура, а в списке нет.
Кроме того число элементов в кортеже фиксируется на этапе компиляции, а список содержит произвольное число элементов.
Это просто разные структуры данных. В чем проблема?
__>Почему эти типы не сделать взаимоменяемыми:
__>
__>// int * int * int ==> список из 3-х int ==> list[int]
__>// Положим что и для списков используются круглые скобки
__>def f(x : int, y : int, j : int) { ... }
__>def a = (1, 2, 3); // typeof(a) -> int * int * int или list[int]
__>f(a);
__>def b = 1 :: (2, 3);
__>f(b);
__>
__>Таким образом у нас есть один тип список и нет лишних преобразований.
У меня никогда не возникало желания их преобразовывать друг в друга. Зачем?
__>def x = [1, 2];
__>q(x); // OK
__>def y = [1, 2, 3];
__>q(y); // Error
__>def z = get_list_from_x();
__>q(z); // Error
__>def q(w : int[2])
__>{
__> f(w)
__>}
__>
Что такое get_list_from_x() ? Некая функция, возвращающая список?
То есть ты предлагаешь, чтобы список, задаваемый литералом, можно было бы использовать вместо кортежа с соответствующим чилом элементов?
А список, имеющий неверное чило элементов, а также список, имеющий неизвестное на этапе компиляции число элементов (например, возвращаемый из функции), вызывали бы в этом контексте ошибку компиляции.
Я верно понял?
Не понимаю, какой от этого мы получаем выигрыш... С таким же успехом можно было бы записать литерал для кортежа. ИМХО, только путаница.
Или же ты предлагаешь, чтобы в случае, когда функции передается список, его элементы с помощью отражения преврщались в аргументы этой функции и она динамически вызывалась? Это бы имело смысл, если бы для этого использовался синтаксис, ясно показывающий, что программист хочет использовать позднее связывание. Впрочем, это не требует изменения языка. Для этого легко написать макрос. Даже, кажется, что-то подобное уже есть...
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, _nn_, Вы писали:
__>>А так ? __>>
__>>def x = [1, 2];
__>>q(x); // OK
__>>def y = [1, 2, 3];
__>>q(y); // Error
__>>def z = get_list_from_x();
__>>q(z); // Error
__>>def q(w : int[2])
__>>{
__>> f(w)
__>>}
__>>
N>Что такое get_list_from_x() ? Некая функция, возвращающая список?
Да. N>То есть ты предлагаешь, чтобы список, задаваемый литералом, можно было бы использовать вместо кортежа с соответствующим чилом элементов?
Да. N>А список, имеющий неверное чило элементов, а также список, имеющий неизвестное на этапе компиляции число элементов (например, возвращаемый из функции), вызывали бы в этом контексте ошибку компиляции. N>Я верно понял?
Да.
N>Не понимаю, какой от этого мы получаем выигрыш... С таким же успехом можно было бы записать литерал для кортежа. ИМХО, только путаница.
Разница в том, что используется один синтаксис на все.
N>Или же ты предлагаешь, чтобы в случае, когда функции передается список, его элементы с помощью отражения преврщались в аргументы этой функции и она динамически вызывалась? Это бы имело смысл, если бы для этого использовался синтаксис, ясно показывающий, что программист хочет использовать позднее связывание. Впрочем, это не требует изменения языка. Для этого легко написать макрос. Даже, кажется, что-то подобное уже есть...
Это тоже, т.к. список и кортеж будут одинаковы по сути.
В принципе достаточно для решения проблемы некое преобразование списка к кортежу через спец. функцию или неявно.
А вот наоборот если надо то как ?
Здравствуйте, _nn_, Вы писали:
N>>Или же ты предлагаешь, чтобы в случае, когда функции передается список, его элементы с помощью отражения преврщались в аргументы этой функции и она динамически вызывалась? Это бы имело смысл, если бы для этого использовался синтаксис, ясно показывающий, что программист хочет использовать позднее связывание. Впрочем, это не требует изменения языка. Для этого легко написать макрос. Даже, кажется, что-то подобное уже есть... __>Это тоже, т.к. список и кортеж будут одинаковы по сути.
По сути они вряд ли будут одинаковы, так как они используют совершенно разное внутреннее представление.
Подумай хотя бы о том, что для доступа к элементу списка, в котором N элементов, требуется время O(N), для доступа к элементу кортежа того же размера — O(1). Элементы кортежа лежат в памяти рядом с известными смещениями, а элементы списка разборосаны по памяти и связаны указателями.
N>>Не понимаю, какой от этого мы получаем выигрыш... С таким же успехом можно было бы записать литерал для кортежа. ИМХО, только путаница. __>Разница в том, что используется один синтаксис на все.
Разница-то есть, только она не является выигрышем. Тут круглые скобки (2 символа), тут квадратные (2 символа) — выигрыша нет.
А то, что для разных по внутреннему устройству объектов используется одинаковый синтаксис — это может только путать...
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, _nn_, Вы писали:
N>>>Или же ты предлагаешь, чтобы в случае, когда функции передается список, его элементы с помощью отражения преврщались в аргументы этой функции и она динамически вызывалась? Это бы имело смысл, если бы для этого использовался синтаксис, ясно показывающий, что программист хочет использовать позднее связывание. Впрочем, это не требует изменения языка. Для этого легко написать макрос. Даже, кажется, что-то подобное уже есть... __>>Это тоже, т.к. список и кортеж будут одинаковы по сути.
N>По сути они вряд ли будут одинаковы, так как они используют совершенно разное внутреннее представление. N>Подумай хотя бы о том, что для доступа к элементу списка, в котором N элементов, требуется время O(N), для доступа к элементу кортежа того же размера — O(1). Элементы кортежа лежат в памяти рядом с известными смещениями, а элементы списка разборосаны по памяти и связаны указателями.
N>>>Не понимаю, какой от этого мы получаем выигрыш... С таким же успехом можно было бы записать литерал для кортежа. ИМХО, только путаница. __>>Разница в том, что используется один синтаксис на все.
N>Разница-то есть, только она не является выигрышем. Тут круглые скобки (2 символа), тут квадратные (2 символа) — выигрыша нет.
N>А то, что для разных по внутреннему устройству объектов используется одинаковый синтаксис — это может только путать...
N>Или я что-то недопонял?
По большей части нужно неявное или явное простой способ преобразования списка в кортеж.
И еще хотелось бы чтобы компилятор мог определять размер списка во времени компиляции и передавать как кортеж если можно
Здравствуйте, _nn_, Вы писали:
__>По большей части нужно неявное или явное простой способ преобразования списка в кортеж.
Если в каком-то конкретном случае это хочется, то можно сделать довольно легко.
__>И еще хотелось бы чтобы компилятор мог определять размер списка во времени компиляции и передавать как кортеж если можно
Зачем?
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, _nn_, Вы писали:
__>>По большей части нужно неявное или явное простой способ преобразования списка в кортеж. N>Если в каком-то конкретном случае это хочется, то можно сделать довольно легко.
Как ?
__>>И еще хотелось бы чтобы компилятор мог определять размер списка во времени компиляции и передавать как кортеж если можно N>Зачем?
Если есть список , а нужно передать его в функцию как кортеж
В принципе все сводится с преобразованием в одну и/или в другую сторону.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, _nn_, Вы писали:
__>>Какие преимущества есть в разделении списков и кортежей на разные типы ? __>>Почему эти типы не сделать взаимоменяемыми:
N>Они разные принципиально. При задании типа кортежа надо указать типы всех его составляющих элементов, при этом эти типы могут быть никак не связаны друг с другом, но их колическто должно быть известно на этапе компиляции. N>При задании типа списка надо указать только один общий базовый тип всех его элементов. При этом количество элементов не указывается. Объекты-списки с различным числом элемнтов будут иметь один и тот же тип.
+1
N>Другое дело, что для кортежей можно было бы определить операции конкатенации, присоединения элемента, а также позволить кортежи из одного элемента и реализовать интерфейс System.Collections.IEnumerable. Это сделало бы синтаксис работы с кортежами более похожим на работу со списками. Я это уже предлагал. Но, как правильно заметили на форуме, эти возможности были бы очень редко востребованы на практике, а иногда бы подталкивали программистов к кривым решениям.
+1
Насчет кривых решений, то их можно многими способами заполучить
