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

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

Почему?

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

AVK>Почему?

Потому-что нет причин, по которым они должны отличаться.

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


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

Если речь всё еще о ф-ии, а не о тождестве (уравнении), то ф-ия должна возвращать одно значение. На то она и ф-ия. А тот факт, что это значение может быть составным — пусть обыгрывается системой типов.

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

V>Если речь всё еще о ф-ии, а не о тождестве (уравнении), то ф-ия должна возвращать одно значение. На то она и ф-ия. А тот факт, что это значение может быть составным — пусть обыгрывается системой типов.

Речь-то о функциях в контексте программирования, а не математики. Но даже если, то смотри: Functions with multiple inputs and outputs.

Обрати внимание, что статья про функцию начинается с рассмотрения случая "один аргумент и один результат", а function with multiple outputs появляются в том же разделе где и function with multiple inputs, причем всего несколькими строками ниже.

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

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

Вот так можно возвращать несколько значений:

def foo(a : int, b : int) : int * string
{
  def sum = a + b;
  (sum, sum.ToString())
}
def (sum, str) = foo(1, 2);

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

H>Вот так можно возвращать несколько значений:

H>def (sum, str) = foo(1, 2);

А можно так :

1, 2 >- foo -> sum, str

То, что результат находится слева, пошло видимо от арабов (как и слово алгебра). Но арабы писали (и пишут, чудаки) справа налево, и потому нормальным людям не указ. (Это впрочем касается и порядка разрядов в числе от старших к младшим, нормальным слева направо пишущим людям должно быть удобнее наоборот.)

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

I>То, что результат находится слева, пошло видимо от арабов (как и слово алгебра).

Это пошло из школьной математики. Исторически сложилось. Но никто не мешает сразу выполнить анализ:

match (foo(1, 2))
{
 | (1, s) => ...
 | (2, s) => ...
...
}

I>Но арабы писали (и пишут, чудаки) справа налево, и потому нормальным людям не указ. (Это впрочем касается и порядка разрядов в числе от старших к младшим, нормальным слева направо пишущим людям должно быть удобнее наоборот.)

Арабы заимствовали десятичную позиционную систему счисления в Индии.

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

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

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

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

Вроде и так, но... Будет либо много синтаксических непоследовательных решений, либо просто странный синтаксис местами.

Если "список параметров" — кортеж, то, получается, можно передать и просто одиночное значение? Как внутри функции ссылаться на это одиночное значение и как ссылаться на части значения-кортежа (а-ля традиционные параметры)? Это далеко не все...

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

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

ARK>Если "список параметров" — кортеж ...

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

int*, size_t get_array_of_int()
{
    int* p;
    size_t n;
    . . .
    return p, n;
}

void f()
{
    int* p1;
    size_t n1;
    p1, n1 = get_array_of_int();
    . . .
    int* p2, size_t n2 = get_array_of_int();
}

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

I>По крайней мере для другого случая, а именно, когда список параметров не кортеж, существует простое и понятное решение (пример на C-подобном языке без операции запятая):

Предположим. Но тут другая кривость — предложенная вами функция, судя по всему, не может быть частью выражения.

if (get_array_of_int().тут_непонятно_что == 1) { ... }

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

AVK>ИМХО, основная проблема кортежей — в безымянности полей. Если типы полей разные (в статике), это еще можно пережить. Но когда типы одинаковые — это ахтунг.

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

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

В Шарпе (и дотнете) номинативная система типов, а тут нужна структрурная, иначе типы не будут совместимы между собой. Если в одной сборке их как-то можно "намапить" на один тип, то в случае множества сборок — нет.

Ну, и естественно, эта трава уже 100 лет существует в языках группы ML и называется "запись" (record).

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

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

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

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

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

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

AVK>?

Есть такая штука — паттерн-матчинг.

match (Func())
{
  | (a, SomeNestedAndComplexPattern()) => a.Foo();
}

В прочем ни с декомпозицией, ни с МП для записей особых проблем нет.

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

AVK>Зачем распаковывать поля объекта, когда объект уже есть?

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

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

VD>Как показывает реальная практика — это редко является проблемой.

Практика у всех разная. В моей практике отсутствие предопределенных имен для параметров лямбд (особенно описанных стандартными Action/Func) уже является проблемой. А в случае кортежей это еще важнее.

VD>В Шарпе (и дотнете) номинативная система типов, а тут нужна структрурная

Не нужна.

VD>, иначе типы не будут совместимы между собой

Это вопрос поддержки со стороны рантайма.

VD>Ну, и естественно, эта трава уже 100 лет существует в языках группы ML и называется "запись" (record).

Я в курсе, не переживай. Но рекорд все таки немного не то.

VD>Такие типы должны сравниваться не по имени, а по их их структуре (вложенности и расположению).

Разумеется.

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

VD>Для декомпозиции и сокращения синтаксиса. Те же кортежи отлично передаются в функцию без создания промежуточных переменных.

Как я уже говорил — декомпозиция кортежа в параметры функции в сочетании с перегрузкой по типам параметров слишком много синтаксических конфликтов порождает. Так что теоретически оно неплохо, уметь кортеж с выхода одной функции неявно распаковать в параметры другой, но на практике вопросов очень много.

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

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

Справедливости ради надо заметить, что при передаче параметров функциям есть варианты:

Add(42, "text");
Add(key=42, value="text");

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

I>То, что результат находится слева, пошло видимо от арабов (как и слово алгебра). Но арабы писали (и пишут, чудаки) справа налево, и потому нормальным людям не указ. (Это впрочем касается и порядка разрядов в числе от старших к младшим, нормальным слева направо пишущим людям должно быть удобнее наоборот.)

Предлагаешь писать цифры наоборот? А что? Отличная идея для 2102 года.

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

ARK>Предположим. Но тут другая кривость — предложенная вами функция, судя по всему, не может быть частью выражения.

ARK>

ARK>if (get_array_of_int().тут_непонятно_что == 1) { ... }
ARK>

Это только если ты зациклен на мэйнтриме. А так без проблема:

if (get_array_of_int() is (ary, 42))
{
  ... ary[41] ...
}

Прошу заметить, что это не гипотетический код, а совершенно реальный код для немерла. Разве что if надо на when заменить, или else добавить.

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

VD>>Для декомпозиции и сокращения синтаксиса. Те же кортежи отлично передаются в функцию без создания промежуточных переменных.

AVK>Как я уже говорил — декомпозиция кортежа в параметры функции в сочетании с перегрузкой по типам параметров слишком много синтаксических конфликтов порождает. Так что теоретически оно неплохо, уметь кортеж с выхода одной функции неявно распаковать в параметры другой, но на практике вопросов очень много.

Нет никаких конфликтов не выдумывай. И на практике никаких проблем нет. Я передаю кортежи в функции при каждом удобном случае.

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

То что ты хочешь можно выразить через виртуальное введение жестких псевдонимов типов. Но это уже довольно сложно (в дотнете и понятия жесткого псевдонима типов то нет). Тогда тип:

{ foo : int; bar : int }

будет переписан в:

type alias foo_int = int;
type alias bar_int = int;
foo_int * bar_int

но тут мы снова получаем проблему несовместимости типов объявленных в разных сборках.

Так что как не крути, а есть всего два пути:
1. Немного доработать рантайм и ввести в него структурные типы.
2. Использовать кортежи, а имена использовать только для сахара позволяющего получать доступ к полям кортежа по именам. При этом имена просто хранить как метаинформацию функций/полей.

Других путей нет.

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

AVK>Практика у всех разная. В моей практике отсутствие предопределенных имен для параметров лямбд (особенно описанных стандартными Action/Func) уже является проблемой. А в случае кортежей это еще важнее.

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

VD>>В Шарпе (и дотнете) номинативная система типов, а тут нужна структрурная

AVK>Не нужна.

Весомое мнение. Продолжая в том же духе ты многих убедишь (себя — точно).

VD>>, иначе типы не будут совместимы между собой

AVK>Это вопрос поддержки со стороны рантайма.

Всего то? В следующий раз не забудь дочитать сообщение на которое отвечаешь хотя бы до середины.

VD>>Ну, и естественно, эта трава уже 100 лет существует в языках группы ML и называется "запись" (record).

AVK>Я в курсе, не переживай. Но рекорд все таки немного не то.

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

VD>>Такие типы должны сравниваться не по имени, а по их их структуре (вложенности и расположению).

AVK>Разумеется.

Если ты с этим согласен, то остается ответить на вопрос — как совместить идею имен с идеей структурной эквивалентности?

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