tuple - list - Nemerle

Какие преимущества есть в разделении списков и кортежей на разные типы ?
Почему эти типы не сделать взаимоменяемыми:

// 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 перестал бы быть языком со статической типизацией... А зачем это нужно?

А вот в рамках статической типизации нельзя разве ?

Зачем, простой пример:

def f(a)
{
  | x :: y => 1
  | (x, y) => 1
  | _ => 0
}

А так можно:

def f(a)
{
  | (x, y) => 1
  | _ => 0
}

Здравствуйте, _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_, Вы писали:

__>А так:
__>

__>def q(w : list[int])
__>{
__> f((w[0], w[1]))
__>}

__>// или так лучше :)
__>def q(w : list[int])
__>{
__>  f(w)
__>}
__>

А если я скормил этому методу список, менее чем из 2-х элементов, ошибка выплывет только в рантайме. Вот оно, отсутствие статической типизации!

Здравствуйте, _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);
__>

__>Таким образом у нас есть один тип список и нет лишних преобразований.

У меня никогда не возникало желания их преобразовывать друг в друга. Зачем?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, _nn_, Вы писали:

__>>А так:
__>>

__>>def q(w : list[int])
__>>{
__>> f((w[0], w[1]))
__>>}

__>>// или так лучше :)
__>>def q(w : list[int])
__>>{
__>>  f(w)
__>>}
__>>

N>А если я скормил этому методу список, менее чем из 2-х элементов, ошибка выплывет только в рантайме. Вот оно, отсутствие статической типизации!

А так ?

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)
}

Здравствуйте, _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)
__>}
__>

Что такое 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_, Вы писали:

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

__>И еще хотелось бы чтобы компилятор мог определять размер списка во времени компиляции и передавать как кортеж если можно

Зачем?

__>>И еще хотелось бы чтобы компилятор мог определять размер списка во времени компиляции и передавать как кортеж если можно

N>Зачем?

Если есть список , а нужно передать его в функцию как кортеж

В принципе все сводится с преобразованием в одну и/или в другую сторону.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, _nn_, Вы писали:

__>>Какие преимущества есть в разделении списков и кортежей на разные типы ?
__>>Почему эти типы не сделать взаимоменяемыми:

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

+1

N>Другое дело, что для кортежей можно было бы определить операции конкатенации, присоединения элемента, а также позволить кортежи из одного элемента и реализовать интерфейс System.Collections.IEnumerable. Это сделало бы синтаксис работы с кортежами более похожим на работу со списками. Я это уже предлагал. Но, как правильно заметили на форуме, эти возможности были бы очень редко востребованы на практике, а иногда бы подталкивали программистов к кривым решениям.

+1

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

Здравствуйте, _nn_, Вы писали:

__>>>По большей части нужно неявное или явное простой способ преобразования списка в кортеж.
N>>Если в каком-то конкретном случае это хочется, то можно сделать довольно легко.
__>Как ?

Что-то вроде такого:

using System;
module A {
    static builtins : Reflection.Assembly = typeof(int*int).Assembly;
    public ToTuple[T](this l : list[T]) : object {
        def a = l.ToArray()  :> array[object];
        Activator.CreateInstance(builtins.GetType($"Nemerle.Builtins.Tuple`$(a.Length)").MakeGenericType(Type.GetTypeArray(a)), a)
    }
}

Console.WriteLine([1, 1.1, "a" : object].ToTuple())

Правда, стоит еще пару проверок добавить...

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, _nn_, Вы писали:

__>>>>По большей части нужно неявное или явное простой способ преобразования списка в кортеж.
N>>>Если в каком-то конкретном случае это хочется, то можно сделать довольно легко.
__>>Как ?

N>Что-то вроде такого:

N>

N>using System;
N>module A {
N>    static builtins : Reflection.Assembly = typeof(int*int).Assembly;
N>    public ToTuple[T](this l : list[T]) : object {
N>        def a = l.ToArray()  :> array[object];
N>        Activator.CreateInstance(builtins.GetType($"Nemerle.Builtins.Tuple`$(a.Length)").MakeGenericType(Type.GetTypeArray(a)), a)
N>    }
N>}

N>Console.WriteLine([1, 1.1, "a" : object].ToTuple())
N>

N>Правда, стоит еще пару проверок добавить...

Это довольно легко ?

Под простым преобразованием я понимаю следующий код:

f(Tuple([1,2,3]))

Неявное преобразование красивее, но могут ошибки вылезти где-нибудь =)

Здравствуйте, _nn_, Вы писали:

__>Это довольно легко ?

Да, это довольно легко! Вот как оно выглядит.

[1, 1.1, "a" : object].ToTuple()

Реализацию пишешь один раз в какой-нибудь библиотеке и подключаешь с помощью инструкции using. Какие проблемы?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>не знаю как в немерле, но в других языках кортежи могут включать элементы разных типов, а списки — только одного.

Точно так же и в Немерле.

BZ> при стат. типизации это две большие разницы. а вот в языках с динамической типизацией вроде перла это действительно одно и то же

В Лиспе так же. Отуда это и пошло.

Но у списков есть еще одно отличее. Их можно формировать динамически.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, _nn_, Вы писали:

__>>Это довольно легко ?

N>Да, это довольно легко! Вот как оно выглядит.

N>

[1, 1.1, "a" : object].ToTuple()

N>Реализацию пишешь один раз в какой-нибудь библиотеке и подключаешь с помощью инструкции using. Какие проблемы?

Я о реализации говорил, не об использовании

А вообще почему бы не добавить это в стандартную библиотеку ?
Было бы неплохо и добавить метов ToList в кортеж.
Так можно было бы просто сделать объединение кортежей.

Здравствуйте, _nn_, Вы писали:

__>Я о реализации говорил, не об использовании

Ну тут уж я ничего поделать не могу. Само собой ничего не получится. Для создания объекта заранее неизвестного типа в любом случае надо отражение использовать.

__>А вообще почему бы не добавить это в стандартную библиотеку ?
__>Было бы неплохо и добавить метов ToList в кортеж.

Не знаю. Сомневаюсь, что общественность это поддержит. Слишком уж невостребованная эта фича.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, _nn_, Вы писали:

__>>Я о реализации говорил, не об использовании

N>Ну тут уж я ничего поделать не могу. Само собой ничего не получится. Для создания объекта заранее неизвестного типа в любом случае надо отражение использовать.

В таком случае нужно иметь возможность указать.
Кстати, а почему тип заранее неизвестен ? Все типы ведь известны во времени компиляции.

[1, 2].ToTuple() // А размер какой будет ??

[1, 2].ToTuple(2) // => (1, 2)
[1 .. 10].ToTuple(3) // => (1, 2, 3)

def f(x : int, y : int) : int { x + y }
f((1, 2)) // OK
f([1, 2].ToTuple(2)) // OK
f([1, 2].ToTuple()) // Хм.. угадывать размер компилятору что ли ??

__>>А вообще почему бы не добавить это в стандартную библиотеку ?
__>>Было бы неплохо и добавить метов ToList в кортеж.

N>Не знаю. Сомневаюсь, что общественность это поддержит. Слишком уж невостребованная эта фича.

Хотя реализовавывается попроще чем ToTuple

Здравствуйте, _nn_, и nikov Вы писали, много и долго.

Мне каежется к конструктиву вы так и не пришли.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

Интересное обсуждение списков и кортежей (правда, применительно к питону) здесь

Здравствуйте, nikov, Вы писали:

N>Интересное обсуждение списков и кортежей (правда, применительно к питону) здесь

Применительно к python есть ещё отличие.
Списки изменяемы, кортежи нет. Поэтому списки нельзя использовать как ключи к словарям.

Здравствуйте, _nn_, Вы писали:

__>А так:
__>

__>def q(w : list[int])
__>{
__> f((w[0], w[1]))
__>}

__>// или так лучше :)
__>def q(w : list[int])
__>{
__>  f(w)
__>}
__>

Сделай так:

def q(w)
{
  f(w)
}

будет что-то в зависимости от того что передаш...

Компилятор сай выведет тип...

например при этом:

def q(w : list[int])
{
 f((w[0], w[1]))
}

Будет список...

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, _nn_, Вы писали:

__>>По большей части нужно неявное или явное простой способ преобразования списка в кортеж.
N>Если в каком-то конкретном случае это хочется, то можно сделать довольно легко.

__>>И еще хотелось бы чтобы компилятор мог определять размер списка во времени компиляции и передавать как кортеж если можно

N>Зачем?

Нафига козе баян....

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

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

Здравствуйте, Mckey, Вы писали:

M>Здравствуйте, _nn_, Вы писали:

__>>А так:
__>>

__>>def q(w : list[int])
__>>{
__>> f((w[0], w[1]))
__>>}

__>>// или так лучше :)
__>>def q(w : list[int])
__>>{
__>>  f(w)
__>>}
__>>

M>Сделай так:

M>

M>def q(w)
M>{
M>  f(w)
M>}
M>

M>будет что-то в зависимости от того что передаш...

M>Компилятор сай выведет тип...

M>например при этом:

M>

M>def q(w : list[int])
M>{
M> f((w[0], w[1]))
M>}
M>

M>Будет список...

Упс.. последнее должно выглядеть как:

def q(w)
{
 f((w[0], w[1]))
}

Прошу прощение за 23 февраля..

— праздник уже практически — наступил.. т.е. на работе уже прошёл — поэтому такие ошибки... — сорри...

Здравствуйте, Mckey, Вы писали:

M>Нафига козе баян....

1. Ты споришь с тем кто разделяет твою точку зрения (ты ошибся адесом).
M>поэто мне кажеться чт кто-то очень сильно тупит..
M>или мы или ты...
2. Давайте как будем по вежливей. Все же упертость и темболее просто другая точка зрения не является поводом для откровенных оскорблений.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Константин, Вы писали:

К>Применительно к python есть ещё отличие.
К>Списки изменяемы, кортежи нет. Поэтому списки нельзя использовать как ключи к словарям.

Кстати, это ошибка дизайна. Списки (точнее однонаправленные связанные списки) совершенно спокойно могут быть неизменяемыми. Во всех ФЯ списки неизменяемы. При их изменении всегда пораждаются новые списки. Так что при правильном вычислении хэш-функции и при правильном реализации сравнения списков они вполне могут выступать в качетсве ключей для — хэш-таблиц. Вот только хэш-значения при этом надо кэшировать. Иначе скорость будет проседать.

... << RSDN@Home 1.2.0 alpha rev. 637>>

От:	_nn_	www.nemerleweb.com
Дата:	12.02.07 08:12
Оценка:

	От:	BulatZiganshin
	Дата:	12.02.07 08:49
	Оценка:	2 (2)

От:	_nn_	www.nemerleweb.com
Дата:	12.02.07 09:06
Оценка:

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	12.02.07 09:37
Оценка:

От:	_nn_	www.nemerleweb.com
Дата:	12.02.07 09:48
Оценка:	-1

	От:	Андрей Хропов
	Дата:	12.02.07 11:52
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	12.02.07 18:37
Оценка:

	От:	Константин
	Дата:	22.02.07 12:49
	Оценка: