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


N>Полной эта схема будет тогда, когда можно будет где-то отдельно сформировать набор аргументов функции в виде кортежа и затем передать его в функцию. Аналоги — питоновый callable(*args) и эрланговый apply(Fun,Args) (в эрланге передаётся список, а не кортеж, но это тут менее важно). Не знаю, как оно сейчас в Nemerle, но описанного тут — явно недостаточно.

В D от digitalmars, в котором схема вполне аналогична немерлевской, можно без как проблем сформировать кортеж отдельно и передать в функцию, так и наоборот "разобрать" функцию на возвращаемое значение и кортеж параметров.

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

S>А там есть definite assignment?
В стандарте не прописано, но обычно компиляторы проводят анализ.

S>Какие ограничения на использование b накладываются на тело GetSomeInt?
В в оригинальной аде в out-параметры можно только писать. В аде-95 разрешено и читать.

Что такое — запись?

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

D>Что такое — запись?

http://msdn.microsoft.com/en-us/library/dd233184(VS.100).aspx

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

D>Что такое — запись?

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

Более развернуто: Record.

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

D>>Что такое — запись?

FR>http://msdn.microsoft.com/en-us/library/dd233184(VS.100).aspx

Эта ссылка может ввести в заблуждение. Тип записи может не иметь явного имени.

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

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

N>С какого-то количества элементов в ответе таки да (опыт того же Erlang). Просто примеры не совсем адекватны: пока этих элементов 2-3 — собеседники не видят смысла в подобной "хитрой штуке". На практике же дофига случаев, когда их и 10, и 30. Если их состав определён на этапе компиляции, то рисовать мап на них — нехорошо, лучше пользоваться именованными статическими позициями. По сказанному, я "издалека" поддерживаю эту идею.

На моей практике 10 и тем более 30 не встречалось ни разу. Но сути дела это, по-моему, не меняет.

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

Это так и есть на практике. В немрле, ты можешь сделать так:

def x = ("aaa", 12);
f(x)

N>Аналоги — питоновый callable(*args) и эрланговый apply(Fun,Args) (в эрланге передаётся список, а не кортеж, но это тут менее важно). Не знаю, как оно сейчас в Nemerle, но описанного тут — явно недостаточно.

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

N>(К слову — тут явно не хватает ещё одного вида скобок для кортежей. Для сравнения, в Erlang — {...},

Наоборот. Это унификация. Тем самым показывается, что нет разницы между списком параметров и кортежем.

N>а в таком оригинальном языке как Рапира (на формирование которого явно повлияли какие-то ранние ФЯ) — <*...*>. В питоне обошлись круглыми скобками и поэтому для кортежа в один элемент используют синтаксический костыль)

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

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

PD>В основном ты прав, но ИМХО все это эффекты второго порядка. Я согласен, что писать придется несколько иначе и эти эффекты надо учитывать. Но , на мой взгляд, эти отличия второго порядка недостаточны, чтобы вводить новое понятие в язык, поскольку пусть не на 100%, но на 99.9% мы уже имеем то же самое иным способом.

Это эффект первого порядка — immutability (неизменяемость). А все остальное — следствия.

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

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

PD>И ИМХО не надо вводить в язык дополнительные сущности, пока не станет ясно, что без них обходиться нельзя. Именно нельзя. А не "мне хотелось бы это написать в одну строку, а не 3"

Тогда за фиг тебе С++? На С можно писать точно так же, только с большим количеством явно выраженных деталей. Ну, а раз можно обходиться, то нужно (по твоей логике)!

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

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

N>>С какого-то количества элементов в ответе таки да (опыт того же Erlang). Просто примеры не совсем адекватны: пока этих элементов 2-3 — собеседники не видят смысла в подобной "хитрой штуке". На практике же дофига случаев, когда их и 10, и 30. Если их состав определён на этапе компиляции, то рисовать мап на них — нехорошо, лучше пользоваться именованными статическими позициями. По сказанному, я "издалека" поддерживаю эту идею.

VD>На моей практике 10 и тем более 30 не встречалось ни разу. Но сути дела это, по-моему, не меняет.

Суть — нет. Показательность примера для увода от посторонних обсуждений — да.

N>>Аналоги — питоновый callable(*args) и эрланговый apply(Fun,Args) (в эрланге передаётся список, а не кортеж, но это тут менее важно). Не знаю, как оно сейчас в Nemerle, но описанного тут — явно недостаточно.
VD>Это не аналогии. К функциям с переменным числом аргументов это отношения не имеет.

Описанное мной точно так же годится для функций с постоянным числом аргументов, и на практике так в основном и применяется. При чём тут переменное число аргументов?

N>>(К слову — тут явно не хватает ещё одного вида скобок для кортежей. Для сравнения, в Erlang — {...},
VD>Наоборот. Это унификация. Тем самым показывается, что нет разницы между списком параметров и кортежем.

Если нет разницы, то это уже не статическая типизация.

N>>а в таком оригинальном языке как Рапира (на формирование которого явно повлияли какие-то ранние ФЯ) — <*...*>. В питоне обошлись круглыми скобками и поэтому для кортежа в один элемент используют синтаксический костыль)

VD>Питен не типизированный язык,

Ну вот, кончил за упокой. С каких это пор он не типизированный?

VD> так что в нем массив трудно отличим от кортежа.

В нём вообще массива нет, а если ты про список — отличия очень заметные.

VD> Вобщем, со скриптами отдельный разговор. В них многое по-другому.

Как-то ты походя прокомментировал все "скрипты", несмотря на то, что между ними порой больше разницы, чем с тем же Nemerle...

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

N>>>Аналоги — питоновый callable(*args) и эрланговый apply(Fun,Args) (в эрланге передаётся список, а не кортеж, но это тут менее важно). Не знаю, как оно сейчас в Nemerle, но описанного тут — явно недостаточно.
VD>>Это не аналогии. К функциям с переменным числом аргументов это отношения не имеет.

N>Описанное мной точно так же годится для функций с постоянным числом аргументов, и на практике так в основном и применяется. При чём тут переменное число аргументов?

А разве *args — это не оно?

N>>>(К слову — тут явно не хватает ещё одного вида скобок для кортежей. Для сравнения, в Erlang — {...},
VD>>Наоборот. Это унификация. Тем самым показывается, что нет разницы между списком параметров и кортежем.

N>Если нет разницы, то это уже не статическая типизация.

Ложное утверждение.

N>>>а в таком оригинальном языке как Рапира (на формирование которого явно повлияли какие-то ранние ФЯ) — <*...*>. В питоне обошлись круглыми скобками и поэтому для кортежа в один элемент используют синтаксический костыль)

VD>>Питен не типизированный язык,

N>Ну вот, кончил за упокой. С каких это пор он не типизированный?

С рождения.

Ладно. Такой уровень дисскуссии меня не устраиват. За сим откланиваюсь.

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

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

N>>>>Аналоги — питоновый callable(*args) и эрланговый apply(Fun,Args) (в эрланге передаётся список, а не кортеж, но это тут менее важно). Не знаю, как оно сейчас в Nemerle, но описанного тут — явно недостаточно.
VD>>>Это не аналогии. К функциям с переменным числом аргументов это отношения не имеет.

N>>Описанное мной точно так же годится для функций с постоянным числом аргументов, и на практике так в основном и применяется. При чём тут переменное число аргументов?

VD>А разве *args — это не оно?

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

VD>>>Питен не типизированный язык,
N>>Ну вот, кончил за упокой. С каких это пор он не типизированный?
VD>С рождения.
VD>Ладно. Такой уровень дисскуссии меня не устраиват. За сим откланиваюсь.

Ну куда нам, убогим, до твоего божественного величества.

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

VD>>>>Питен не типизированный язык,
N>>>Ну вот, кончил за упокой. С каких это пор он не типизированный?
VD>>С рождения.
VD>>Ладно. Такой уровень дисскуссии меня не устраиват. За сим откланиваюсь.

N>Ну куда нам, убогим, до твоего божественного величества.

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

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

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

VD>>>>>Питен не типизированный язык,
N>>>>Ну вот, кончил за упокой. С каких это пор он не типизированный?
VD>>>С рождения.
VD>>>Ладно. Такой уровень дисскуссии меня не устраиват. За сим откланиваюсь.

N>>Ну куда нам, убогим, до твоего божественного величества.

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

Это не "докапывание до терминов", это поиск согласования. Когда ты говоришь какие-то вещи безусловно не соответствующие общепринятому пониманию, "совершенно точно имеет факт одного из двух" — или непонимание, или своя терминология ради какой-то своей цели. Но причины такого определения ты раскрывать не хочешь — ну что ж, заставить нельзя:))

VD> В данном случае совершенно точно имеет факт одного из двух.

Мимо. Впрочем, возобновлять дискуссию мне облом.

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

VD>Тогда за фиг тебе С++? На С можно писать точно так же, только с большим количеством явно выраженных деталей. Ну, а раз можно обходиться, то нужно (по твоей логике)!

Инкапсулирование. На С практически невозможно, разве что пародия.
Наследование. То же.
Полиморфизм. То же.

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

S>Ну, я так и подумал. Впрочем, мой аргумент ты очень хорошо подчеркнул — даже "минимальный демонстрационный" пример получился достаточно громоздким, чтобы объяснить сомневающимся все преимущества нормального решения.

Подумал еще раз. Сравним два решения (моих)

FPoint fp = GetPoint();

IPoint ip;
GetPointByRef(ip);
FPoint fp1 = ip;

Дьявол в деталях, ты прав. Вот и давай этого дьявола поищем тут.

Первый способ создания FPoint выглядит намного красивее ? Бесспорно. Но!

Тебе очевидно, глядя на эту единственную строчку, что здесь создается два экземпляра ? Один — промежуточный IPoint, возвращаемый GetPoint, другой — результат конструирования FPoint по этому промежуточному IPoint.
Мне — не очевидно. Глядя на этот код, я не знаю этого. И компилятор мне не поможет — конструктор такой есть, все честно.

А вот во втором варианте кода это ясно даже младенцу. И глядя на него, я задамся вопросом — а нужен ли здесь этот IPoint ip вообще ? Может быть, это совсем ненужная промежуточная сущность, от которой можно в данном случае отказаться.

FPoint fp1;
GetFPointByRef(fp1);

и теперь нет второго экземпляра. Только один остался.

А если я вот так попробую

GetPointByRef(fp1);

то компилятор меня поправит — нельзя так! И правильно, что нельзя.

А может, IPoint вообще лишняя сущность ? Может, его лучше ликвидировать как класс совсем ? Действительно я не могу обойтись вещественными точками, и мне нужны еще целые ? Почему нужны ? Ответ на это вопрос , возможно, заставит меня пересмотреть то, что я делаю и упростить код.

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


PD>>Бесплатный сыр бывает только в мышеловках
S>Ну-ну. Предлагаю отказаться от бесплатного сыра типа компайл-тайм проверки типов или перегрузки операторов. Наверно, это мышеловка — надо вернуться в старый добрый K&R C без этих новомодных фишек вроде описания типов аргументов прямо в месте декларации функции.

Неубедительно. От проверки типов в компайл-тайм никому хуже не будет, и никаких затрат в рантайме не потребуется. И от описания типов в заголовке вместо того, чтобы их описывать в стиле K&R — тоже не будет. Последнее — просто элементарное улучшение синтаксиса.

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

[...]

S>И вся эта могучая магия, надёжно отлаженная в поколениях компиляторов, мгновенно испаряется в тот момент, когда я хочу получить два значения вместо одного.

S>А вот более реалистичный пример
S>

S>(int modulo, int reminder) = IntDivide(arg, divisor); 
S>// не работает, если arg и divisor - byte; 
S>// при очевидном определении IntDivide как 
S>template<classname T>
S>void IntDivide(T arg, T divisor, T &modulo, T &remainder)
S>// вместо этого мне нужно вручную выписывать нудные промежуточные присваивания
S>// хотя вот такой код будет работать безо всяких проблем:
S>int modulo = arg / divisor; // здесь сработает очевидное расширение байта до инта
S>int remainder = arg % divisor; // но делить придётся дважды, вместо быстрой операции, которая получает сразу оба числа.
S>

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

На том же С++ реализуется достаточно просто — для тупла нужны шаблонные копирующий конструктор и оператор присваивания, которые почленно конструируют связку хранимых объектов — соответствующий конструктор/assigment operator будет выбран автоматически. При это скалярами ограничиваться необязательно — если тип T может быть сконструирован из типа U, то такое преобразование для каждого члена тупла будт использоваться автоматически.

Так сделано, например, в boost::tuple:

//...

template<class T>
tuple<T, T> f(T a, T b) //...

void g()
{
  typedef char byte;

  byte a = 17, b = 7;
  int i1, i2;
  double d1;
    
  tie(i1, i2) = f(a, b); // <byte, byte> -> <int, int>
  tie(i1, d1) = f(a, b); 
    
  tuple<float, float> t1 = f(a, b);   // <byte, byte> -> <float, float>
  tuple<int, float>   t2 = f(i1, i2);
}

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


PD>А вот во втором варианте кода это ясно даже младенцу. И глядя на него, я задамся вопросом — а нужен ли здесь этот IPoint ip вообще ? Может быть, это совсем ненужная промежуточная сущность, от которой можно в данном случае отказаться.
Ну, то есть понятно, что ты начнёшь задаваться лишними вопросами.

PD>А может, IPoint вообще лишняя сущность ? Может, его лучше ликвидировать как класс совсем ? Действительно я не могу обойтись вещественными точками, и мне нужны еще целые ? Почему нужны ? Ответ на это вопрос , возможно, заставит меня пересмотреть то, что я делаю и упростить код.
Это вряд ли. Пока что ты занимаешься тем, что только усложняешь код. У тебя была библиотечная функция, которая работала с целыми точками. Теперь ты её интегрируешь в программу, которая должна работать с вещественными. Какое "упрощение" ты хочешь сделать? Переписать готовую функцию, которая работала на быстрой целой арифметике, чтобы она теперь пользовалась медленной плавающей?

PD>Ну а если я все же приду к выводу, что IPoint нужен, и здесь действительно нужно такое конструирование двух объектов, а не одного... ну тогда будет 3 строчки вместо одной. Зато я ясно понимаю, что я тут делаю, а не полагаюсь на неявные преобразования, которых я тут не вижу и которые, возможно, совсем не так эффективны, как мне бы этого хотелось.

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

double d = GetSomeFloat();

Ок? Это ж пустяки — писать всякий раз явно new double(GetSomeFloat()).


PD>Неубедительно. От проверки типов в компайл-тайм никому хуже не будет, и никаких затрат в рантайме не потребуется.
Ну, то есть таки бывает бесплатный сыр?
PD> И от описания типов в заголовке вместо того, чтобы их описывать в стиле K&R — тоже не будет. Последнее — просто элементарное улучшение синтаксиса.
Правда что ли? А я полагал, что это элементарное улучшение семантики. Которое позволяет избежать ошибок при вызове функции — в K&R компилятор вообще ничего не компилирует, и нет проблем передать double вместо int.

Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>На том же С++ реализуется достаточно просто — для тупла нужны шаблонные копирующий конструктор и оператор присваивания, которые почленно конструируют связку хранимых объектов — соответствующий конструктор/assigment operator будет выбран автоматически. При это скалярами ограничиваться необязательно — если тип T может быть сконструирован из типа U, то такое преобразование для каждого члена тупла будт использоваться автоматически.

Всё не совсем так. То есть, это тоже реализация, хотя и совсем другая, чем предложил Павел.
Он, напомню, предложил считать запись (string ret1, int ret2) FuncName(string param1, int param2) эквивалентной void FuncName(string param1, int param2, out int ret2, out string ret1).
Такой подход всё еще позволяет направить результат функции в нужные локальные переменные (или поля доступного локально объекта), хотя по-прежнему сильно ограничен по сравнению с возвратом одного аргумента.

В твоём подходе мы требуем создавать именованный тип для возвращаемого значения.
Ну, то есть буст предлагает анонимный тупл с анонимными мемберами, но это всё еще не то, чего хочется.

Хочется, чтобы всё было в полный рост:
1. Возможность описывать имена компонентов тупла, чтобы пользователь меньше встревал. В подходе Павла реализуется само, через имена out-параметров. В твоём — нужно приватно наследоваться от анонимного тупла и задавать маппинг компонентов вручную
2. Возможность структурной эквивалентности
3. Еще всякие занятные возможности, которые скорее всего расходятся с идеями Влада.

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


PD>>А вот во втором варианте кода это ясно даже младенцу. И глядя на него, я задамся вопросом — а нужен ли здесь этот IPoint ip вообще ? Может быть, это совсем ненужная промежуточная сущность, от которой можно в данном случае отказаться.
S>Ну, то есть понятно, что ты начнёшь задаваться лишними вопросами.

А почему они лишние ? Аргументов пока не вижу.

PD>>А может, IPoint вообще лишняя сущность ? Может, его лучше ликвидировать как класс совсем ? Действительно я не могу обойтись вещественными точками, и мне нужны еще целые ? Почему нужны ? Ответ на это вопрос , возможно, заставит меня пересмотреть то, что я делаю и упростить код.
S>Это вряд ли. Пока что ты занимаешься тем, что только усложняешь код. У тебя была библиотечная функция, которая работала с целыми точками. Теперь ты её интегрируешь в программу, которая должна работать с вещественными. Какое "упрощение" ты хочешь сделать? Переписать готовую функцию, которая работала на быстрой целой арифметике, чтобы она теперь пользовалась медленной плавающей?

При чем тут быстрые и медленные целые и плавающие точки ? Мы что обсуждаем, скорость целой арифметики по сравнению с вещественной ? Речь вовсе не об этом, а о том, что создается 2 экземпляра. И во втором варианте этот факт присутствует явно, а в первом это можно легко упустить из виду. Написать очень красивую конструкцию, в одну строчку, а в ней такой дьявол порылся, что в действительности там несколько промежуточных экземпляров создается, память тратится и время. Так я предпочитаю явно видеть, что они создаются, тогда я еще подумаю, надо ли. И если все же надо (применительно к моему примеру это значит, что выкинуть IPoint нельзя), то преобразования я напишу явно, так что буду уверен, что это именно то преобразование, которое здесь уместно, а не то, которое здесь получилось из-за того, что я (допустим) неправильно понимаю, какие там в этих классах преобразования есть.

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

S>double d = GetSomeFloat();
S>

S>Ок? Это ж пустяки — писать всякий раз явно new double(GetSomeFloat()).

Господи, зачем же до абсурда все доводить ? Я разве предложил запретить ? Да бога ради, пусть будет. И с float в double, и c IPoint в FPoint. Я просто говорю, что ИМХО лучше в более или менее сложных случаях использовать явные преобразования, так как при этом ясно, что происходит в действительности. И тому, кто пишет, и тому, кто читает. А плата ничтожная — подумаешь, вместо одной строчки 3 написать! Тем более что пишется и то и другое почти на автомате.

А эффективность явного и неявного преобразования — одна и та же. По той простой причине, что код один и тот же фактически. Как ни крути, а без конструктора FPoint(IPoint&) никуда не денешься, и он в обоих случаях вызывается.


PD>>Неубедительно. От проверки типов в компайл-тайм никому хуже не будет, и никаких затрат в рантайме не потребуется.
S>Ну, то есть таки бывает бесплатный сыр?

Нет. Просто в С не продумали это как следует, а в С++ исправили. Или, если хочешь, в С руководствовались принципом "да позволим как можно больше", а в С++ — "не позволи то, что слишком рискованно".

PD>> И от описания типов в заголовке вместо того, чтобы их описывать в стиле K&R — тоже не будет. Последнее — просто элементарное улучшение синтаксиса.
S>Правда что ли? А я полагал, что это элементарное улучшение семантики. Которое позволяет избежать ошибок при вызове функции — в K&R компилятор вообще ничего не компилирует, и нет проблем передать double вместо int.

Или ты не в курсе про lint, или сознательно делаешь вид, что не в курсе. Там именно рекомендовалось обязательно использовать lint для такой проверки. Фактически то же самое, но проверку передали сторонней утилите. Не лучшее решение, вот и поправили.