Здравствуйте, NeoCode, Вы писали:
NC>Пытаюсь построить идеальную модель кортежей в некотором языке программирования.
NC>Кортеж — это просто некоторая группа объектов (переменных, констант), не имеющая собственного типа, а существующая на этапе компиляции просто для удобства.
NC>Записывается просто как список объектов в круглых скобках через запятую.
Тоже думал о таком, и вот что придумал:
1)Вам необходимо представить кортеж как группу(линейную последовательность или вектор) значений/ООП-объектов, а не переменных и не констант, т.е. значение может быть получено из переменной, задано при помощи константы и т.п.
2)Вам нужно представить выполнение оператора/вызова в три этапа(например для "r = s + 2"(s: "int s = 1")):
a)Извлечение из источника/создание значений-аргументов, в примере извлечение "1" из "s" и создание непосредственно определённого "2".
b)Выполнение операции над значениями-аргументами и получение значения-результата, в примере сложение "1" и "2", результат "3".
c)Помещение значения-результата в приёмник, в примере помещение "3" в переменную "r".
Выражения (типа "r = s + (1 / g) — d * 3") выполняются точно так же, но имеют несколько шагов b), а значение-результат предыдущего шага передаётся в следующий.
Для кортежей это будет соответственно(для "r,g = s,d + 1,2"(s: "int s = 3", d: int d = 4")):
a)"s,d","1,2" -> [3,4],[1,2]
b)[3,4]+[1,2] = [4,6]
c)[4,6] -> "r,g"
3)Кортежи "существуют"(на самом деле их вообще не существует, это ментальный сахар) только пока выполняется оператор/выражение, т.е. их нельзя просто сохранить в переменную(одну).
4)Если в вашем ЯП есть структуры/массивы или что-то подобно необходимо предусмотреть сретсва/правила их декомпозиции в кортеж(на a)) и композиции из кортежа(на b)).
NC>На простых примерах вроде все хорошо, но дальше начинаются противоречия и ужасы.
NC>- поведение таких групп внутри сложных выражений ?
Сложные выражения разбиваются на простые.
NC>- простая, понятная и правильная логика обработки операций над двумя и более кортежами разных размеров ?
Правило дополнения: меньший кортеж дополняется до размера большего копиями своего последнего значения. Например:
s,t,g = 1 //s = 1,t = 1,g = 1
s,t,g = 1,2 //s = 1,t = 2,g = 2
NC>- передача кортежей в функции; по аналогии с возвращаемыми значениями, список аргументов функции тоже кортеж, но если возможен например инкремент сразу трех переменных, то что делать если программист хочет вызвать функцию сразу для трех переменных?
NC>Foo((i,j,k)); //???
NC>- соответственно, получение множественного возврата из обычных функций, в которые передали кортеж (по аналогии с операциями!)
NC>(d1,d3,d3,d4) = sin(0.2, 0.4, 0.6, 0.8); // double sin(double x)
Тут ничего не подскажу(у меня в ЯП функции принимают только один аргумент, и возвращают только один результат или ничего).
NC>- ну и если рассматривать наложение ситуаций множественного возврата и множественных аргументов, то вообще бред получается.
Этого не понял.

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

H>1) Кортежи в C# можно и нужно изготавливать так:
H>

H>Tuple.Create(true, "value");
H>

А в чем разница кроме синтаксиса?

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

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

H>>1) Кортежи в C# можно и нужно изготавливать так:
H>>

H>>Tuple.Create(true, "value");
H>>

V>А в чем разница кроме синтаксиса?

В C# нельзя вызвать конструктор опуская параметры типов. В подобных случаях типы очевидны, и их явное указание существенно добавляет визуального мусора.

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

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

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

H>>>1) Кортежи в C# можно и нужно изготавливать так:
H>>>

H>>>Tuple.Create(true, "value");
H>>>

V>>А в чем разница кроме синтаксиса?

H>В C# нельзя вызвать конструктор опуская параметры типов. В подобных случаях типы очевидны, и их явное указание существенно добавляет визуального мусора.

Спасибо, возьму на заметку)

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

ИМХО, основная проблема кортежей — в безымянности полей. Если типы полей разные (в статике), это еще можно пережить. Но когда типы одинаковые — это ахтунг.
В этом плане анонимные типы аля C# существенно лучше. Но у них другая проблема — исключительно локальная доступность.
В идеале, мне кажется, нужны шарповские анонимные типы + синтаксис для декларации типа без создания экземпляра. Типа такого:

{string Foo, string Bar} Func()
{
  return new {Foo = "foo", Bar = "bar"};
}

Здравствуйте, AndrewVK, Вы писали:
AVK>В идеале, мне кажется, нужны шарповские анонимные типы + синтаксис для декларации типа без создания экземпляра. Типа такого:

{string Foo, string Bar} Func()
{
  return new {Foo = "foo", Bar = "bar"};
}

Если мы говорим про шарп, то для этого придётся или ограничить использование анонимных типов внутри сборки, или расширять il/рантайм. Иначе код вида

// assembly1
void Func({string Foo, string Bar} x) ...

// assembly2
void Func({string Foo, string Bar} x) ...

// assembly3
void Func2({string Foo, string Bar} x)
{
  ClassFromAssembly1.Func(x);

  ClassFromAssembly2.Func(x);
}

работать не будет.

Если всё-таки добавлять, то я бы выбрал первый вариант. Его сделать относительно несложно, плюс, внешний интерфейс сборки не будет нарушать CLS и не будет проблем с бинарной совместимостью сборок при добавлении в возвращаемый кортеж нового элемента.

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

S>Если всё-таки добавлять, то я бы выбрал первый вариант. Его сделать относительно несложно, плюс, внешний интерфейс сборки не будет нарушать CLS и не будет проблем с бинарной совместимостью сборок при добавлении в возвращаемый кортеж нового элемента.

Первый вариант, увы, отсекает очень вкусное использование такого синтаксиса при описании моделей различных. Еще такое очень удобно в сочетании с сокращенным синтаксисом для описания POCO/DTO классов в контрактных сборках.

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

NC>Элементы группы не взаимодействуют между собой при групповых операциях, имеется в виду только взаимодействие i-того элемента группы и другого операнда.
NC>

x -= (1,2,3); // x-=1; x-=2; x-=3;
NC>(x,y,z) -= 10; // x-=10; y-=10; z-=10;
NC>(x,y,z) -= (1,2,3); // x-=1; y-=2; z-=3;

Это как один из вариантов. Почему бы и нет..

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

AVK>В идеале, мне кажется, нужны шарповские анонимные типы + синтаксис для декларации типа без создания экземпляра. Типа такого:
AVK>

AVK>{string Foo, string Bar} Func()
AVK>{
AVK>  return new {Foo = "foo", Bar = "bar"};
AVK>}
AVK>

Да, плюс упаковка-распаковка:

string a;
string b;
(a, b) = Func();

// либо
{string Foo, string Bar} tuple; // здесь имена полей должны совпадать с теми, что в Func
tuple = Func();

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

ARK>Да, плюс упаковка-распаковка:

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

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

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

ARK>>Да, плюс упаковка-распаковка:

AVK>Упаковка-распаковка нужна только для безимянных кортежей. Когда элементы кортежа имеют полноценное имя, распаковка не нужна.

Ну хз, мне кажется, что удобно. И ничему не мешает.

AVK>А эквивалентность списка параметров метода кортежу порождает слишком много синтаксических конфликтов.

Про эквивалентность списка параметров метода кортежу я нигде не говорил.

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

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

AVK>Первый вариант, увы, отсекает очень вкусное использование такого синтаксиса при описании моделей различных. Еще такое очень удобно в сочетании с сокращенным синтаксисом для описания POCO/DTO классов в контрактных сборках.

Ок, тогда можно попробовать компромисс: фактически возвращать и принимать обычный Tuple<string, string>, в il дополнительно описывать имена полей для tuple.

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

ARK>Ну хз, мне кажется, что удобно. И ничему не мешает.

Чем удобно? Чем такой код:

(a, b) = Func();
a(); b();

сильно удобнее такого:

var ab = Func();
ab.a();ab.b();

?

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

S>Ок, тогда можно попробовать компромисс: фактически возвращать и принимать обычный Tuple<string, string>, в il дополнительно описывать имена полей для tuple.

Так можно, да.

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

S>Ок, тогда можно попробовать компромисс: фактически возвращать и принимать обычный Tuple<string, string>, в il дополнительно описывать имена полей для tuple.

Тут еще может быть стоит подумать, как унифицировать сокращенный синтаксис DTO и синтаксис анонимных типов. Т.е. что то вроде:

record NamedRecord {string X, string Y, record {string Foo, string Bar} FooBar}

Раскрывается в:

class NamedRecord
{
  private string _X;
  private string _Y;
  private Tuple<string, string> _FooBar;
  
  public NamedRecord(string X, string Y, Tuple<string, string> FooBar)
  {
    ...
  }
  
  public string X {get{...}}
  public string Y {get{...}}
  [Name(0, "Foo")]
  [Name(1, "Bar")]
  public Tuple<string, string> FooBar {get{...}}
  
  public override bool Equals(...){...}
  public override int GetHashCode()(...){...}
}

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

AVK>Чем удобно? Чем такой код:
AVK>сильно удобнее такого:

Ну, прям о каком-то новом уровне удобства речи нет, конечно.
Можно, например, распаковывать результат функции прямо в поля объекта — без дополнительных присваиваний.
С другой стороны, минус тоже есть — можно при распаковке перепутать поля одинаковых типов.

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

ARK>Можно, например, распаковывать результат функции прямо в поля объекта — без дополнительных присваиваний.

Зачем распаковывать поля объекта, когда объект уже есть? Вот когда вместо объекта примитивный тупл, тогда да, тогда смысл имеется. А в случае анонимных типов это уже целый меппер, встроенный в язык, и необходимость его на уровне языка — вопрос открытый.

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

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

ARK>>Можно, например, распаковывать результат функции прямо в поля объекта — без дополнительных присваиваний.

AVK>Зачем распаковывать поля объекта, когда объект уже есть? Вот когда вместо объекта примитивный тупл, тогда да, тогда смысл имеется. А в случае анонимных типов это уже целый меппер, встроенный в язык, и необходимость его на уровне языка — вопрос открытый.

Я имею в виду нечто вроде:

class Foo
{
  public static {string A, int B} GetTuple(int param) { ... }
}

class Bar
{
  private int _field1;
  private string _field2;

  void Func()
  {
    (_field2, _field1) = Foo.GetTuple(3);

    // а можно и так:
    var tup = Foo.GetTuple(3);
    _field1 = tup.B;
    _field2 = tup.A;
  }
}

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

ARK>Я имею в виду нечто вроде:

Ну я и говорю — ты хочешь фактически встроенный в язык меппер.

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

NC>1. возврат нескольких значений из функции

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