Расскажите, пожалуйста, зачем нужны системы типов. Какие задачи они решают?
Например, очевидно, что типы позволяют производить проверки корректности кода, диспатчить полиморфизмы типа оператора сложения (хотя здесь я не уверен).
Здравствуйте, Temoto, Вы писали:
T>Привет.
T>Расскажите, пожалуйста, зачем нужны системы типов. Какие задачи они решают?
T>Например, очевидно, что типы позволяют производить проверки корректности кода, диспатчить полиморфизмы типа оператора сложения (хотя здесь я не уверен).
Полиморфизмы можно и без типов сделать
Ну, вообще говоря они позволяют использовать код повторно при наследовании (доопределение методов и полей, полиморфизм), приводить типы вверх по дереву и унифицированно обращаться с ними, дают компилятору информацию о том как именно хранить и что хранить в объекте (иначе каждый объект должен быть словарём переменных), ограничивать область видимости методов (икапсуляция, абстрагирование), предоставлять стандартные интерфейсы без реализации
T>>Расскажите, пожалуйста, зачем нужны системы типов. Какие задачи они решают?
T>>Например, очевидно, что типы позволяют производить проверки корректности кода, диспатчить полиморфизмы типа оператора сложения (хотя здесь я не уверен).
Спасибо за ответ.
FDS>Полиморфизмы можно и без типов сделать
Можно поподробнее? Как компилятор узнает какую именно реализацию оператора сложения подставить, если ему неизвестен тип операндов?
Здравствуйте, Temoto, Вы писали:
FDS>>Полиморфизмы можно и без типов сделать
T>Можно поподробнее? Как компилятор узнает какую именно реализацию оператора сложения подставить, если ему неизвестен тип операндов?
У вас во всех операндах должен быть определён один и тот же метод "+", который хранится в словаре методов. Компилятор, точнее интерпретатор, посмотрит на то, что все методы в объектах одинаковые, и применит их соотв. образом.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Полиморфизмы можно и без типов сделать
S>Исходя из определения полиморфизма — это вряд ли.
Полиморфизм (polymorphism) (от греческого polymorphos) — это свойство, которое позволяет одно и то же имя использовать для решения двух или более схожих, но технически разных задач.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, Temoto, Вы писали:
FDS>>>Полиморфизмы можно и без типов сделать
T>>Можно поподробнее? Как компилятор узнает какую именно реализацию оператора сложения подставить, если ему неизвестен тип операндов?
FDS>У вас во всех операндах должен быть определён один и тот же метод "+", который хранится в словаре методов. Компилятор, точнее интерпретатор, посмотрит на то, что все методы в объектах одинаковые, и применит их соотв. образом.
Т.е. "во всех операндах должен быть определён" тип с методом "+" ?
Здравствуйте, Курилка, Вы писали:
FDS>>У вас во всех операндах должен быть определён один и тот же метод "+", который хранится в словаре методов. Компилятор, точнее интерпретатор, посмотрит на то, что все методы в объектах одинаковые, и применит их соотв. образом.
К>Т.е. "во всех операндах должен быть определён" тип с методом "+" ?
Совершенно не обязательно. Если допустить, что для каждого объекта можно добавлять свой метод, то мы не нуждаемся в типах вообще.
Здравствуйте, FDSC, Вы писали:
FDS>>>Полиморфизмы можно и без типов сделать
S>>Исходя из определения полиморфизма — это вряд ли.
FDS>отсюда FDS>
FDS>Полиморфизм (polymorphism) (от греческого polymorphos) — это свойство, которое позволяет одно и то же имя использовать для решения двух или более схожих, но технически разных задач.
FDS>Чем вам мешает это определение, если нет типов?
Здравствуйте, FDSC, Вы писали:
К>>Т.е. "во всех операндах должен быть определён" тип с методом "+" ?
FDS>Совершенно не обязательно. Если допустить, что для каждого объекта можно добавлять свой метод, то мы не нуждаемся в типах вообще.
А одинаковая совокупность добавленных к объекту методов не порождает общности этих объектов, могущей быть при этом названной типом? Кто-то может в них и не нуждаться, но по факту они будут существовать, нес па?
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, Курилка, Вы писали:
К>>Т.е. "во всех операндах должен быть определён" тип с методом "+" ?
FDS>Совершенно не обязательно. Если допустить, что для каждого объекта можно добавлять свой метод, то мы не нуждаемся в типах вообще.
В таком случае тип будет отождествлен с совокупностью методов, добавленных к объекту. Это динамическая типизация, но тем не менее, типизация.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, Temoto, Вы писали:
FDS>>>Полиморфизмы можно и без типов сделать
T>>Можно поподробнее? Как компилятор узнает какую именно реализацию оператора сложения подставить, если ему неизвестен тип операндов?
FDS>У вас во всех операндах должен быть определён один и тот же метод "+", который хранится в словаре методов. Компилятор, точнее интерпретатор, посмотрит на то, что все методы в объектах одинаковые, и применит их соотв. образом.
Хм.. допустим все значения являются объектами (в смысле словарями имя:метод), хотя это уже очень сильное допущение, в изначальном вопросе его не было.
Допустим также, что в каких-то двух объектах a и b есть метод "+". Какую сигнатуру имеет этот метод?
Допустим, что a это число 5, а b это число 3. Очевидно, что в этих объектах "методы + одинаковые". Какова последовательность действий (логических выводов?) компилятора чтобы применить реализацию plus_int_int :: Int -> Int -> Int?
В конце концов всё сведется к вызову какой-то низкоуровневой функции, которая ожидает конкретные аргументы. Пусть даже это будет x86 инструкция ADD, суть тут не меняется.
Вопрос был не про то, что полиморфизм можно представить/записать, а про то, как его диспатчить, то есть собственно вызывать конкретные реализации.
T>>Расскажите, пожалуйста, зачем нужны системы типов. Какие задачи они решают?
T>>Например, очевидно, что типы позволяют производить проверки корректности кода, диспатчить полиморфизмы типа оператора сложения (хотя здесь я не уверен).
FDS>Полиморфизмы можно и без типов сделать
FDS>Ну, вообще говоря они позволяют использовать код повторно при наследовании (доопределение методов и полей, полиморфизм), приводить типы вверх по дереву и унифицированно обращаться с ними, дают компилятору информацию о том как именно хранить и что хранить в объекте (иначе каждый объект должен быть словарём переменных), ограничивать область видимости методов (икапсуляция, абстрагирование), предоставлять стандартные интерфейсы без реализации
Хранение — бесспорно, спасибо.
Ограничение видимости... вот в питоне, например, ограничение *видимости* делается как раз без типов. Когда метод называется с двух подчёркиваний, его ровно с таким именем "снаружи" не видно. Его видно иначе, как Class__name, но это детали. В гипотетическом языке можно сделать синтаксической ошибкой x.__foo() и не ошибкой this.__foo(); если при этом this будет зарезервированным словом, и любому объекту можно добавить метод __foo "на лету" — получается ограничение без типов.
Ещё интересно подробнее про "приводить типы вверх по дереву и унифицированно обращаться с ними". Система типов позволяет приводить типы вверх по дереву. Честно говоря, я не понял фразу.
И про это тоже: "предоставлять стандартные интерфейсы без реализации". В гипотетическом языке каждый объект это словарь имя:метод (хороший пример — Javascript). Вы вызываете метод length, чтобы получить длину объекта dreams (допустим это список снов). Не совсем понятно, имеет ли тут место "предоставление интерфейсов" или нет. Вроде всё работает, в документации описан интерфейс: length :: Object -> Int, однако назначать для этого специальный тип объекту dreams не нужно.
T>Расскажите, пожалуйста, зачем нужны системы типов. Какие задачи они решают?
Попробую подытожить.
Типы позволяют:
производить проверку корректности кода,
диспатчить полиморфизмы,
выбирать способ представления данных в памяти.
Было мнение, что диспатчить полиморфизм можно и без типов, но это не противоречит второму пункту. Остальное тоже можно делать и в рамках одного типа, но с разветвлённой системой — намного более эффективно.
Пока это всё, к сожалению, многие светлые умы обходят вопрос стороной.
Здравствуйте, deniok, Вы писали:
D>А одинаковая совокупность добавленных к объекту методов не порождает общности этих объектов, могущей быть при этом названной типом? Кто-то может в них и не нуждаться, но по факту они будут существовать, нес па?
Как вы правильно сказали, наоборот, порождает, а вовсе не требует эту самую систему типов
Здравствуйте, samius, Вы писали:
S>В таком случае тип будет отождествлен с совокупностью методов, добавленных к объекту. Это динамическая типизация, но тем не менее, типизация.
Это не так.
1. Нам совершенно не нужно знать тип объекта и отождествлять объект с его типом для того, чтобы реализовать полиморфизм некоторой операции
2. Тип может задаваться объектом и иметь только один экземпляр — говорить при этом о системе типов абсурдно.
Поэтому мы всегда можем сказать, что типизация для полиморфизма нам не нужна, хотя в общем и целом в реальной программе так или иначе некоторые вещи можно будет выделить как типы, что, однако, не означает, что сам язык будет содержать такое понятие как "тип".
Здравствуйте, Temoto, Вы писали:
FDS>>Ну, вообще говоря они позволяют использовать код повторно при наследовании (доопределение методов и полей, полиморфизм), приводить типы вверх по дереву и унифицированно обращаться с ними, дают компилятору информацию о том как именно хранить и что хранить в объекте (иначе каждый объект должен быть словарём переменных), ограничивать область видимости методов (икапсуляция, абстрагирование), предоставлять стандартные интерфейсы без реализации
T>Хранение — бесспорно, спасибо.
Здесь есть варианты. Например, процедурные типы данных. Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных. Тип процедуры не то же самое, что тип данных, тем не менее процедуры позволяют хранить данные в форме отличном от "словаря переменных".
T>Ещё интересно подробнее про "приводить типы вверх по дереву и унифицированно обращаться с ними". Система типов позволяет приводить типы вверх по дереву. Честно говоря, я не понял фразу.
Речь идет о дереве наследования в традиционных ООП языках, т.е. интерпретация производных типов в качестве базовых. Кроме приведения upcast существует и приведение downcast. Система типов в случае downcast-а должна контроллировать корректность приведения.
T>И про это тоже: "предоставлять стандартные интерфейсы без реализации". В гипотетическом языке каждый объект это словарь имя:метод (хороший пример — Javascript). Вы вызываете метод length, чтобы получить длину объекта dreams (допустим это список снов). Не совсем понятно, имеет ли тут место "предоставление интерфейсов" или нет. Вроде всё работает, в документации описан интерфейс: length :: Object -> Int, однако назначать для этого специальный тип объекту dreams не нужно.
Здесь опять-таки слово интерфейс употребляется в контексте традиционных ООП языков. Аналог в хаскеле — класс типов, т.е. декларация того, что для некоторых типов должна существовать совокупность методов.
Здравствуйте, Temoto, Вы писали:
T>Хм.. допустим все значения являются объектами (в смысле словарями имя:метод), хотя это уже очень сильное допущение, в изначальном вопросе его не было.
В изначальном вопросе вообще ничего не было, я лишь просто абстрактно ответил на то, что такое возможно без типов, что не значит, что хотя бы один язык так делает
T>Допустим также, что в каких-то двух объектах a и b есть метод "+". Какую сигнатуру имеет этот метод?
Оператор плюс, насколько мне помнится, всегда был бинарным, сигнатуру имеет, соответственно, в виде двух объектов (любого типа, так как типизации у нас нет)
T>Допустим, что a это число 5, а b это число 3. Очевидно, что в этих объектах "методы + одинаковые". Какова последовательность действий (логических выводов?) компилятора чтобы применить реализацию plus_int_int :: Int -> Int -> Int?
Я думаю правильней object * object -> object
a и b есть два параметра, результат является вызовом функции, представляющей реализацию оператора "+"
Например,
a и b — числа
Тогда им соответствует функция сложения именно двух чисел (например, ассемблерная вставка или побитовое сложение соответствующей области памяти )
a и b — строки
Тогда им соответствует функция конкантенации, т.е. совмещения двух областей памяти в одну последовательно.
Интерпретатор ищет функцию "+", подставляет a и b в неё и получает некий результирующий объект. Всё (при динамической типизации).
Я что-то упустил?
T>В конце концов всё сведется к вызову какой-то низкоуровневой функции, которая ожидает конкретные аргументы. Пусть даже это будет x86 инструкция ADD, суть тут не меняется.
И?
T>Вопрос был не про то, что полиморфизм можно представить/записать, а про то, как его диспатчить, то есть собственно вызывать конкретные реализации.
Здравствуйте, FDSC, Вы писали:
T>>Допустим, что a это число 5, а b это число 3. Очевидно, что в этих объектах "методы + одинаковые". Какова последовательность действий (логических выводов?) компилятора чтобы применить реализацию plus_int_int :: Int -> Int -> Int?
FDS>Я думаю правильней object * object -> object
FDS>a и b есть два параметра, результат является вызовом функции, представляющей реализацию оператора "+" FDS>Например, FDS>a и b — числа FDS>Тогда им соответствует функция сложения именно двух чисел (например, ассемблерная вставка или побитовое сложение соответствующей области памяти ) FDS>a и b — строки FDS>Тогда им соответствует функция конкантенации, т.е. совмещения двух областей памяти в одну последовательно.
И чем же здесь являются понятия "числа" и "строки"?
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Ни чем. Я не считаю это за определение.
FDS>Ну а я не считаю за определение ваше определение. И?
Тогда мы ни о чем не договоримся.
Кстати, я использую общепринятые определения, а не выдумываю их.
FDS>Полиморфизм не обязан привязываться к типам и может не оперировать такими понятиями как "тип".
Здравствуйте, Temoto, Вы писали:
T>Ограничение видимости... вот в питоне, например, ограничение *видимости* делается как раз без типов. Когда метод называется с двух подчёркиваний, его ровно с таким именем "снаружи" не видно. Его видно иначе, как Class__name, но это детали. В гипотетическом языке можно сделать синтаксической ошибкой x.__foo() и не ошибкой this.__foo(); если при этом this будет зарезервированным словом, и любому объекту можно добавить метод __foo "на лету" — получается ограничение без типов.
Уязвили, если считать типы именно так, как я их считал, когда писал сообщение . Вы правы
T>Ещё интересно подробнее про "приводить типы вверх по дереву и унифицированно обращаться с ними". Система типов позволяет приводить типы вверх по дереву. Честно говоря, я не понял фразу.
Я в том смысле, что если у нас есть геометрические фигуры и все эти фигуры нужно переместить на какое-то расстояние, то их всех можно привести к базовому классу с реализацией метода move и работать именно с этими объектами ни о чём не задумываясь, хотя при этом каждый из них не потеряет своей индивидуальности.
Хотя, конечно, здесь можно сказать, что мы можем просто добавить в каждый объект метод move и системы типов не нужно , но тут всё же базовый тип сам собой появляется — все объекты, имеющие метод move с данной сигнатурой.
T>И про это тоже: "предоставлять стандартные интерфейсы без реализации". В гипотетическом языке каждый объект это словарь имя:метод (хороший пример — Javascript). Вы вызываете метод length, чтобы получить длину объекта dreams (допустим это список снов). Не совсем понятно, имеет ли тут место "предоставление интерфейсов" или нет. Вроде всё работает, в документации описан интерфейс: length :: Object -> Int, однако назначать для этого специальный тип объекту dreams не нужно.
Мда, я, кажется, вырыл себе терминологическую яму...
Я имел в виду то, что все объекты с заданным интерфейсом в некотором смысле являются объектами одного типа и мы этот тип требуем, т.е. описатель типа декларирует что именно должно предоставлятся и как. И если, например, при десериализации объекта без описателя типа мы не можем понять, удовлетворяет ли объект интерфейсу, то если тип описан, то по этому описателю типа мы поймём, если сохранённый объект какой-то не такой, иначе — поймём только когда программа будет неправильно работать — то бишь речь идёт про проверку корректности при взаимодействии разных модулей, а не при компиляции.
Здравствуйте, samius, Вы писали:
FDS>>a и b есть два параметра, результат является вызовом функции, представляющей реализацию оператора "+" FDS>>Например, FDS>>a и b — числа FDS>>Тогда им соответствует функция сложения именно двух чисел (например, ассемблерная вставка или побитовое сложение соответствующей области памяти ) FDS>>a и b — строки FDS>>Тогда им соответствует функция конкантенации, т.е. совмещения двух областей памяти в одну последовательно.
S>И чем же здесь являются понятия "числа" и "строки"?
Грубо говоря, именами типов, которые я использую для доходчивости. Что, вообще говоря, не говорит о том, что в реале операция порождает какие-либо типы (хотя требует объекты с наличествующей одинаковой операцией сложения). То бишь нам совершенно не важно знать типы объектов, чтобы работать с операцией "+", важно лишь знать наличие одинаково определённой такой операции.
Здравствуйте, samius, Вы писали:
FDS>>Ну а я не считаю за определение ваше определение. И? S>Тогда мы ни о чем не договоримся. S>Кстати, я использую общепринятые определения, а не выдумываю их.
И где же ссылка на стандарт? Кто эти определения признал общепринятыми?
FDS>>Полиморфизм не обязан привязываться к типам и может не оперировать такими понятиями как "тип".
S>http://en.wikipedia.org/wiki/Type_polymorphism
Ага, обратите внимание — полиморфизм ТИПОВ. А я про типы ни слова не говорил. Поищите другое определение, где не было бы слова "типы", но было бы слово "полиморфизм"
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>a и b есть два параметра, результат является вызовом функции, представляющей реализацию оператора "+" FDS>>>Например, FDS>>>a и b — числа FDS>>>Тогда им соответствует функция сложения именно двух чисел (например, ассемблерная вставка или побитовое сложение соответствующей области памяти ) FDS>>>a и b — строки FDS>>>Тогда им соответствует функция конкантенации, т.е. совмещения двух областей памяти в одну последовательно.
S>>И чем же здесь являются понятия "числа" и "строки"?
FDS>Грубо говоря, именами типов, которые я использую для доходчивости. Что, вообще говоря, не говорит о том, что в реале операция порождает какие-либо типы (хотя требует объекты с наличествующей одинаковой операцией сложения). То бишь нам совершенно не важно знать типы объектов, чтобы работать с операцией "+", важно лишь знать наличие одинаково определённой такой операции.
Ваше право называть это чем угодно, но по общепринятой классификации систем типов — это динамическая типизация.
Кстати, условие об одинаково определенной операции — совершенно необязательное условие для реализации ad-hoc полиморфизма.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Temoto, Вы писали:
FDS>>>Ну, вообще говоря они позволяют использовать код повторно при наследовании (доопределение методов и полей, полиморфизм), приводить типы вверх по дереву и унифицированно обращаться с ними, дают компилятору информацию о том как именно хранить и что хранить в объекте (иначе каждый объект должен быть словарём переменных), ограничивать область видимости методов (икапсуляция, абстрагирование), предоставлять стандартные интерфейсы без реализации
T>>Хранение — бесспорно, спасибо. S>Здесь есть варианты. Например, процедурные типы данных. Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных.
Ну почему же, процедура имеет адрес, значит компилятор знает, сколько памяти под неё выделять, когда хранится указатель на неё.
Кроме этого, компилятор так же по типу процедуры определяет сколько места в стеке занимают данные.
S> Тип процедуры не то же самое, что тип данных, тем не менее процедуры позволяют хранить данные в форме отличном от "словаря переменных".
В свою очередь это один из подвидов полиморфизма типов.
FDS>
FDS>взаимозаменяемость объектов с одинаковым интерфейсом.
FDS>В этой строке нет ни слова о классах — только об интерфейсах.
А кто говорил о классах?
FDS>Если вам так больше будет нравится, можем говорить о перегрузке операторов, а не полиморфизме — хотя суть останется одна и та же.
Перегрузка операторов — частный случай полиморфизма типов.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>В таком случае тип будет отождествлен с совокупностью методов, добавленных к объекту. Это динамическая типизация, но тем не менее, типизация.
FDS>Это не так. FDS>1. Нам совершенно не нужно знать тип объекта и отождествлять объект с его типом для того, чтобы реализовать полиморфизм некоторой операции
Это верно в общем случае. Но для ad-hoc полиморфизма тип — обязательное явление.
FDS>2. Тип может задаваться объектом и иметь только один экземпляр — говорить при этом о системе типов абсурдно.
Абсудрно говорить о системе типов в привязке к количеству экземпляров.
Здравствуйте, samius, Вы писали:
S>Ваше право называть это чем угодно, но по общепринятой классификации систем типов — это динамическая типизация.
У меня есть два объекта — a и b, у них есть только одна совпадающая операция — операция сложения: какой тип у этих объектов по общепринятой классификации?
S>Кстати, условие об одинаково определенной операции — совершенно необязательное условие для реализации ad-hoc полиморфизма.
А если конкретнее, как это сделать без одинаково определённой операции?
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Ваше право называть это чем угодно, но по общепринятой классификации систем типов — это динамическая типизация.
FDS>У меня есть два объекта — a и b, у них есть только одна совпадающая операция — операция сложения: какой тип у этих объектов по общепринятой классификации?
"Объекты, которые можно складывать"
S>>Кстати, условие об одинаково определенной операции — совершенно необязательное условие для реализации ad-hoc полиморфизма.
FDS>А если конкретнее, как это сделать без одинаково определённой операции?
Пример:
сигнатура оператора сложения со строкой в C# имеет тип
(+) :: String -> Object -> String
за счет того что можно получить строковое представление любого объекта.
Здравствуйте, samius, Вы писали:
S>>>В таком случае тип будет отождествлен с совокупностью методов, добавленных к объекту. Это динамическая типизация, но тем не менее, типизация.
FDS>>Это не так. FDS>>1. Нам совершенно не нужно знать тип объекта и отождествлять объект с его типом для того, чтобы реализовать полиморфизм некоторой операции S>Это верно в общем случае. Но для ad-hoc полиморфизма тип — обязательное явление.
Если я правильно понимаю, ad-hoc полиморфизм и есть перегрузка операторов (кстати, где здесь слово "тип") и типы там совершенно не нужны. О чём уже писал. Или вы имеете в виду какое-то моё упущение?
FDS>>2. Тип может задаваться объектом и иметь только один экземпляр — говорить при этом о системе типов абсурдно. S>Абсудрно говорить о системе типов в привязке к количеству экземпляров.
Не абсурдно. Т.к. если у нас тип задаётся объектом, то использование самого понятия тип становится абсурдным. Так же как использование понятия "список" становится абсурдным, когда мы постоянно говорим о списке из одного объекта — легче сразу говорить об этом объекте, список не нужен.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Здесь есть варианты. Например, процедурные типы данных. Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных.
FDS>Ну почему же, процедура имеет адрес, значит компилятор знает, сколько памяти под неё выделять, когда хранится указатель на неё.
Из адреса не выводится объем памяти )))
FDS>Кроме этого, компилятор так же по типу процедуры определяет сколько места в стеке занимают данные.
Это не факт. Процедуры могут иметь один тип, но разные реализации.
S>> Тип процедуры не то же самое, что тип данных, тем не менее процедуры позволяют хранить данные в форме отличном от "словаря переменных".
FDS>Это как? Я не понял
Это когда вместо типа данных возвращается процедура, которая в свою очередь вернет данные при определенных обстоятельствах.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
S>>>Ваше право называть это чем угодно, но по общепринятой классификации систем типов — это динамическая типизация.
FDS>>У меня есть два объекта — a и b, у них есть только одна совпадающая операция — операция сложения: какой тип у этих объектов по общепринятой классификации?
S>"Объекты, которые можно складывать"
И кто же определил такой тип? Или по-вашему достаточно того, чтобы он фактически был, а синтаксическое определение и явное использование понятия "тип" не обязательно?
S>>>Кстати, условие об одинаково определенной операции — совершенно необязательное условие для реализации ad-hoc полиморфизма.
FDS>>А если конкретнее, как это сделать без одинаково определённой операции?
S>Пример: S>сигнатура оператора сложения со строкой в C# имеет тип S>(+) :: String -> Object -> String S>за счет того что можно получить строковое представление любого объекта.
Такой операции не может быть, если у нас нет явно объявленных типов, т.к. в таком случае будет непонятно, какую из функций сложения вызывать
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>1. Нам совершенно не нужно знать тип объекта и отождествлять объект с его типом для того, чтобы реализовать полиморфизм некоторой операции S>>Это верно в общем случае. Но для ad-hoc полиморфизма тип — обязательное явление.
FDS>Если я правильно понимаю, ad-hoc полиморфизм и есть перегрузка операторов (кстати, где здесь слово "тип") и типы там совершенно не нужны. О чём уже писал. Или вы имеете в виду какое-то моё упущение?
FDS>>>2. Тип может задаваться объектом и иметь только один экземпляр — говорить при этом о системе типов абсурдно. S>>Абсудрно говорить о системе типов в привязке к количеству экземпляров.
FDS>Не абсурдно. Т.к. если у нас тип задаётся объектом, то использование самого понятия тип становится абсурдным. Так же как использование понятия "список" становится абсурдным, когда мы постоянно говорим о списке из одного объекта — легче сразу говорить об этом объекте, список не нужен.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, samius, Вы писали:
S>>Исходя из определения полиморфизма — это вряд ли.
AVK>Хм. А как тогда трактовать статический полиморфизм ввиде перегрузки функций по количеству аргументов? Вроде бы в этом случае типы не нужны, нет?
Точно, в этом случае не нужны.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, samius, Вы писали:
S>>Исходя из определения полиморфизма — это вряд ли.
AVK>Хм. А как тогда трактовать статический полиморфизм ввиде перегрузки функций по количеству аргументов? Вроде бы в этом случае типы не нужны, нет?
Это вопрос трактовки термина "тип". Если понимать его как способ классификации имеющихся сущностей, то разделение по арности — тоже род типизации. Типы же не обязательно строго зашиты; мы можем приписывать их для своих нужд. Главное, чтобы от этого польза была.
Здравствуйте, Temoto, Вы писали:
T>Привет.
T>Расскажите, пожалуйста, зачем нужны системы типов. Какие задачи они решают? T>Например, очевидно, что типы позволяют производить проверки корректности кода, диспатчить полиморфизмы типа оператора сложения (хотя здесь я не уверен).
Системы типов — дисциплина программирования, проверка техническими средствами на разных этапах разработки. Но актуально в отдельных областях, требующих минимальной зависимости от человеческого фактора.
В инновационных проектах (особенно инет), которые постоянно меняются и развиваются, когда нужны быстрые решения — языки со слабой типизацией. Phyton, PHP, Ruby и etc.
В суровых промышленных проектах, с реальным временем и прочими удовольствиями — ASM/C/C++.
Ну и золотая середина — конкурентные С# и Java. Это бизнес, банки, госуправление.
В больших проектах, в зависимости от задач пригодно всё, что позволяет решать конкретные задачи и подзадачи.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>У меня есть два объекта — a и b, у них есть только одна совпадающая операция — операция сложения: какой тип у этих объектов по общепринятой классификации?
S>>"Объекты, которые можно складывать"
FDS>И кто же определил такой тип? Или по-вашему достаточно того, чтобы он фактически был, а синтаксическое определение и явное использование понятия "тип" не обязательно?
Нет, не обязательно. Существует толпа языков, не использующих тип явно, в отличии от языков, в которых бы не было типа совсем.
S>>>>Кстати, условие об одинаково определенной операции — совершенно необязательное условие для реализации ad-hoc полиморфизма.
FDS>>>А если конкретнее, как это сделать без одинаково определённой операции?
S>>Пример: S>>сигнатура оператора сложения со строкой в C# имеет тип S>>(+) :: String -> Object -> String S>>за счет того что можно получить строковое представление любого объекта.
FDS>Такой операции не может быть, если у нас нет явно объявленных типов, т.к. в таком случае будет непонятно, какую из функций сложения вызывать
В таком случае мне не понятно, что Вы имеет в виду под перегрузкой операторов вообще.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
S>>>Здесь есть варианты. Например, процедурные типы данных. Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных.
FDS>>Ну почему же, процедура имеет адрес, значит компилятор знает, сколько памяти под неё выделять, когда хранится указатель на неё. S>Из адреса не выводится объем памяти )))
Из адреса выводится объём памяти на указатель, так же, как и для любого другого массива данных.
FDS>>Кроме этого, компилятор так же по типу процедуры определяет сколько места в стеке занимают данные. S>Это не факт. Процедуры могут иметь один тип, но разные реализации.
Место в стеке, используемое для передачи параметров функции, а так же число, стоящее как операнд в команде RET для освобождения этой памяти, однозначно определяется сигнатурой функции и соглашением о её вызове.
S>Это когда вместо типа данных возвращается процедура, которая в свою очередь вернет данные при определенных обстоятельствах.
В данном случае компилятор знает, что данные хранятся как процедура — а больше ему и не нужно. Я, признаться, ни разу не видел, чтобы при объявленном типе String прямо туда можно было бы запихнуть процедуру, а значит компилятор должен знать о том, что там хранится не сама строка, а процедура, т.е. имеет информацию о том, что эта процедура есть, нужно хранить указатель на неё, знает, как эту процедуру вызвать. Таким образом, объявляя процедуру как способ получения данных мы всё равно сообщаем компилятору некоторую информацию о способе хранения данных и их получения (точнее, о том, что данные выражаются в адресе функции и факте её вызова).
Здравствуйте, samius, Вы писали:
S>>>"Объекты, которые можно складывать" FDS>>И кто же определил такой тип? Или по-вашему достаточно того, чтобы он фактически был, а синтаксическое определение и явное использование понятия "тип" не обязательно?
S>Нет, не обязательно. Существует толпа языков, не использующих тип явно, в отличии от языков, в которых бы не было типа совсем.
Т.е. это означает, что объект в этой толпе языков имеет множество типов вне одной ветки дерева, а так же информация об этом неявно типе где-то хранится, или нет?
FDS>>Такой операции не может быть, если у нас нет явно объявленных типов, т.к. в таком случае будет непонятно, какую из функций сложения вызывать S>В таком случае мне не понятно, что Вы имеет в виду под перегрузкой операторов вообще.
Я имею в виду, что для каждого объекта я могу задать свою операцию сложения, которая будет обладать одинаковым синтаксисом и именем для всех объектов, где операция задана, но работать в них по разному.
Здравствуйте, TimurSPB, Вы писали:
TSP>В инновационных проектах (особенно инет), которые постоянно меняются и развиваются, когда нужны быстрые решения — языки со слабой типизацией. Phyton, PHP, Ruby и etc.
Здравствуйте, deniok, Вы писали:
AVK>>Хм. А как тогда трактовать статический полиморфизм ввиде перегрузки функций по количеству аргументов? Вроде бы в этом случае типы не нужны, нет?
D>Это вопрос трактовки термина "тип". Если понимать его как способ классификации имеющихся сущностей, то разделение по арности — тоже род типизации.
Ну я понимаю, что презерватив и на глобус натянуть можно. Только это уже чистая софистика. Тип в контексте разговора должен быть чем то реально существующим, а не голой абстракцией.
Здравствуйте, FDSC, Вы писали:
FDS>>>Ну почему же, процедура имеет адрес, значит компилятор знает, сколько памяти под неё выделять, когда хранится указатель на неё. S>>Из адреса не выводится объем памяти )))
FDS>Из адреса выводится объём памяти на указатель, так же, как и для любого другого массива данных.
Что бы это значило?
FDS>>>Кроме этого, компилятор так же по типу процедуры определяет сколько места в стеке занимают данные. S>>Это не факт. Процедуры могут иметь один тип, но разные реализации.
FDS>Место в стеке, используемое для передачи параметров функции, а так же число, стоящее как операнд в команде RET для освобождения этой памяти, однозначно определяется сигнатурой функции и соглашением о её вызове.
Тем не менее две функции одной сигнатуры и соглашения о вызове могут иметь разные реализации, соответсвенно по-разному использовать стек внутри себя. Я не понимаю к чему все это, тип функции не определяет объем памяти, используемой функцией.
S>>Это когда вместо типа данных возвращается процедура, которая в свою очередь вернет данные при определенных обстоятельствах.
FDS>В данном случае компилятор знает, что данные хранятся как процедура — а больше ему и не нужно.
Компилятор об этом может и не знать
FDS>Я, признаться, ни разу не видел, чтобы при объявленном типе String прямо туда можно было бы запихнуть процедуру, а значит компилятор должен знать о том, что там хранится не сама строка, а процедура, т.е. имеет информацию о том, что эта процедура есть, нужно хранить указатель на неё, знает, как эту процедуру вызвать.
Прямо туда — это куда?
FDS>Таким образом, объявляя процедуру как способ получения данных мы всё равно сообщаем компилятору некоторую информацию о способе хранения данных и их получения (точнее, о том, что данные выражаются в адресе функции и факте её вызова).
О способе хранения — нет. О способе их получения — не факт. Эта информация может быть получена динамически.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, FDSC, Вы писали:
FDS>>В этой строке нет ни слова о классах — только об интерфейсах.
AVK>Хм, а некий известный заранее интерфейс может не являться типом?
Хм. Хм. Хмммм...
Скажем так: не обязательно, что этот интерфейс как-то отмечен и имеет название (см. спор про операцию "+"), следовательно, говорить о типе можно примерно так же, как говорить о конечном автомате в программе, где есть парсинг, который можно сделать путём объявления конечного автомата.
То бишь математически тип конечно есть, но фактически этот тип уже никому не нужен — он не помечается и не объявляется и сам термин "тип" можно не использовать.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>И кто же определил такой тип? Или по-вашему достаточно того, чтобы он фактически был, а синтаксическое определение и явное использование понятия "тип" не обязательно?
S>>Нет, не обязательно. Существует толпа языков, не использующих тип явно, в отличии от языков, в которых бы не было типа совсем.
FDS>Т.е. это означает, что объект в этой толпе языков имеет множество типов вне одной ветки дерева, а так же информация об этом неявно типе где-то хранится, или нет?
Нет, не означает
S>>В таком случае мне не понятно, что Вы имеет в виду под перегрузкой операторов вообще.
FDS>Я имею в виду, что для каждого объекта я могу задать свою операцию сложения, которая будет обладать одинаковым синтаксисом и именем для всех объектов, где операция задана, но работать в них по разному.
Тогда операция сложения может задаваться лишь типом (ассоциацией с процедурой сложения) первого аргумента. Задание этой операции у второго аргумента не обязательно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, deniok, Вы писали:
AVK>>>Хм. А как тогда трактовать статический полиморфизм ввиде перегрузки функций по количеству аргументов? Вроде бы в этом случае типы не нужны, нет?
D>>Это вопрос трактовки термина "тип". Если понимать его как способ классификации имеющихся сущностей, то разделение по арности — тоже род типизации.
AVK>Ну я понимаю, что презерватив и на глобус натянуть можно. Только это уже чистая софистика. Тип в контексте разговора должен быть чем то реально существующим, а не голой абстракцией.
мне показалось, что вы говорите именно о голой абстракции — ведь интерфейс объекта может быть задан неявно — просто возможностью наличия или отсутствия некоторой операции (операции сложения, например)
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, deniok, Вы писали:
AVK>>>>Хм. А как тогда трактовать статический полиморфизм ввиде перегрузки функций по количеству аргументов? Вроде бы в этом случае типы не нужны, нет?
D>>>Это вопрос трактовки термина "тип". Если понимать его как способ классификации имеющихся сущностей, то разделение по арности — тоже род типизации.
AVK>>Ну я понимаю, что презерватив и на глобус натянуть можно. Только это уже чистая софистика. Тип в контексте разговора должен быть чем то реально существующим, а не голой абстракцией.
FDS>В этом сообщении http://rsdn.ru/forum/philosophy/3664919.1.aspx
мне показалось, что вы говорите именно о голой абстракции — ведь интерфейс объекта может быть задан неявно — просто возможностью наличия или отсутствия некоторой операции (операции сложения, например)
Т.е. по-твоему duck typing не является типизацией?
Здравствуйте, samius, Вы писали:
FDS>>Из адреса выводится объём памяти на указатель, так же, как и для любого другого массива данных. S>Что бы это значило?
Это значит, что мы определяем объём памяти, который должен быть использован для хранения этого указателя, до бишь делаем примерно то же, что и когда декларируем поле int.
S>Тем не менее две функции одной сигнатуры и соглашения о вызове могут иметь разные реализации, соответсвенно по-разному использовать стек внутри себя. Я не понимаю к чему все это, тип функции не определяет объем памяти, используемой функцией.
Это к тому, что тип функции и её сигнатура есть обязательные вещи для транслятора — иначе он не сможет правильно вызвать соответствующую функцию и правильно передать туда параметры. Поэтому тип функции ничуть не меньше говорит компилятору о том, как хранить определённые данные (аргументы функции), чем, скажем, объявление полей структуры.
FDS>>Я, признаться, ни разу не видел, чтобы при объявленном типе String прямо туда можно было бы запихнуть процедуру, а значит компилятор должен знать о том, что там хранится не сама строка, а процедура, т.е. имеет информацию о том, что эта процедура есть, нужно хранить указатель на неё, знает, как эту процедуру вызвать.
S>Прямо туда — это куда?
В поле типа String. Всегда вместо этого объявляется делегат, интерфейс или объект, приводимый к String
FDS>>Таким образом, объявляя процедуру как способ получения данных мы всё равно сообщаем компилятору некоторую информацию о способе хранения данных и их получения (точнее, о том, что данные выражаются в адресе функции и факте её вызова). S>О способе хранения — нет. О способе их получения — не факт. Эта информация может быть получена динамически.
О способе хранения — да. См. выше про хранение аргументов функции и указателя на неё.
О способе получения — да, так как мы должны вызвать функцию и отвести место, куда будем получать результат (если результат сложный — то место под указатель на результат)
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, deniok, Вы писали:
AVK>>>Хм. А как тогда трактовать статический полиморфизм ввиде перегрузки функций по количеству аргументов? Вроде бы в этом случае типы не нужны, нет?
D>>Это вопрос трактовки термина "тип". Если понимать его как способ классификации имеющихся сущностей, то разделение по арности — тоже род типизации.
AVK>Ну я понимаю, что презерватив и на глобус натянуть можно. Только это уже чистая софистика. Тип в контексте разговора должен быть чем то реально существующим, а не голой абстракцией.
Для подсистемы диспетчеризации отношение таких сущностей (скажем,f(a,b) и f(a,b,c)) к разным типам — самая реальная реальность. А то что программисту не надо тут писать типы, так и в Хаскелле их тоже можно почти нигде не писать — их компилятор выводит для проверки. Я не вижу здесь принципиальной разницы.
мне показалось, что вы говорите именно о голой абстракции — ведь интерфейс объекта может быть задан неявно — просто возможностью наличия или отсутствия некоторой операции (операции сложения, например)
К>Т.е. по-твоему duck typing не является типизацией?
Не совсем: если при этом речь идёт об объявленном типе — то является типизацией, а если просто идёт проверка на наличие и совместимость некоторых операций, то нет, тогда это просто проверка. Так же, как не является проверкой типа операция проверки на чётность числа if (a mod 2)ф [для особо аккуратных if (a and 1 == 0)], но от неё вполне может зависеть ветка исполнения программы
Здравствуйте, deniok, Вы писали:
D>Для подсистемы диспетчеризации отношение таких сущностей (скажем,f(a,b) и f(a,b,c)) к разным типам — самая реальная реальность.
Еще раз — при желании презерватив можно натянуть на глобус. Но по факту говорить о типе функций для языка, у которого вообще функционального типа может не быть, глупо.
D> А то что программисту не надо тут писать типы, так и в Хаскелле их тоже можно почти нигде не писать — их компилятор выводит для проверки.
Нельзя писать != отсутствуют. Потому что как только они несовпадут, к примеру, ты сразу о существовании типов в Хаскеле узнаешь.
Здравствуйте, samius, Вы писали:
FDS>>Т.е. это означает, что объект в этой толпе языков имеет множество типов вне одной ветки дерева, а так же информация об этом неявно типе где-то хранится, или нет?
S>Нет, не означает
Тогда я могу назвать операцией типизации конструкцию if a mod 2 then ?
S>>>В таком случае мне не понятно, что Вы имеет в виду под перегрузкой операторов вообще.
FDS>>Я имею в виду, что для каждого объекта я могу задать свою операцию сложения, которая будет обладать одинаковым синтаксисом и именем для всех объектов, где операция задана, но работать в них по разному.
S>Тогда операция сложения может задаваться лишь типом (ассоциацией с процедурой сложения) первого аргумента. Задание этой операции у второго аргумента не обязательно.
Тогда может оказаться, что операция сложения вылетит в связи с несовместимостью типов.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Тем не менее две функции одной сигнатуры и соглашения о вызове могут иметь разные реализации, соответсвенно по-разному использовать стек внутри себя. Я не понимаю к чему все это, тип функции не определяет объем памяти, используемой функцией.
FDS>Это к тому, что тип функции и её сигнатура есть обязательные вещи для транслятора — иначе он не сможет правильно вызвать соответствующую функцию и правильно передать туда параметры. Поэтому тип функции ничуть не меньше говорит компилятору о том, как хранить определённые данные (аргументы функции), чем, скажем, объявление полей структуры.
object*object -> object.
Много чего сказало это компилятору о том как хранить данные?
FDS>>>Я, признаться, ни разу не видел, чтобы при объявленном типе String прямо туда можно было бы запихнуть процедуру, а значит компилятор должен знать о том, что там хранится не сама строка, а процедура, т.е. имеет информацию о том, что эта процедура есть, нужно хранить указатель на неё, знает, как эту процедуру вызвать.
S>>Прямо туда — это куда?
FDS>В поле типа String. Всегда вместо этого объявляется делегат, интерфейс или объект, приводимый к String
Я тоже не встречал такого бреда — в поле типа String засунуть процедуру. Спишем это на позднее время
FDS>>>Таким образом, объявляя процедуру как способ получения данных мы всё равно сообщаем компилятору некоторую информацию о способе хранения данных и их получения (точнее, о том, что данные выражаются в адресе функции и факте её вызова). S>>О способе хранения — нет. О способе их получения — не факт. Эта информация может быть получена динамически.
FDS>О способе хранения — да. См. выше про хранение аргументов функции и указателя на неё.
Не исключаю что функция object*object -> object положит аргументы в словарь и вернет словарь. А может положить их в список и вернуть список, а может записать их в файл и вернуть хэндл файла. Так что сигнатура и соглашение не говорят ничего компилятору о способе хранения переданных данных.
FDS>О способе получения — да, так как мы должны вызвать функцию и отвести место, куда будем получать результат (если результат сложный — то место под указатель на результат)
мы должны вызвать функцию, чтобы получить данные обратно. Зачем об этой функции что-то знать компилятору?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, FDSC, Вы писали:
FDS>>Скажем так: не обязательно, что этот интерфейс как-то отмечен и имеет название (см. спор про операцию "+")
AVK>Ну ты же сам их назвал — строка, число.
Это я их назвал, но это не значит, что они объявлены специально как целое 32-битное число и т.п. То бишь для компилятора разница лишь в том, какие методы объявлены в этих объектах
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>Т.е. это означает, что объект в этой толпе языков имеет множество типов вне одной ветки дерева, а так же информация об этом неявно типе где-то хранится, или нет?
S>>Нет, не означает
FDS>Тогда я могу назвать операцией типизации конструкцию if a mod 2 then ?
Вы — можете. Уверен в этом теперь.
FDS>>>Я имею в виду, что для каждого объекта я могу задать свою операцию сложения, которая будет обладать одинаковым синтаксисом и именем для всех объектов, где операция задана, но работать в них по разному.
S>>Тогда операция сложения может задаваться лишь типом (ассоциацией с процедурой сложения) первого аргумента. Задание этой операции у второго аргумента не обязательно.
FDS>Тогда может оказаться, что операция сложения вылетит в связи с несовместимостью типов.
Иначе может оказаться что вылетит операция диспетчеризации метода сложения
Здравствуйте, FDSC, Вы писали:
FDS>Это я их назвал, но это не значит, что они объявлены специально как целое 32-битное число и т.п.
Если эти термины имеют какой то смысл в контексте языка (не реализации), то таки типы есть.
FDS> То бишь для компилятора разница лишь в том, какие методы объявлены в этих объектах
Все, как только компилятор знает про объявленные методы, сразу же имеем типы. Единственная возможность поиметь полиморфизм операторов без типов — язык, в котором методы привязываются к экземплярам в рантайме.
Здравствуйте, samius, Вы писали:
S>object*object -> object. S>Много чего сказало это компилятору о том как хранить данные?
Столько, сколько ему нужно. Это сказало компилятору, что нужно выделить 8 байт в стеке для аргументов и байта на результат (для 32-битной архитектуры)
FDS>>>>Я, признаться, ни разу не видел, чтобы при объявленном типе String прямо туда можно было бы запихнуть процедуру, а значит компилятор должен знать о том, что там хранится не сама строка, а процедура, т.е. имеет информацию о том, что эта процедура есть, нужно хранить указатель на неё, знает, как эту процедуру вызвать.
S>>>Прямо туда — это куда?
FDS>>В поле типа String. Всегда вместо этого объявляется делегат, интерфейс или объект, приводимый к String S>Я тоже не встречал такого бреда — в поле типа String засунуть процедуру. Спишем это на позднее время
Ну вот, а значит когда мы объявляем вызов функции, которая возвращает строку, то это не то же самое, что объявление строки
S>Не исключаю что функция object*object -> object положит аргументы в словарь и вернет словарь. А может положить их в список и вернуть список, а может записать их в файл и вернуть хэндл файла. Так что сигнатура и соглашение не говорят ничего компилятору о способе хранения переданных данных.
Говорят. Я уже писал, выше в этом сообщении и в предыдущем сообщении, но ты невнимательно прочитал.
Объявление функции object * object -> object говорит компилятору, что он делает приращение вершины стека на 2 указателя (8-мь или 16-ть байт, в зависимости от архитектуры), определяет место под результат в виде 1 указателя, ставит команду call на месте вызова функции и передаёт ей указатель на эту функцию. А если ты хочешь, чтобы в одной строчке программы сразу объявить как и что она делает и хранит, то ты многого хочешь. Достаточно того, что компилятор из этой строки узнал новую и необходимую для него информацию.
FDS>>О способе получения — да, так как мы должны вызвать функцию и отвести место, куда будем получать результат (если результат сложный — то место под указатель на результат) S>мы должны вызвать функцию, чтобы получить данные обратно. Зачем об этой функции что-то знать компилятору?
Чтобы её правильно вызвать, как ты понимаешь.
Здравствуйте, samius, Вы писали: FDS>>Тогда я могу назвать операцией типизации конструкцию if a mod 2 then ?
S>Вы — можете. Уверен в этом теперь.
И как же провести грань между одной условной веткой и другой, где так же определяется некоторое условие, без какой-либо явной процедуры получения имени или другого идентификатора типа?
S>Иначе может оказаться что вылетит операция диспетчеризации метода сложения
Так оно и должно быть, если мы говорим о строгой типизации, хоть и без типов .
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, FDSC, Вы писали:
FDS>>Это я их назвал, но это не значит, что они объявлены специально как целое 32-битное число и т.п.
AVK>Если эти термины имеют какой то смысл в контексте языка (не реализации), то таки типы есть.
А если не имеют? Грубо говоря, язык имеет стандартные наборы методов для int, String и decimal, но никак их не различает (т.е. я могу для decimal взять и определить метод print как-будто это String и будет у меня на экран выводится бессмысленные символы)
FDS>> То бишь для компилятора разница лишь в том, какие методы объявлены в этих объектах
AVK>Все, как только компилятор знает про объявленные методы, сразу же имеем типы. Единственная возможность поиметь полиморфизм операторов без типов — язык, в котором методы привязываются к экземплярам в рантайме.
Здравствуйте, FDSC, Вы писали:
AVK>>Если эти термины имеют какой то смысл в контексте языка (не реализации), то таки типы есть.
FDS>Грубо говоря, язык имеет стандартные наборы методов для int, String и decimal
Стандартный набор методов и есть тип.
FDS>Я о таком языке и говорю.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>object*object -> object. S>>Много чего сказало это компилятору о том как хранить данные?
FDS>Столько, сколько ему нужно. Это сказало компилятору, что нужно выделить 8 байт в стеке для аргументов и байта на результат (для 32-битной архитектуры)
А что это сказало компилятору о том, как процедура хранит переданные ей аргументы после вызова? Мы ведь все еще о процедурных типах данных здесь говорим, не так ли?
S>>>>Прямо туда — это куда?
FDS>>>В поле типа String. Всегда вместо этого объявляется делегат, интерфейс или объект, приводимый к String S>>Я тоже не встречал такого бреда — в поле типа String засунуть процедуру. Спишем это на позднее время
FDS>Ну вот, а значит когда мы объявляем вызов функции, которая возвращает строку, то это не то же самое, что объявление строки
Кто-то утверждал обратное?
S>>Не исключаю что функция object*object -> object положит аргументы в словарь и вернет словарь. А может положить их в список и вернуть список, а может записать их в файл и вернуть хэндл файла. Так что сигнатура и соглашение не говорят ничего компилятору о способе хранения переданных данных.
FDS>Говорят. Я уже писал, выше в этом сообщении и в предыдущем сообщении, но ты невнимательно прочитал. FDS>Объявление функции object * object -> object говорит компилятору, что он делает приращение вершины стека на 2 указателя (8-мь или 16-ть байт, в зависимости от архитектуры), определяет место под результат в виде 1 указателя, ставит команду call на месте вызова функции и передаёт ей указатель на эту функцию. А если ты хочешь, чтобы в одной строчке программы сразу объявить как и что она делает и хранит, то ты многого хочешь. Достаточно того, что компилятор из этой строки узнал новую и необходимую для него информацию.
Процедурные типы данных и соглашения о вызове метода не имеют ничего общего.
FDS>>>О способе получения — да, так как мы должны вызвать функцию и отвести место, куда будем получать результат (если результат сложный — то место под указатель на результат) S>>мы должны вызвать функцию, чтобы получить данные обратно. Зачем об этой функции что-то знать компилятору? FDS>Чтобы её правильно вызвать, как ты понимаешь.
Правильно вызвать — это одно, а то как хранит процедура переданные ей данные — это другое.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, AndrewVK, Вы писали:
FDS>>> То бишь для компилятора разница лишь в том, какие методы объявлены в этих объектах
AVK>>Все, как только компилятор знает про объявленные методы, сразу же имеем типы. Единственная возможность поиметь полиморфизм операторов без типов — язык, в котором методы привязываются к экземплярам в рантайме.
FDS>Я о таком языке и говорю.
T>>Хранение — бесспорно, спасибо. S>Здесь есть варианты. Например, процедурные типы данных. Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных. Тип процедуры не то же самое, что тип данных, тем не менее процедуры позволяют хранить данные в форме отличном от "словаря переменных".
Интересно, а разве с процедурой не проще, наоборот?
Имя (чтоб вычислить entry point позже) или сразу ссылка на начало кода, да список типов аргументов, нет?
T>>Ещё интересно подробнее про "приводить типы вверх по дереву и унифицированно обращаться с ними". Система типов позволяет приводить типы вверх по дереву. Честно говоря, я не понял фразу. S>Речь идет о дереве наследования в традиционных ООП языках, т.е. интерпретация производных типов в качестве базовых. Кроме приведения upcast существует и приведение downcast. Система типов в случае downcast-а должна контроллировать корректность приведения.
Да, но это все равно что: компьютеры решают все проблемы, которых до их изобретения не существовало. Нет системы типов — не нужно ходить по дереву. Тут вроде никакая проблема/задача не решается. Вот проверка корректности и с типами нужна, и без.
T>>И про это тоже: "предоставлять стандартные интерфейсы без реализации". В гипотетическом языке каждый объект это словарь имя:метод (хороший пример — Javascript). Вы вызываете метод length, чтобы получить длину объекта dreams (допустим это список снов). Не совсем понятно, имеет ли тут место "предоставление интерфейсов" или нет. Вроде всё работает, в документации описан интерфейс: length :: Object -> Int, однако назначать для этого специальный тип объекту dreams не нужно. S>Здесь опять-таки слово интерфейс употребляется в контексте традиционных ООП языков. Аналог в хаскеле — класс типов, т.е. декларация того, что для некоторых типов должна существовать совокупность методов.
Я понял в каком смысле слово "интерфейс", не понял в каком смысле система типов их "предоставляет" и привёл пример утиной типизации, когда интерфейс декларируется только в документации. Да, статическая проверка корректности затруднена. Не уверен, это ли FDSC имел в виду.
T>>Допустим также, что в каких-то двух объектах a и b есть метод "+". Какую сигнатуру имеет этот метод?
FDS>Оператор плюс, насколько мне помнится, всегда был бинарным, сигнатуру имеет, соответственно, в виде двух объектов (любого типа, так как типизации у нас нет)
T>>Допустим, что a это число 5, а b это число 3. Очевидно, что в этих объектах "методы + одинаковые". Какова последовательность действий (логических выводов?) компилятора чтобы применить реализацию plus_int_int :: Int -> Int -> Int?
FDS>Я думаю правильней object * object -> object
Речь не об интерфейсе полиморфичного оператора +, а о реализации оператора + для двух чисел. Например, x86 ADD. Она оперирует числами, а не объектами...
FDS>a и b есть два параметра, результат является вызовом функции, представляющей реализацию оператора "+" FDS>Например, FDS>a и b — числа FDS>Тогда им соответствует функция сложения именно двух чисел (например, ассемблерная вставка или побитовое сложение соответствующей области памяти ) FDS>a и b — строки FDS>Тогда им соответствует функция конкантенации, т.е. совмещения двух областей памяти в одну последовательно.
FDS>Интерпретатор ищет функцию "+", подставляет a и b в неё и получает некий результирующий объект. Всё (при динамической типизации). FDS>Я что-то упустил?
... и, соответственно, вопрос был в том как на основании двух одинаковых + :: Object -> Object -> Object компилятор узнает, что нужно подставить ADD, на какие ячейки памяти нужно ссылаться. Давайте попытаемся представить себе действия компилятора.
Дальше вы сказали, что компилятор видит, что методы одинаковые, и на основании этой одинаковости предпринимает какое-то решение (в этом заключается вопрос), на основании которого генерится код типа
Выход:
ADD d x y # где ADD это какая-то низкоуровневая функция, принимающая два числа, а x и y это числа из объектов a и b.
Вот объясните, что делает компилятор после обнаружения, что методы одинаковые, как получается результат?
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали: FDS>>>Тогда я могу назвать операцией типизации конструкцию if a mod 2 then ?
S>>Вы — можете. Уверен в этом теперь.
FDS>И как же провести грань между одной условной веткой и другой, где так же определяется некоторое условие, без какой-либо явной процедуры получения имени или другого идентификатора типа?
Когда я отвечал на это
FDS>>>Т.е. это означает, что объект в этой толпе языков имеет множество типов вне одной ветки дерева, а так же информация об этом неявно типе где-то хранится, или нет?
S>>Нет, не означает
Я подразумевал то, что информация о типе может быть у программиста в голове, и что компилятор/интерпретатор действительно не знает и не проверяет типы.
причем тут ветвление и проверка деления на 2 — у меня даже догадок нет.
S>>Иначе может оказаться что вылетит операция диспетчеризации метода сложения
FDS>Так оно и должно быть, если мы говорим о строгой типизации, хоть и без типов .
Ну да. В итоге получаем что наличие ассоциации с операцией сложения у двух операндов не обязательно.
Здравствуйте, Temoto, Вы писали:
T>>>Хранение — бесспорно, спасибо. S>>Здесь есть варианты. Например, процедурные типы данных. Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных. Тип процедуры не то же самое, что тип данных, тем не менее процедуры позволяют хранить данные в форме отличном от "словаря переменных".
T>Интересно, а разве с процедурой не проще, наоборот?
Менее эффективно, как правило — это да. Проще — не знаю. Что есть проще и для кого?!?!?
S>>Речь идет о дереве наследования в традиционных ООП языках, т.е. интерпретация производных типов в качестве базовых. Кроме приведения upcast существует и приведение downcast. Система типов в случае downcast-а должна контроллировать корректность приведения.
T>Да, но это все равно что: компьютеры решают все проблемы, которых до их изобретения не существовало. Нет системы типов — не нужно ходить по дереву. Тут вроде никакая проблема/задача не решается.
апкастами и даункастами проверка корректности и решается.
T>Вот проверка корректности и с типами нужна, и без.
Нужна-то нужна, но необходимой она является только для статически типизированных языков.
S>>Здесь опять-таки слово интерфейс употребляется в контексте традиционных ООП языков. Аналог в хаскеле — класс типов, т.е. декларация того, что для некоторых типов должна существовать совокупность методов.
T>Я понял в каком смысле слово "интерфейс", не понял в каком смысле система типов их "предоставляет" и привёл пример утиной типизации, когда интерфейс декларируется только в документации. Да, статическая проверка корректности затруднена. Не уверен, это ли FDSC имел в виду.
T>>>>Хранение — бесспорно, спасибо. S>>>Здесь есть варианты. Например, процедурные типы данных. Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных. Тип процедуры не то же самое, что тип данных, тем не менее процедуры позволяют хранить данные в форме отличном от "словаря переменных".
T>>Интересно, а разве с процедурой не проще, наоборот? S>Менее эффективно, как правило — это да. Проще — не знаю. Что есть проще и для кого?!?!?
Да, "проще" — не то слово.
Я имел в виду, что несмотря на то, что варианты есть, разве с процедурами не всё очевидно? Разве есть какие-то камни в хранении имени и списка параметров? Выглядит не сложнее, чем хранить значение, например, длинного числа.
Здравствуйте, Temoto, Вы писали:
T>>>>>Хранение — бесспорно, спасибо. S>>>>Здесь есть варианты. Например, процедурные типы данных. Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных. Тип процедуры не то же самое, что тип данных, тем не менее процедуры позволяют хранить данные в форме отличном от "словаря переменных".
T>>>Интересно, а разве с процедурой не проще, наоборот? S>>Менее эффективно, как правило — это да. Проще — не знаю. Что есть проще и для кого?!?!?
T>Да, "проще" — не то слово.
T>Я имел в виду, что несмотря на то, что варианты есть, разве с процедурами не всё очевидно? Разве есть какие-то камни в хранении имени и списка параметров? Выглядит не сложнее, чем хранить значение, например, длинного числа.
Не понимаю, что имеется в виду под хранением имени и списка параметров.
Я имел в виду нечто вроде определений cons отсюда, когда процедура используется вместо структуры данных и даже вместо чисел (см. Church numerals там же). Здесь хранятся не имена и списки параметров, а замыкания, либо представление параметров в виде произведения простых делителей... В этом примере определяющим способ хранения является не тип структуры данных, а именно способ представления, задаваемый совокупностью конструктора и селекторов.
Здравствуйте, samius, Вы писали:
S>Когда я отвечал на это
... S>Я подразумевал то, что информация о типе может быть у программиста в голове, и что компилятор/интерпретатор действительно не знает и не проверяет типы.
S>причем тут ветвление и проверка деления на 2 — у меня даже догадок нет.
Информация о типе, хранящаяся в голове программиста — это абстракция. Т.е. у компилятора, получается, системы типов технологически нет, соответственно и функции она никакой в языке не играет.
S>Ну да. В итоге получаем что наличие ассоциации с операцией сложения у двух операндов не обязательно.
При условии, что определён порядок применения этой операции.
Здравствуйте, Temoto, Вы писали:
FDS>>Я думаю правильней object * object -> object
T>Речь не об интерфейсе полиморфичного оператора +, а о реализации оператора + для двух чисел. Например, x86 ADD. Она оперирует числами, а не объектами...
Ну и? В чём сложность объявить такую операцию? Это просто функция сложения, которая будет вызвана именно для тех объектов, для которых определена именно функция сложения (она может быть базовой в компиляторе или выполнена на ассемблерных вставках)
T>... и, соответственно, вопрос был в том как на основании двух одинаковых + :: Object -> Object -> Object компилятор узнает, что нужно подставить ADD, на какие ячейки памяти нужно ссылаться. Давайте попытаемся представить себе действия компилятора.
1. Есть указатели на объекты a и b
2. В этих объектах хранятся данные объекта в двух возможных вариантах: а) сами данные объекта как первичного типа (секция неименованных данных) б) объекты-поля в словаре полей (секция именованных полей)
3. В этих объектах хранится словарь методов, которые принимают указатели на объекты и заранее известно для каждого метода, сколько указателей принимает, и сколько возвращает
Тогда
1. Компилятор находит объекты a и b как операнды оператора "+".
2. В зависимости от соглашения, допустм, сравнивает, имеют ли a и b методы "+" и если имеют, равны ли они (совместимы ли) или просто вызывает один из методов по заранее определённому соглашению (мне нравится первый вариант, но samius указал на возможность и второго)
3. Вызов метода происходит следующим образом: в него передаются два указателя на объект, сохраняется место для результата-объекта
4. Метод реализован так, что читает данные обоих аргументов-объектов из секции неименованных данных, сам метод знает, что они 32-разрядные и передаёт два 32-разрядных числа в операцию add процессора.
5. Получив результат создаёт новый объект, куда записывает получившийся результат в секцию неименованных данных, а так же указатели на методы, соответствующие соглашению (назначению метода)
T>Вход: выражение a + b. T>
T>Дальше вы сказали, что компилятор видит, что методы одинаковые, и на основании этой одинаковости предпринимает какое-то решение (в этом заключается вопрос), на основании которого генерится код типа
Не понял вопроса.
T>Выход: T>ADD d x y # где ADD это какая-то низкоуровневая функция, принимающая два числа, а x и y это числа из объектов a и b.
Выход — это уже новый объект с числом d. Кстати, раньше add не принимала целых три аргумента. Это я так, к слову
T>Вот объясните, что делает компилятор после обнаружения, что методы одинаковые, как получается результат?
Здравствуйте, AndrewVK, Вы писали:
FDS>>Грубо говоря, язык имеет стандартные наборы методов для int, String и decimal
AVK>Стандартный набор методов и есть тип.
Нет. Я могу выбрать из этого стандартного набора любое сочетание, например, метод print, предназначенный для int, запихнуть в объект, содержащий фактические данные типа decimal и метод + для типа decimal
FDS>>Я о таком языке и говорю.
AVK>Ну как то ты очень непонятно об этом говоришь.
Надо читать все сообщения темы, тогда будет понятно, я думаю.
Здравствуйте, samius, Вы писали:
AVK>>>Все, как только компилятор знает про объявленные методы, сразу же имеем типы. Единственная возможность поиметь полиморфизм операторов без типов — язык, в котором методы привязываются к экземплярам в рантайме.
FDS>>Я о таком языке и говорю.
S>http://en.wikipedia.org/wiki/Type_system#Dynamic_typing
И? Судя по определению, это не динамически типизированный язык.
Здравствуйте, samius, Вы писали:
S>А что это сказало компилятору о том, как процедура хранит переданные ей аргументы после вызова? Мы ведь все еще о процедурных типах данных здесь говорим, не так ли?
Всё сказало, т.к. процедура хранит аргументы так, как ей передал компилятор и больше никак. Тип функции является указанием на то, как компилятор хранит аргументы в момент их передачи, т.к. передача аргументов в функцию есть сохранение этих аргументов в стеке или регистрах процессора, в зависимости от соглашения о вызовах.
FDS>>Ну вот, а значит когда мы объявляем вызов функции, которая возвращает строку, то это не то же самое, что объявление строки
S>Кто-то утверждал обратное?
Да, ты утверждал, что
Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных.
Процедурный тип говорит компилятору, что у него нет объекта String, т.е. указывает его способ получения. Если бы процедурный тип ничего не говорил компилятору о способе хранения данных, то мы могли бы записать указатель на процедуру прямо в String, или наоборот, String в указатель на процедуру — компилятор бы не различал объекты String и сами процедуры.
S>>>Не исключаю что функция object*object -> object положит аргументы в словарь и вернет словарь. А может положить их в список и вернуть список, а может записать их в файл и вернуть хэндл файла. Так что сигнатура и соглашение не говорят ничего компилятору о способе хранения переданных данных.
FDS>>Говорят. Я уже писал, выше в этом сообщении и в предыдущем сообщении, но ты невнимательно прочитал. FDS>>Объявление функции object * object -> object говорит компилятору, что он делает приращение вершины стека на 2 указателя (8-мь или 16-ть байт, в зависимости от архитектуры), определяет место под результат в виде 1 указателя, ставит команду call на месте вызова функции и передаёт ей указатель на эту функцию. А если ты хочешь, чтобы в одной строчке программы сразу объявить как и что она делает и хранит, то ты многого хочешь. Достаточно того, что компилятор из этой строки узнал новую и необходимую для него информацию.
S>Процедурные типы данных и соглашения о вызове метода не имеют ничего общего.
Кто-то утверждал обратное?
Я утверждал лишь то, что тип функции используется компилятором для определения того, как вызывать функцию, в частности, сколько места в стеке и подо что нужно.
FDS>>>>О способе получения — да, так как мы должны вызвать функцию и отвести место, куда будем получать результат (если результат сложный — то место под указатель на результат) S>>>мы должны вызвать функцию, чтобы получить данные обратно. Зачем об этой функции что-то знать компилятору? FDS>>Чтобы её правильно вызвать, как ты понимаешь. S>Правильно вызвать — это одно, а то как хранит процедура переданные ей данные — это другое.
Ты правда такой или притворяешься?
Давай по пунктам, какой из них непонятен.
1. Тип процедуры есть информация — это понятно?
Если да, то
2. Тип процедуры указывает на то, что она процедура, т.е. её надо вызывать и что для вызова используется указатель
Ели это тоже понятно, то
3. Тип аргументов процедуры (т.е. сама сигнатура процедуры, её тип) указывает компилятору, как аргументы хранятся при вызове.
Если это тоже понятно, то
4. Пункты 2 и 3 и есть информация, которую компилятор использует для правильного вызва, который включает хранение в стеке или регистрах аргументов
Если это тоже понятно, то
5. Это и есть та информация о хранении данных, о которой указывает тип процедуры
Если это тоже понятно, то
6. Все остальные данные и информация о них абсолютно пофигу, независимо от того и где они, 5-ый пункт доказывает, что тип функции, как и любой другой тип, указывает компилятору, как хранить некоторую информацию.
Если это понятно, то
7. О том, что он указывает как хранить что-то кроме аргументов функции и указателя на функцию я никогда не утверждал
Здравствуйте, samius, Вы писали:
S>Не понимаю, что имеется в виду под хранением имени и списка параметров.
S>Я имел в виду нечто вроде определений cons ...
Ты имеешь в виду высокоуровневые вещи, а говорят тебе о низкоуровневых — о том как, если бы дело в asm, ты хранил бы параметры.
Т.е. тип процедуры определяет информацию о хранении данных, но, естественно, вовсе не ту, о которой ты говоришь
Так же, скажем, нетипизированный массив объявляет только о том, что данные занимают не более некоего объёма памяти, не говоря ничего об их структуре, но при этом ещё и говорит компилятору, что есть 4 байта на указатель на этот массив — т.е. говорит и о структуре и о размере некоторых других полей.
Здравствуйте, Temoto, Вы писали:
T>Пока это всё, к сожалению, многие светлые умы обходят вопрос стороной.
На самом деле, это не всё.
Главное, что мы выяснили: система типов позволяет организованно определять группы методов и полей, чем существенно облегчает работу программисту, т.к. иначе для кадого объекта программист вынужден был бы при создании этого объекта определять весь набор методов и полей объекта вручную.
Здравствуйте, Temoto, Вы писали:
T>Было мнение, что диспатчить полиморфизм можно и без типов, но это не противоречит второму пункту. Остальное тоже можно делать и в рамках одного типа, но с разветвлённой системой — намного более эффективно.
Ты зря опускаешь именно повышение эффективности — это ведь тоже цель типов.
Кроме этого типы позволяют говорить самому программисту о том, что он собирается получить и тем самым лучше документировать и структурировать программу, т.е. не только компилятору объявляют тип и наследников типа, но и программисту — по сути играют документирующую роль, причём именно формально-документирующую, в отличие от неформальной документации на естественном языке. Это большая разница, других инструментов для формальной документации у нас нет — это важно не только компилятору.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>Информация о типе, хранящаяся в голове программиста — это абстракция. Т.е. у компилятора, получается, системы типов технологически нет, соответственно и функции она никакой в языке не играет.
Я не понимаю, о чем ты. Если даже объекты состоят из словарей полей и методов, то это и есть система типов, которая будет играть определяющую роль в языке и его интерпретации.
Назови уже в конце концов язык без системы типов. Но не абстрактный, который ты придумал, а конкретный, существующий. Я все не могу понять, о чем ты думаешь, когда говоришь об отсутствии системы типов, может быть об Io?
S>>Ну да. В итоге получаем что наличие ассоциации с операцией сложения у двух операндов не обязательно.
FDS>При условии, что определён порядок применения этой операции.
Не обязательно и все тут.
А что ты имеешь под порядком, ассоциативность? Если да, то с какого конца будешь вычислять 1 + 2 + 3 если ассоциативность не определена?
Здравствуйте, samius, Вы писали:
FDS>>Информация о типе, хранящаяся в голове программиста — это абстракция. Т.е. у компилятора, получается, системы типов технологически нет, соответственно и функции она никакой в языке не играет.
S>Я не понимаю, о чем ты. Если даже объекты состоят из словарей полей и методов, то это и есть система типов, которая будет играть определяющую роль в языке и его интерпретации.
Где ж тут система типов? Система типов позразумевает определение типов объектов, а мы нигде не определяем типы, мы определяем только сами объекты, каждый из которых может состоять из уникального набора полей
S>Назови уже в конце концов язык без системы типов. Но не абстрактный, который ты придумал, а конкретный, существующий.
Зачем? Я специально использую абстракцию, чтобы отделить то, что привносят типы, от того, что они не привносят. Однако язык без типов в практическом программировании — это нонсенс.
S>>>Ну да. В итоге получаем что наличие ассоциации с операцией сложения у двух операндов не обязательно.
FDS>>При условии, что определён порядок применения этой операции.
S>Не обязательно и все тут.
Это неверно, см. ниже
S>А что ты имеешь под порядком, ассоциативность? Если да, то с какого конца будешь вычислять 1 + 2 + 3 если ассоциативность не определена?
Ассоциативность-то тут причём?
Под порядком я имею в виду алгоритм того, от которого из объектов будет браться метод сложения — от первого, второго и/или третьего, если у каждого из них определена своя операция сложения. В противном случае мы получаем неоднозначность.
Например, у нас есть три объекта, по факту хранящих числа 1, 2 и 3. В первом объекте операция сложения складывает числа, во втором — преобразует числа в строки и конкатенирует их, в третьем — складывает числа и возвращает вещественный результат (то бишь с плавающей точкой).
Тогда возможны следующие варианты:
1. 1 и результат 1 + 2, получаем 1+2=3, 3 + 3 = 6 в целочисленном виде
2. 2 и 1, получаем 2 + 3 = "23", 1 + "23" = 1 + 0x5051 = 0x5052 = 20562 в целочисленном виде (хотя, возможно, будет access violation или непредсказуемый результат, т.к. строка только два байта, а нужно целых четыре)
3. 3 и результат 2 + 3, тогда 2 + 3 = 5.0, 1 + 5.0 = 6.0
Возможны и другие варианты, поэтому без определения соглашения о порядке выполнения функций невозможно работать с такого рода полиморфизмом, если только у каждого из аргументов не определены один и те же функции сложения
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Не понимаю, что имеется в виду под хранением имени и списка параметров.
S>>Я имел в виду нечто вроде определений cons ...
FDS>Ты имеешь в виду высокоуровневые вещи, а говорят тебе о низкоуровневых — о том как, если бы дело в asm, ты хранил бы параметры. FDS>Т.е. тип процедуры определяет информацию о хранении данных, но, естественно, вовсе не ту, о которой ты говоришь
Еще раз говорю, процедура может сохранить параметры в файл, может послать по почте. Тип процедуры говорит о том, что процедура сделала с параметрами?
Причем тут стек и asm?
FDS>Так же, скажем, нетипизированный массив объявляет только о том, что данные занимают не более некоего объёма памяти, не говоря ничего об их структуре, но при этом ещё и говорит компилятору, что есть 4 байта на указатель на этот массив — т.е. говорит и о структуре и о размере некоторых других полей.
Здравствуйте, samius, Вы писали:
S>Еще раз говорю, процедура может сохранить параметры в файл, может послать по почте. Тип процедуры говорит о том, что процедура сделала с параметрами? S>Причем тут стек и asm?
Вы сказали о том, что тип процедуры не используется компилятором для получения информации о способе хранения данных, по крайней мере я так понял.
Понял я это из того, что вы стали возражать по поводу хранения, сказав "здесь есть варианты" так, как будто объявление процедуры не декларирует информацию о хранении данных.
Соответственно, я вам привёл пример того, что объявление процедуры декларирует инфомацию о хранении данных. При этом тут asm и стек.
FDS>>Так же, скажем, нетипизированный массив объявляет только о том, что данные занимают не более некоего объёма памяти, не говоря ничего об их структуре, но при этом ещё и говорит компилятору, что есть 4 байта на указатель на этот массив — т.е. говорит и о структуре и о размере некоторых других полей.
S>А о чем говорит компилятору хэндл файла?
Смотря как этот хэндл объявлен. Минимум — о том, что ему надо выделить 4 байта на хранение этого хэндла. Т.е. объявляя хэнд файла мы так же указываем информацию о способе хранения некоторых данных (собственно, хэндла файла)
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>А что это сказало компилятору о том, как процедура хранит переданные ей аргументы после вызова? Мы ведь все еще о процедурных типах данных здесь говорим, не так ли?
FDS>Всё сказало, т.к. процедура хранит аргументы так, как ей передал компилятор и больше никак. Тип функции является указанием на то, как компилятор хранит аргументы в момент их передачи, т.к. передача аргументов в функцию есть сохранение этих аргументов в стеке или регистрах процессора, в зависимости от соглашения о вызовах.
Процедурные типы хранят данные еще до того как состоялся вызов процедуры. Хватит нести чушь про стек и регистры.
FDS>>>Ну вот, а значит когда мы объявляем вызов функции, которая возвращает строку, то это не то же самое, что объявление строки
S>>Кто-то утверждал обратное?
FDS>Да, ты утверждал, что FDS>
FDS>Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных.
я до сих пор это утверждаю, но говорю о способе хранения данных а не о способе передачи аргументов и возврата результата
FDS>Процедурный тип говорит компилятору, что у него нет объекта String, т.е. указывает его способ получения. Если бы процедурный тип ничего не говорил компилятору о способе хранения данных, то мы могли бы записать указатель на процедуру прямо в String, или наоборот, String в указатель на процедуру — компилятор бы не различал объекты String и сами процедуры.
Но проблема в том, что ты походу не догоняешь, что такое процедурные типы и несешь что-то про записывание указателя в строку. Мне жаль, но я не хочу разбираться в этом бреде.
S>>Процедурные типы данных и соглашения о вызове метода не имеют ничего общего.
FDS>Кто-то утверждал обратное? FDS>Я утверждал лишь то, что тип функции используется компилятором для определения того, как вызывать функцию, в частности, сколько места в стеке и подо что нужно.
Ты утверждаешь то, что тип функции определяет то, что функция будет делать с данными.
FDS>Ты правда такой или притворяешься?
Я бы подумал что именно ты притворяешься, но теперь я думаю что ты не желаешь разобраться с процедурными типами данных и споришь о чем-то своем.
FDS>Давай по пунктам, какой из них непонятен.
FDS>1. Тип процедуры есть информация — это понятно?
Это банальность вроде того что программа есть информация.
FDS>Если да, то FDS>2. Тип процедуры указывает на то, что она процедура, т.е. её надо вызывать и что для вызова используется указатель FDS>Ели это тоже понятно, то FDS>3. Тип аргументов процедуры (т.е. сама сигнатура процедуры, её тип) указывает компилятору, как аргументы хранятся при вызове. FDS>Если это тоже понятно, то FDS>4. Пункты 2 и 3 и есть информация, которую компилятор использует для правильного вызва, который включает хранение в стеке или регистрах аргументов FDS>Если это тоже понятно, то FDS>5. Это и есть та информация о хранении данных, о которой указывает тип процедуры FDS>Если это тоже понятно, то FDS>6. Все остальные данные и информация о них абсолютно пофигу, независимо от того и где они, 5-ый пункт доказывает, что тип функции, как и любой другой тип, указывает компилятору, как хранить некоторую информацию. FDS>Если это понятно, то FDS>7. О том, что он указывает как хранить что-то кроме аргументов функции и указателя на функцию я никогда не утверждал
Тогда ты наверно не будешь спорить, что может существовать 2 разных процедуры с одним типом, которые делают с данными разные вещи?
Здравствуйте, samius, Вы писали:
S>Процедурные типы хранят данные еще до того как состоялся вызов процедуры.
И?
S> Хватит нести чушь про стек и регистры.
Т.е. по-твоему, всё что я сказал про стек и регистры — это чушь? Поздравляю
S>Но проблема в том, что ты походу не догоняешь, что такое процедурные типы и несешь что-то про записывание указателя в строку. Мне жаль, но я не хочу разбираться в этом бреде.
Ну если ты не хочешь спорить — это твои проблемы.
FDS>>Я утверждал лишь то, что тип функции используется компилятором для определения того, как вызывать функцию, в частности, сколько места в стеке и подо что нужно. S>Ты утверждаешь то, что тип функции определяет то, что функция будет делать с данными.
Приведи конкретную цитату, где я это сказал.
FDS>>Ты правда такой или притворяешься? S>Я бы подумал что именно ты притворяешься, но теперь я думаю что ты не желаешь разобраться с процедурными типами данных и споришь о чем-то своем.
Да ну?
FDS>>Давай по пунктам, какой из них непонятен.
FDS>>1. Тип процедуры есть информация — это понятно? S>Это банальность вроде того что программа есть информация.
Я не понял, тебе этот пункт понятен или нет? Программа программой, но информация о типе процедуры есть именно информация о типе процедуры, с этим ты, надеюсь, не споришь?
FDS>>Если да, то FDS>>2. Тип процедуры указывает на то, что она процедура, т.е. её надо вызывать и что для вызова используется указатель FDS>>Ели это тоже понятно, то FDS>>3. Тип аргументов процедуры (т.е. сама сигнатура процедуры, её тип) указывает компилятору, как аргументы хранятся при вызове. FDS>>Если это тоже понятно, то FDS>>4. Пункты 2 и 3 и есть информация, которую компилятор использует для правильного вызва, который включает хранение в стеке или регистрах аргументов FDS>>Если это тоже понятно, то FDS>>5. Это и есть та информация о хранении данных, о которой указывает тип процедуры FDS>>Если это тоже понятно, то FDS>>6. Все остальные данные и информация о них абсолютно пофигу, независимо от того и где они, 5-ый пункт доказывает, что тип функции, как и любой другой тип, указывает компилятору, как хранить некоторую информацию. FDS>>Если это понятно, то FDS>>7. О том, что он указывает как хранить что-то кроме аргументов функции и указателя на функцию я никогда не утверждал
S>Тогда ты наверно не будешь спорить, что может существовать 2 разных процедуры с одним типом, которые делают с данными разные вещи?
Ты зря игнорируешь все семь пунктов — просто словами мы с тобой друг друга понять не можем, а по пунктам ты наверняка найдёшь в чём дело (хотя я в другом сообщении уже отписался насчёт того, что мы спорим немного о разных вещах).
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Я не понимаю, о чем ты. Если даже объекты состоят из словарей полей и методов, то это и есть система типов, которая будет играть определяющую роль в языке и его интерпретации.
FDS>Где ж тут система типов? Система типов позразумевает определение типов объектов
Я понял мысль, если нет оператора typeof, значит нет системы типов?
S>>Назови уже в конце концов язык без системы типов. Но не абстрактный, который ты придумал, а конкретный, существующий.
FDS>Зачем? Я специально использую абстракцию, чтобы отделить то, что привносят типы, от того, что они не привносят. Однако язык без типов в практическом программировании — это нонсенс.
Тогда предлагаю тебе поспорить с абстрактным собеседником.
S>>>>Ну да. В итоге получаем что наличие ассоциации с операцией сложения у двух операндов не обязательно.
FDS>Под порядком я имею в виду алгоритм того, от которого из объектов будет браться метод сложения — от первого, второго и/или третьего, если у каждого из них определена своя операция сложения. В противном случае мы получаем неоднозначность.
member lookup ты имеешь в виду )))
Получаем и получаем. Это неважно. Мало ли неоднозначностей в языках программирования?
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>> Хватит нести чушь про стек и регистры.
FDS>Т.е. по-твоему, всё что я сказал про стек и регистры — это чушь? Поздравляю
Пусть не чушь, я не вчитывался. Но все это имеет лишь некоторое отношение к вызову процедур. В общем случае работать со стеком и регистрами может интерпретатор, но вызов процедуры может быть лишь переходом по синтаксическому дереву.
S>>Но проблема в том, что ты походу не догоняешь, что такое процедурные типы и несешь что-то про записывание указателя в строку. Мне жаль, но я не хочу разбираться в этом бреде.
FDS>Ну если ты не хочешь спорить — это твои проблемы.
Я не вижу с твоей стороны понимания обсуждаемого вопроса.
S>>Ты утверждаешь то, что тип функции определяет то, что функция будет делать с данными.
FDS>Приведи конкретную цитату, где я это сказал.
Лень
FDS>>>Ты правда такой или притворяешься? S>>Я бы подумал что именно ты притворяешься, но теперь я думаю что ты не желаешь разобраться с процедурными типами данных и споришь о чем-то своем.
FDS>Да ну?
FDS>>>Давай по пунктам, какой из них непонятен.
FDS>Ты зря игнорируешь все семь пунктов — просто словами мы с тобой друг друга понять не можем, а по пунктам ты наверняка найдёшь в чём дело (хотя я в другом сообщении уже отписался насчёт того, что мы спорим немного о разных вещах).
Дело в том, что ни один из пунктов не имеют отношения к обсуждаемому вопросу. Мы действительно спорим о разных вещах. Я о способах хранения данных в процедурных представлениях данных, а ты о способе передачи аргументов и возврата результата в процедурах.
Здравствуйте, samius, Вы писали:
S>>>Я не понимаю, о чем ты. Если даже объекты состоят из словарей полей и методов, то это и есть система типов, которая будет играть определяющую роль в языке и его интерпретации.
FDS>>Где ж тут система типов? Система типов позразумевает определение типов объектов S>Я понял мысль, если нет оператора typeof, значит нет системы типов?
Если нет данных о типе в коде или в служебных функциях самого языка — значит нет и типов.
S>>>Назови уже в конце концов язык без системы типов. Но не абстрактный, который ты придумал, а конкретный, существующий.
FDS>>Зачем? Я специально использую абстракцию, чтобы отделить то, что привносят типы, от того, что они не привносят. Однако язык без типов в практическом программировании — это нонсенс.
S>Тогда предлагаю тебе поспорить с абстрактным собеседником.
Какой в этом смысл?
FDS>>Под порядком я имею в виду алгоритм того, от которого из объектов будет браться метод сложения — от первого, второго и/или третьего, если у каждого из них определена своя операция сложения. В противном случае мы получаем неоднозначность.
S>member lookup ты имеешь в виду ))) S>Получаем и получаем. Это неважно. Мало ли неоднозначностей в языках программирования?
Компилятор тоже должен все десять способов вызвать? И все десять разных результатов запихнуть в один объект?
Здравствуйте, samius, Вы писали:
S>Пусть не чушь, я не вчитывался. Но все это имеет лишь некоторое отношение к вызову процедур. В общем случае работать со стеком и регистрами может интерпретатор, но вызов процедуры может быть лишь переходом по синтаксическому дереву.
Это не так. Рекурсивный вызов процедуры не может быть переходом по синтаксическому дереву.
S>Я не вижу с твоей стороны понимания обсуждаемого вопроса.
А я — с твоей. И? Кстати, это уже оффтопик.
S>>>Ты утверждаешь то, что тип функции определяет то, что функция будет делать с данными.
FDS>>Приведи конкретную цитату, где я это сказал.
S>Лень
Не лень, а не можешь, потому что я этого не говорил.
S>Дело в том, что ни один из пунктов не имеют отношения к обсуждаемому вопросу. Мы действительно спорим о разных вещах. Я о способах хранения данных в процедурных представлениях данных, а ты о способе передачи аргументов и возврата результата в процедурах.
Как раз все пункты имеют, просто ты совершенно не хочешь отвечать на то, что тебе говорят. Ты споришь как раз с тем самым абстрактным собеседником, с которым смысла спорить нет, вместо того, чтобы спорить с реальным собеседником или, хотя бы, читать его посты перед тем, как отвечать на них.
моё сообщение, т.к. тебе или придётся и дальше делать вид ничего не понимающего дурачка или наконец признать, что или ты был не прав, или опять же ты был не прав . Но ты почему-то игнорируешь это сообщение... лень, да... жуть
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>>>Я не понимаю, о чем ты. Если даже объекты состоят из словарей полей и методов, то это и есть система типов, которая будет играть определяющую роль в языке и его интерпретации.
FDS>>>Где ж тут система типов? Система типов позразумевает определение типов объектов S>>Я понял мысль, если нет оператора typeof, значит нет системы типов?
FDS>Если нет данных о типе в коде или в служебных функциях самого языка — значит нет и типов.
Что такое служебные функции языка?
S>>member lookup ты имеешь в виду ))) S>>Получаем и получаем. Это неважно. Мало ли неоднозначностей в языках программирования?
FDS>Компилятор тоже должен все десять способов вызвать? И все десять разных результатов запихнуть в один объект?
Компиялтор может вызвать первый попавшийся
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>Приведи конкретную цитату, где я это сказал.
S>>Лень
FDS>Не лень, а не можешь, потому что я этого не говорил.
Пусть не говорил, мне поровну
S>>Дело в том, что ни один из пунктов не имеют отношения к обсуждаемому вопросу. Мы действительно спорим о разных вещах. Я о способах хранения данных в процедурных представлениях данных, а ты о способе передачи аргументов и возврата результата в процедурах.
FDS>Как раз все пункты имеют, просто ты совершенно не хочешь отвечать на то, что тебе говорят. Ты споришь как раз с тем самым абстрактным собеседником, с которым смысла спорить нет, вместо того, чтобы спорить с реальным собеседником или, хотя бы, читать его посты перед тем, как отвечать на них.
Если тебе не нравится то что я сказал о процедурных типах, разберись для начала с предметом. Я не собирался с тобой спорить о стеке и регистрах.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Пусть не чушь, я не вчитывался. Но все это имеет лишь некоторое отношение к вызову процедур. В общем случае работать со стеком и регистрами может интерпретатор, но вызов процедуры может быть лишь переходом по синтаксическому дереву.
FDS>Это не так. Рекурсивный вызов процедуры не может быть переходом по синтаксическому дереву.
Это — чушь
T>>... и, соответственно, вопрос был в том как на основании двух одинаковых + :: Object -> Object -> Object компилятор узнает, что нужно подставить ADD, на какие ячейки памяти нужно ссылаться. Давайте попытаемся представить себе действия компилятора.
FDS>1. Есть указатели на объекты a и b FDS>2. В этих объектах хранятся данные объекта в двух возможных вариантах: а) сами данные объекта как первичного типа (секция неименованных данных) б) объекты-поля в словаре полей (секция именованных полей) FDS>3. В этих объектах хранится словарь методов, которые принимают указатели на объекты и заранее известно для каждого метода, сколько указателей принимает, и сколько возвращает
FDS>Тогда FDS>1. Компилятор находит объекты a и b как операнды оператора "+". FDS>2. В зависимости от соглашения, допустм, сравнивает, имеют ли a и b методы "+" и если имеют, равны ли они (совместимы ли) или просто вызывает один из методов по заранее определённому соглашению (мне нравится первый вариант, но samius указал на возможность и второго) FDS>3. Вызов метода происходит следующим образом: в него передаются два указателя на объект, сохраняется место для результата-объекта FDS>4. Метод реализован так, что читает данные обоих аргументов-объектов из секции неименованных данных, сам метод знает, что они 32-разрядные и передаёт два 32-разрядных числа в операцию add процессора. FDS>5. Получив результат создаёт новый объект, куда записывает получившийся результат в секцию неименованных данных, а так же указатели на методы, соответствующие соглашению (назначению метода)
Понятно, всё делает метод +. Всё ещё непонятно, как метод (+) :: Object -> Object -> Object имея на руках только два неименованных куска битов узнает, что к ним надо применить численное сложение, а не конкатенацию строк.
Здравствуйте, samius, Вы писали:
FDS>>Если нет данных о типе в коде или в служебных функциях самого языка — значит нет и типов. S>Что такое служебные функции языка?
Это то, что делает компилятор, чтобы определить тип, например, получает имя типа, или, скажем, список его методов и полей.
S>>>Получаем и получаем. Это неважно. Мало ли неоднозначностей в языках программирования?
FDS>>Компилятор тоже должен все десять способов вызвать? И все десять разных результатов запихнуть в один объект? S>Компиялтор может вызвать первый попавшийся
Если первую попавшуюся, то это означает, что или соглашение есть — вызвать первую, или соглашения нет — тогда функция вызывается случайно. В первом случае, очевидно, я прав, говоря, что это соглашение нужно, во втором случае, очевидно, такое выражение как 1+2+3 тогда вообще лишается смысла, так как даже сам программист никогда не узнает, что же получится в результате — т.е. в таком случае это означает фактический запрет на написание и вызов такого кода, следовательно, я опять прав.
Здравствуйте, samius, Вы писали:
FDS>>Как раз все пункты имеют, просто ты совершенно не хочешь отвечать на то, что тебе говорят. Ты споришь как раз с тем самым абстрактным собеседником, с которым смысла спорить нет, вместо того, чтобы спорить с реальным собеседником или, хотя бы, читать его посты перед тем, как отвечать на них.
S>Если тебе не нравится то что я сказал о процедурных типах, разберись для начала с предметом. Я не собирался с тобой спорить о стеке и регистрах.
Сам разберись сначала о чём я с тобой спорю — прочитай внимательно на что я первоначально отвечал и подумай, причём тут вообще способ получения и хранения данных внутри процедур (подсказка: он не при чём).
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Еще раз говорю, процедура может сохранить параметры в файл, может послать по почте. Тип процедуры говорит о том, что процедура сделала с параметрами? S>>Причем тут стек и asm?
FDS> Вы сказали о том, что тип процедуры не используется компилятором для получения информации о способе хранения данных, по крайней мере я так понял. FDS>Понял я это из того, что вы стали возражать по поводу хранения, сказав "здесь есть варианты" так, как будто объявление процедуры не декларирует информацию о хранении данных.
FDS>Соответственно, я вам привёл пример того, что объявление процедуры декларирует инфомацию о хранении данных. При этом тут asm и стек.
Этот пример не опровергает моего утверждения, более того он не имеет отношения к вопросу.
Вот пример обратного
[scheme]
(define (cons x y)
(define (dispatch m)
(cond ((= m 0) x)
((= m 1) y)
(else (error "Argument not 0 or 1 -- CONS" m))))
dispatch)
(define (car z) (z 0))
(define (cdr z) (z 1))
[/scheme]
FDS>>>Так же, скажем, нетипизированный массив объявляет только о том, что данные занимают не более некоего объёма памяти, не говоря ничего об их структуре, но при этом ещё и говорит компилятору, что есть 4 байта на указатель на этот массив — т.е. говорит и о структуре и о размере некоторых других полей.
S>>А о чем говорит компилятору хэндл файла?
FDS>Смотря как этот хэндл объявлен. Минимум — о том, что ему надо выделить 4 байта на хранение этого хэндла. Т.е. объявляя хэнд файла мы так же указываем информацию о способе хранения некоторых данных (собственно, хэндла файла)
О 4х байтах может и говорит, но о том в каком месте файла, и вообще в файле ли данные — нет.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
S>>>Пусть не чушь, я не вчитывался. Но все это имеет лишь некоторое отношение к вызову процедур. В общем случае работать со стеком и регистрами может интерпретатор, но вызов процедуры может быть лишь переходом по синтаксическому дереву.
FDS>>Это не так. Рекурсивный вызов процедуры не может быть переходом по синтаксическому дереву. S>Это — чушь
Пример в студию. Каким образом я буду переходить по синтаксическому дереву не выделяя при этом дополнительно памяти на рекурсию и запоминание самого факта вызова?
Рекурсивный вызов не может быть переходом по синтаксическому дереву, так как это уже переход по графу потока управления, который имеет циклы и деревом вообще не является.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Если тебе не нравится то что я сказал о процедурных типах, разберись для начала с предметом. Я не собирался с тобой спорить о стеке и регистрах.
FDS>Сам разберись сначала о чём я с тобой спорю — прочитай внимательно на что я первоначально отвечал и подумай, причём тут вообще способ получения и хранения данных внутри процедур (подсказка: он не при чём).
Здравствуйте, Temoto, Вы писали:
T>Понятно, всё делает метод +. Всё ещё непонятно, как метод (+) :: Object -> Object -> Object имея на руках только два неименованных куска битов узнает, что к ним надо применить численное сложение, а не конкатенацию строк.
Метод "+" ничего не узнаёт, он просто складывает два целых числа, так как в числах он именно такой.
В строках метод "+" определён другим способом — он уже выполняет конкатенацию.
Указатель на конкретный метод "+" каждый объект получает от программиста в свой словарь методов — что программист дал, то и есть, т.е. сам метод считает, что он применим к нужному куску битов без какой-либо проверки.
FDS>>Информация о типе, хранящаяся в голове программиста — это абстракция. Т.е. у компилятора, получается, системы типов технологически нет, соответственно и функции она никакой в языке не играет.
S>Я не понимаю, о чем ты. Если даже объекты состоят из словарей полей и методов, то это и есть система типов, которая будет играть определяющую роль в языке и его интерпретации.
S>Назови уже в конце концов язык без системы типов. Но не абстрактный, который ты придумал, а конкретный, существующий. Я все не могу понять, о чем ты думаешь, когда говоришь об отсутствии системы типов, может быть об Io?
Это я должен был пояснить.
Языком без системы типов можно называть язык с одним типом. Например, bash.
Здравствуйте, FDSC, Вы писали:
FDS>>>Это не так. Рекурсивный вызов процедуры не может быть переходом по синтаксическому дереву. S>>Это — чушь
FDS>Пример в студию. Каким образом я буду переходить по синтаксическому дереву не выделяя при этом дополнительно памяти на рекурсию и запоминание самого факта вызова?
foo() { foo(); }
память не нужна, факт вызова не нужен, во всяком случае на каждый вызов.
FDS>Рекурсивный вызов не может быть переходом по синтаксическому дереву, так как это уже переход по графу потока управления, который имеет циклы и деревом вообще не является.
Здравствуйте, Temoto, Вы писали:
S>>Назови уже в конце концов язык без системы типов. Но не абстрактный, который ты придумал, а конкретный, существующий. Я все не могу понять, о чем ты думаешь, когда говоришь об отсутствии системы типов, может быть об Io?
T>Это я должен был пояснить.
T>Языком без системы типов можно называть язык с одним типом. Например, bash.
Почему вы исключаете систему типов, состоящую из одного типа? Есть тип — есть система типов.
T>>Понятно, всё делает метод +. Всё ещё непонятно, как метод (+) :: Object -> Object -> Object имея на руках только два неименованных куска битов узнает, что к ним надо применить численное сложение, а не конкатенацию строк.
FDS>Метод "+" ничего не узнаёт, он просто складывает два целых числа, так как в числах он именно такой. FDS>В строках метод "+" определён другим способом — он уже выполняет конкатенацию.
FDS>Указатель на конкретный метод "+" каждый объект получает от программиста в свой словарь методов — что программист дал, то и есть, т.е. сам метод считает, что он применим к нужному куску битов без какой-либо проверки.
То есть вы имели в виду случай, когда после создания каждого объекта программист должен сам навесить ему операторов. Теперь всё ясно, спасибо.
S>>>Назови уже в конце концов язык без системы типов. Но не абстрактный, который ты придумал, а конкретный, существующий. Я все не могу понять, о чем ты думаешь, когда говоришь об отсутствии системы типов, может быть об Io?
T>>Это я должен был пояснить.
T>>Языком без системы типов можно называть язык с одним типом. Например, bash.
S>Почему вы исключаете систему типов, состоящую из одного типа? Есть тип — есть система типов.
Потому что это неконструктивно, как считать всякую программу информацией.
Здравствуйте, samius, Вы писали: S>язык без системы типов
А вот фиг его знает. Можно подразумевать под этим язык, где значения переменных интерпретируются по-разному: как строки или как числа или как еще что в зависимости от текущей операции.
А можно подразумевать язык, где нет статической типизации. Ведь можно систему типов считать языком записи высказываний относительно программы (а саму программу — набором доказательств этих высказываний).
>Io
Вот и бедному io досталось. А чем он хуже любого другого динамического языка?
Здравствуйте, Temoto, Вы писали:
T>>>Языком без системы типов можно называть язык с одним типом. Например, bash.
S>>Почему вы исключаете систему типов, состоящую из одного типа? Есть тип — есть система типов.
T>Потому что это неконструктивно, как считать всякую программу информацией.
Здравствуйте, samius, Вы писали:
FDS>>Соответственно, я вам привёл пример того, что объявление процедуры декларирует инфомацию о хранении данных. При этом тут asm и стек.
S>Этот пример не опровергает моего утверждения, более того он не имеет отношения к вопросу.
Этот пример как раз имеет отношение к вопросу, так как он показывает, что любое определение процедуры объявляет информацию о хранении аргументов этой процедуры.
S>Вот пример обратного
S>[scheme] S>(define (cons x y) S> (define (dispatch m) S> (cond ((= m 0) x) S> ((= m 1) y) S> (else (error "Argument not 0 or 1 -- CONS" m)))) S> dispatch)
S>(define (car z) (z 0))
S>(define (cdr z) (z 1)) S>[/scheme]
Где именно здесь пример обратного? Во всех объявлениях функций интерпретатор получает информацию о том, сколько в них аргументов — т.е. определяет, по сути, структуру, в которой передаются аргументы, и, соответственно, место под эту структуру. А уж что в ней дальше содержится — нам без разницы. Важно, что определяя функцию мы указали о способе хранения аргумента. Например, для функции cons мы указали о том, что её аргумент состоит из пары значений (если считать все функции только с одним аргументом) или, что то же самое, что при вызове этой функции нам необходимо запомнить в стеке два аргумента. Это и есть так информация, которая предоставляется компилятору в описании функции — и она есть.
А то, что в результате исполнения функции мы получаем лексическое замыкание, с помощью которого можно построить любой односвязный граф — это уже другой вопрос.
S>О 4х байтах может и говорит, но о том в каком месте файла, и вообще в файле ли данные — нет.
И? В процедурных типах вы говорите, что и этих 4-х байтов нет.
Здравствуйте, Mr.Cat, Вы писали: MC>А можно подразумевать язык, где нет статической типизации. Ведь можно систему типов считать языком записи высказываний относительно программы (а саму программу — набором доказательств этих высказываний).
Дополню. В языке с динамической типизацией скорее всего не будет способа записи этих самых высказываний — так что программа вроде как и не является доказательством чего-либо.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, samius, Вы писали: S>>язык без системы типов MC>А вот фиг его знает. Можно подразумевать под этим язык, где значения переменных интерпретируются по-разному: как строки или как числа или как еще что в зависимости от текущей операции. MC>А можно подразумевать язык, где нет статической типизации. Ведь можно систему типов считать языком записи высказываний относительно программы (а саму программу — набором доказательств этих высказываний).
Нет статической, значит есть динамическая. А подразумевать-то конечно можно.
>>Io MC>Вот и бедному io досталось. А чем он хуже любого другого динамического языка?
Его имя короче )))
Здравствуйте, Temoto, Вы писали:
T>То есть вы имели в виду случай, когда после создания каждого объекта программист должен сам навесить ему операторов. Теперь всё ясно, спасибо.
Ну да, потому что иначе придётся объявлять типы, а их у нас нет
MC>А можно подразумевать язык, где нет статической типизации. Ведь можно систему типов считать языком записи высказываний относительно программы (а саму программу — набором доказательств этих высказываний).
Интересная мысль, вы не могли бы разъяснить другими словами? Может быть, с примером?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>>>Это не так. Рекурсивный вызов процедуры не может быть переходом по синтаксическому дереву. S>>>Это — чушь
FDS>>Пример в студию. Каким образом я буду переходить по синтаксическому дереву не выделяя при этом дополнительно памяти на рекурсию и запоминание самого факта вызова?
S>foo() { foo(); } S>память не нужна, факт вызова не нужен, во всяком случае на каждый вызов.
1. Частный случай
2. Справедлив только если компилятор преобразует это в концевую рекурсию — т.е. цикл, но тогда это уже не переход по AST
3. Если же компилятор осуществляет этот переход без преобразования, то он, в отличие от человека, должен надеятся когда-то вернутся, поэтому должен сохранять адрес возврата при каждом вызове. Это машинная логика, другая логика машине не доступна. По крайней мере пока, иначе бы сейчас у нас уже был бы верифицирующий компилятор.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>Соответственно, я вам привёл пример того, что объявление процедуры декларирует инфомацию о хранении данных. При этом тут asm и стек.
S>>Этот пример не опровергает моего утверждения, более того он не имеет отношения к вопросу.
FDS>Этот пример как раз имеет отношение к вопросу, так как он показывает, что любое определение процедуры объявляет информацию о хранении аргументов этой процедуры.
О передаче аргументов — без базара. О зранении их вне вызова — нет.
S>>Вот пример обратного
S>>[scheme] S>>(define (cons x y) S>> (define (dispatch m) S>> (cond ((= m 0) x) S>> ((= m 1) y) S>> (else (error "Argument not 0 or 1 -- CONS" m)))) S>> dispatch)
S>>(define (car z) (z 0))
S>>(define (cdr z) (z 1)) S>>[/scheme]
FDS>Где именно здесь пример обратного? Во всех объявлениях функций интерпретатор получает информацию о том, сколько в них аргументов — т.е. определяет, по сути, структуру, в которой передаются аргументы, и, соответственно, место под эту структуру. А уж что в ней дальше содержится — нам без разницы. Важно, что определяя функцию мы указали о способе хранения аргумента. Например, для функции cons мы указали о том, что её аргумент состоит из пары значений (если считать все функции только с одним аргументом) или, что то же самое, что при вызове этой функции нам необходимо запомнить в стеке два аргумента. Это и есть так информация, которая предоставляется компилятору в описании функции — и она есть.
Продолжаешь обсасывать передачу аргументов? Дальше сам с собой!
FDS>А то, что в результате исполнения функции мы получаем лексическое замыкание, с помощью которого можно построить любой односвязный граф — это уже другой вопрос.
Вот именно другого вопроса и касалось мое утверждение
S>>О 4х байтах может и говорит, но о том в каком месте файла, и вообще в файле ли данные — нет.
FDS>И? В процедурных типах вы говорите, что и этих 4-х байтов нет.
Теперь поделись секретом, как ты из моего утверждения сделал такой далекоидущий вывод? Нет, ну интересно просто.
Здравствуйте, Temoto, Вы писали:
MC>>А можно подразумевать язык, где нет статической типизации. Ведь можно систему типов считать языком записи высказываний относительно программы (а саму программу — набором доказательств этих высказываний).
T>Интересная мысль, вы не могли бы разъяснить другими словами? Может быть, с примером?
Если я правильно понял, он имеет в виду, что мы высказываем, что int a, b, c, а затем даём высказывания с = 1; b = c + 1; a = b + 1.
Таким образом мы получаем своего рода "доказательство": c действительно является int, т.к. равна значению типа int, b действительно является int, т.к. равна значению типа int, получаемому как результат операции +: int * int -> int, и т.п.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, FDSC, Вы писали:
FDS>>>>>Это не так. Рекурсивный вызов процедуры не может быть переходом по синтаксическому дереву. S>>>>Это — чушь
FDS>>>Пример в студию. Каким образом я буду переходить по синтаксическому дереву не выделяя при этом дополнительно памяти на рекурсию и запоминание самого факта вызова?
S>>foo() { foo(); } S>>память не нужна, факт вызова не нужен, во всяком случае на каждый вызов.
FDS>1. Частный случай
Частный случай, опровергающий необходимость дополнительной памяти. Большего от примера не требовалось.
FDS>2. Справедлив только если компилятор преобразует это в концевую рекурсию — т.е. цикл, но тогда это уже не переход по AST
Концевая рекурсия — еще целый класс примеров, не требующих "памяти на рекурсию".
FDS>3. Если же компилятор осуществляет этот переход без преобразования, то он, в отличие от человека, должен надеятся когда-то вернутся, поэтому должен сохранять адрес возврата при каждом вызове. Это машинная логика, другая логика машине не доступна. По крайней мере пока, иначе бы сейчас у нас уже был бы верифицирующий компилятор.
При каждом не должен.
У меня вообще все время навязчивое впечатление, что все твои изречения определены в твоей голове на каких-то частных случаях типа язык без типа или неверифицирующий компилятор... Но выглядят-то они так, как будто они справедливы на все случаи жизни.
Вот поясни, откуда ты вообще взял что обсуждаемый компилятор верифицирующий или нет? Нет, не надо пояснять.
Здравствуйте, Temoto, Вы писали: T>Интересная мысль, вы не могли бы разъяснить другими словами? Может быть, с примером?
Своими словами у меня плохо получается. Лучше почитать про изоморфизм Карри-Ховарда, хотя б тут, а лучше тут (сам пока в процессе). Грубо говоря, типы в программировании ведут себя подобно высказываниям в логике.
S>>>foo() { foo(); } S>>>память не нужна, факт вызова не нужен, во всяком случае на каждый вызов.
FDS>>1. Частный случай
S>Частный случай, опровергающий необходимость дополнительной памяти. Большего от примера не требовалось.
Наоборот, я привёл частный случай, когда дополнительная память необходима — а любая это рекурсия или нет — не важно, есть по крайней мере одна рекурсия (например, qsort) где память необходима и, значит, это не есть переход по дереву.
FDS>>2. Справедлив только если компилятор преобразует это в концевую рекурсию — т.е. цикл, но тогда это уже не переход по AST S>Концевая рекурсия — еще целый класс примеров, не требующих "памяти на рекурсию".
см. выше.
FDS>>3. Если же компилятор осуществляет этот переход без преобразования, то он, в отличие от человека, должен надеятся когда-то вернутся, поэтому должен сохранять адрес возврата при каждом вызове. Это машинная логика, другая логика машине не доступна. По крайней мере пока, иначе бы сейчас у нас уже был бы верифицирующий компилятор. S>При каждом не должен.
Должен. Например, транслятор это просто не может сделать иначе как
proc foo
call foo
RET
а значит, что при каждом вызове будет выделяться память. Вообще говоря, и интерпретатор должен делать аналогичные вещи, если только это программу не интерпретирует компилятор с ИИ, которого ещё не придумали или не интерпретирует человек (который сообразит всю бессмысленность таких манипуляций).
S>У меня вообще все время навязчивое впечатление, что все твои изречения определены в твоей голове на каких-то частных случаях типа язык без типа или неверифицирующий компилятор... Но выглядят-то они так, как будто они справедливы на все случаи жизни. S>Вот поясни, откуда ты вообще взял что обсуждаемый компилятор верифицирующий или нет? Нет, не надо пояснять.
Обсуждаемый компилятор неверифицирующий, т.к. верифицирующих компиляторов нет в связи с отсутствием ИИ. Пока ИИ не появится для рекурсии foo {foo();} компилятор будет вынужден выделять на каждый вызов место в стеке или преобразовывать концевую рекурсию в цикл.
Здравствуйте, samius, Вы писали:
S>Продолжаешь обсасывать передачу аргументов? Дальше сам с собой!
Ну, если ты признаешь наконец-то свою ошибку — то само собой.
FDS>>А то, что в результате исполнения функции мы получаем лексическое замыкание, с помощью которого можно построить любой односвязный граф — это уже другой вопрос.
S>Вот именно другого вопроса и касалось мое утверждение
А другой вопрос мы не обсуждаем, т.к. обсуждается твоё утверждение о том, что декларация типа процедуры не объявляет вообще никакой информации о хранении данных.
S>>>О 4х байтах может и говорит, но о том в каком месте файла, и вообще в файле ли данные — нет.
FDS>>И? В процедурных типах вы говорите, что и этих 4-х байтов нет.
S>Теперь поделись секретом, как ты из моего утверждения сделал такой далекоидущий вывод? Нет, ну интересно просто.
Я уже писал выше, цитирую
Вы сказали о том, что тип процедуры не используется компилятором для получения информации о способе хранения данных, по крайней мере я так понял.
Понял я это из того, что вы стали возражать по поводу хранения, сказав "здесь есть варианты" так, как будто объявление процедуры не декларирует информацию о хранении данных.
Соответственно, я вам привёл пример того, что объявление процедуры декларирует инфомацию о хранении данных. При этом тут asm и стек.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>>>foo() { foo(); } S>>>>память не нужна, факт вызова не нужен, во всяком случае на каждый вызов.
FDS>>>1. Частный случай
S>>Частный случай, опровергающий необходимость дополнительной памяти. Большего от примера не требовалось.
FDS>Наоборот, я привёл частный случай, когда дополнительная память необходима — а любая это рекурсия или нет — не важно, есть по крайней мере одна рекурсия (например, qsort) где память необходима и, значит, это не есть переход по дереву.
Существование частного случая qsort не доказыват тот факт что дополнительная память необходима для всей рекурсии.
Раз это для тебя не очевидно, то я прекращаю спор
FDS>>Наоборот, я привёл частный случай, когда дополнительная память необходима — а любая это рекурсия или нет — не важно, есть по крайней мере одна рекурсия (например, qsort) где память необходима и, значит, это не есть переход по дереву.
S>Существование частного случая qsort не доказыват тот факт что дополнительная память необходима для всей рекурсии.
А я никогда и не пытался доказать этот факт.
Существование частного случая qsort доказывает тот факт, что есть операции, где вызов функции не может быть представлен как простой переход по AST
Здравствуйте, samius, Вы писали:
S>Существование частного случая qsort не доказыват тот факт что дополнительная память необходима для всей рекурсии. S>Раз это для тебя не очевидно, то я прекращаю спор
Кроме этого вы пропустили другой мой аргумент по поводу того, что всякая рекурсия не является переходом по дереву AST
Здравствуйте, FDSC, Вы писали:
FDS>А другой вопрос мы не обсуждаем, т.к. обсуждается твоё утверждение о том, что декларация типа процедуры не объявляет вообще никакой информации о хранении данных.
Я имел в виду хранение данных а не передачу аргументов. Почувствуй разницу.
Напомню, речь шла о структурах данных и о роли типа в хранении данных. Алтернатива предлагалась — словарь.
S>>>>О 4х байтах может и говорит, но о том в каком месте файла, и вообще в файле ли данные — нет.
FDS>>>И? В процедурных типах вы говорите, что и этих 4-х байтов нет.
S>>Теперь поделись секретом, как ты из моего утверждения сделал такой далекоидущий вывод? Нет, ну интересно просто.
Я имел в виду этот вывод "В процедурных типах вы говорите, что и этих 4-х байтов нет."
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Существование частного случая qsort не доказыват тот факт что дополнительная память необходима для всей рекурсии. S>>Раз это для тебя не очевидно, то я прекращаю спор
FDS>Кроме этого вы пропустили другой мой аргумент по поводу того, что всякая рекурсия не является переходом по дереву AST
У вас ярко выраженная проблема с кванторами всеобщности и существования. Пока вы ее не устраните, ваши аргументы меня не интересуют
Здравствуйте, samius, Вы писали:
S>У вас ярко выраженная проблема с кванторами всеобщности и существования. Пока вы ее не устраните, ваши аргументы меня не интересуют
Ну если ты не хочешь спорить и переходишь на личности — мне же лучше, засчитываю себе победу.
А проблема с кванторами у вас, а не у меня, так что устраняйте эту проблему как можно скорее. Для того, чтобы доказать, что утверждение "все вызовы функций являются переходами по дереву AST" мне достаточно привести лишь один пример вызова, который не является переходом, а вовсе не доказывать, что все вызовы не являются таковыми переходами.
А уж то, что на практике все рекурсивные вызовы, не преобразованные в циклы, требуют выделения памяти при каждом вызове — это довесок.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>А другой вопрос мы не обсуждаем, т.к. обсуждается твоё утверждение о том, что декларация типа процедуры не объявляет вообще никакой информации о хранении данных. S>Я имел в виду хранение данных а не передачу аргументов. Почувствуй разницу.
Передача аргументов и есть хранение данных — этих самых аргументов. Об этом и спор — при определении типа функции определяется способ передачи аргументов, т.е. способ их хранения при передаче.
S>Напомню, речь шла о структурах данных и о роли типа в хранении данных. Алтернатива предлагалась — словарь.
Ну да, именно. Опеределение типа функции по сути и определяет структуру данных, которая передаётся в эту функцию.
S>Я имел в виду этот вывод "В процедурных типах вы говорите, что и этих 4-х байтов нет."
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>У вас ярко выраженная проблема с кванторами всеобщности и существования. Пока вы ее не устраните, ваши аргументы меня не интересуют
FDS>Ну если ты не хочешь спорить и переходишь на личности — мне же лучше, засчитываю себе победу.
Да пожалуйста, считай что угодно.
FDS>А проблема с кванторами у вас, а не у меня, так что устраняйте эту проблему как можно скорее. Для того, чтобы доказать, что утверждение "все вызовы функций являются переходами по дереву AST" мне достаточно привести лишь один пример вызова, который не является переходом, а вовсе не доказывать, что все вызовы не являются таковыми переходами.
Приведи только цитату того места, где я сделал утверждение "все вызовы функций являются переходами по дереву AST".
FDS>А уж то, что на практике все рекурсивные вызовы, не преобразованные в циклы, требуют выделения памяти при каждом вызове — это довесок.
Вот выделенное — довесок.
Здравствуйте, FDSC, Вы писали: MC>>Своими словами у меня плохо получается. Лучше почитать про изоморфизм Карри-Ховард FDS>Моё объяснение (чуть выше вашего) имеет с этим что-либо общее?
Да, плюс, еще можно понаблюдать, во что в системах типов превращаются логические операции (коньюнкция, дизъюнкция, импликация) и кванторы — в туплы, ADT, функции (тип).
Здравствуйте, samius, Вы писали:
FDS>>А проблема с кванторами у вас, а не у меня, так что устраняйте эту проблему как можно скорее. Для того, чтобы доказать, что утверждение "все вызовы функций являются переходами по дереву AST" мне достаточно привести лишь один пример вызова, который не является переходом, а вовсе не доказывать, что все вызовы не являются таковыми переходами.
S>Приведи только цитату того места, где я сделал утверждение "все вызовы функций являются переходами по дереву AST".
А может мне лень, как и тебе приводит мои цитаты?
Но все это имеет лишь некоторое отношение к вызову процедур. В общем случае работать со стеком и регистрами может интерпретатор, но вызов процедуры может быть лишь переходом по синтаксическому дереву.
FDS>>А уж то, что на практике все рекурсивные вызовы, не преобразованные в циклы, требуют выделения памяти при каждом вызове — это довесок. S>Вот выделенное — довесок.
Тогда это уже не вызов процедуры, а условный переход и никакого отношения к твоему утверждению он не имеет.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, FDSC, Вы писали:
FDS>>>А другой вопрос мы не обсуждаем, т.к. обсуждается твоё утверждение о том, что декларация типа процедуры не объявляет вообще никакой информации о хранении данных. S>>Я имел в виду хранение данных а не передачу аргументов. Почувствуй разницу.
FDS>Передача аргументов и есть хранение данных — этих самых аргументов. Об этом и спор — при определении типа функции определяется способ передачи аргументов, т.е. способ их хранения при передаче.
А что делать с данными, которые не были переданы? Замыкание получает свои данные не через стек и может хранить их как угодно не взирая на тип функции.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>А проблема с кванторами у вас, а не у меня, так что устраняйте эту проблему как можно скорее. Для того, чтобы доказать, что утверждение "все вызовы функций являются переходами по дереву AST" мне достаточно привести лишь один пример вызова, который не является переходом, а вовсе не доказывать, что все вызовы не являются таковыми переходами.
S>>Приведи только цитату того места, где я сделал утверждение "все вызовы функций являются переходами по дереву AST".
FDS>А может мне лень, как и тебе приводит мои цитаты? FDS>
FDS>Но все это имеет лишь некоторое отношение к вызову процедур. В общем случае работать со стеком и регистрами может интерпретатор, но вызов процедуры может быть лишь переходом по синтаксическому дереву.
Ты уже не можешь отличить "все вызовы функций" от "вызов может быть" ???
FDS>>>А уж то, что на практике все рекурсивные вызовы, не преобразованные в циклы, требуют выделения памяти при каждом вызове — это довесок. S>>Вот выделенное — довесок.
FDS>Тогда это уже не вызов процедуры, а условный переход и никакого отношения к твоему утверждению он не имеет.
Имеет, т.к. это форма рекурсии
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
FDS>>>>А проблема с кванторами у вас, а не у меня, так что устраняйте эту проблему как можно скорее. Для того, чтобы доказать, что утверждение "все вызовы функций являются переходами по дереву AST" мне достаточно привести лишь один пример вызова, который не является переходом, а вовсе не доказывать, что все вызовы не являются таковыми переходами.
S>>>Приведи только цитату того места, где я сделал утверждение "все вызовы функций являются переходами по дереву AST".
FDS>>А может мне лень, как и тебе приводит мои цитаты? FDS>>
FDS>>Но все это имеет лишь некоторое отношение к вызову процедур. В общем случае работать со стеком и регистрами может интерпретатор, но вызов процедуры может быть лишь переходом по синтаксическому дереву.
S>Ты уже не можешь отличить "все вызовы функций" от "вызов может быть" ???
Если ты имел в виду, что "вызов может быть", то у тебя проблема с логикой (а я думал, что у тебя её нет). Проблема, потому что тогда твой аргумент не имеет никакой силы, т.к. если "может быть", то это означает что интерпретатор всё равно работает на вызовах со стеком, храня в нём аргументы и адрес возврата.
Кроме этого, на самом деле, совершенно не важно, переход это по AST или нет — аргументы всё равно где-то хранятся. Если даже это переход — то мы, декларируя тип функции, определили место в AST, где хранятся аргументы функции, а так же определили место, где хранится сама информация о вызове функции, т.е. всё равно определили способ хранения некоторых данных даже для функции без параметров, которая ничего не делает.
FDS>>>>А уж то, что на практике все рекурсивные вызовы, не преобразованные в циклы, требуют выделения памяти при каждом вызове — это довесок. S>>>Вот выделенное — довесок.
FDS>>Тогда это уже не вызов процедуры, а условный переход и никакого отношения к твоему утверждению он не имеет. S>Имеет, т.к. это форма рекурсии
Нет, условный переход вызовом функции не является.
Здравствуйте, samius, Вы писали:
FDS>>Передача аргументов и есть хранение данных — этих самых аргументов. Об этом и спор — при определении типа функции определяется способ передачи аргументов, т.е. способ их хранения при передаче.
S>А что делать с данными, которые не были переданы? Замыкание получает свои данные не через стек и может хранить их как угодно не взирая на тип функции.
Это не так. Когда мы определяем замыкание, мы определяем место в куче, т.е. структуру, соответствующую функции, где нечто хранится, т.е. определяя замыкание мы вообще указываем не только на передачу аргументов (или их отсутствие), но и указываем способ хранения некоторых данных этого замыкания и формат этих данных (в твоём примере — пара значений)
Здравствуйте, FDSC, Вы писали:
S>>Ты уже не можешь отличить "все вызовы функций" от "вызов может быть" ???
FDS>Если ты имел в виду, что "вызов может быть", то у тебя проблема с логикой (а я думал, что у тебя её нет). Проблема, потому что тогда твой аргумент не имеет никакой силы, т.к. если "может быть", то это означает что интерпретатор всё равно работает на вызовах со стеком, храня в нём аргументы и адрес возврата.
Не силен в демагогии, но я считаю что своим аргументом я опровергнул твой.
FDS>>>Тогда это уже не вызов процедуры, а условный переход и никакого отношения к твоему утверждению он не имеет. S>>Имеет, т.к. это форма рекурсии
FDS>Нет, условный переход вызовом функции не является.
Как и переход по АСТ
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>Передача аргументов и есть хранение данных — этих самых аргументов. Об этом и спор — при определении типа функции определяется способ передачи аргументов, т.е. способ их хранения при передаче.
S>>А что делать с данными, которые не были переданы? Замыкание получает свои данные не через стек и может хранить их как угодно не взирая на тип функции.
FDS>Это не так. Когда мы определяем замыкание, мы определяем место в куче, т.е. структуру, соответствующую функции, где нечто хранится, т.е. определяя замыкание мы вообще указываем не только на передачу аргументов (или их отсутствие), но и указываем способ хранения некоторых данных этого замыкания и формат этих данных (в твоём примере — пара значений)
Теперь ответь как способ хранения некоторых данных замыкания влияет на тип функции
FDS>>>А другой вопрос мы не обсуждаем, т.к. обсуждается твоё утверждение о том, что декларация типа процедуры не объявляет вообще никакой информации о хранении данных. S>>Я имел в виду хранение данных а не передачу аргументов. Почувствуй разницу.
FDS>Передача аргументов и есть хранение данных — этих самых аргументов. Об этом и спор — при определении типа функции определяется способ передачи аргументов, т.е. способ их хранения при передаче.
Он говорил о том, что функция f = 15 хранит число 15. И это число можно получить посредством вызова функции. Но хранит она это число до вызова. Это не имеет отношения к передаче аргументов. Тут речь про хранение данных, про структуры данных в виде функций. Ещё пример: функция add_1 = (+) 1 :: Int -> Int прибавляет к числу единицу. add_1 2 = 3. add_1 хранит единицу. Эту единицу можно "извлечь" с помощью add_1 0.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
S>>>Ты уже не можешь отличить "все вызовы функций" от "вызов может быть" ???
FDS>>Если ты имел в виду, что "вызов может быть", то у тебя проблема с логикой (а я думал, что у тебя её нет). Проблема, потому что тогда твой аргумент не имеет никакой силы, т.к. если "может быть", то это означает что интерпретатор всё равно работает на вызовах со стеком, храня в нём аргументы и адрес возврата.
S>Не силен в демагогии, но я считаю что своим аргументом я опровергнул твой.
В демагогии ты как раз силён.
Ты не опровергнул мой аргумент и вообще занимаешься сейчас троллингом.
Тип функции в любом случае определяет информацию о месте для хранения парамтеров, не важно, как именно мы это место представляем — где-то эти параметры всегда хранятся, даже если сделать такое AST, на котором сразу можно будет выполнять какие-то программы, мы всё равно где-то будем хранить аргументы функции и то место (точнее, его формат), где будем хранить, будет определятся в частности и типом функции.
FDS>>>>Тогда это уже не вызов процедуры, а условный переход и никакого отношения к твоему утверждению он не имеет. S>>>Имеет, т.к. это форма рекурсии
FDS>>Нет, условный переход вызовом функции не является. S>Как и переход по АСТ
Ты споришь или хулиганишь? Если споришь — спорь, если нет — не надо ничего писать.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
FDS>>>>Передача аргументов и есть хранение данных — этих самых аргументов. Об этом и спор — при определении типа функции определяется способ передачи аргументов, т.е. способ их хранения при передаче.
S>>>А что делать с данными, которые не были переданы? Замыкание получает свои данные не через стек и может хранить их как угодно не взирая на тип функции.
FDS>>Это не так. Когда мы определяем замыкание, мы определяем место в куче, т.е. структуру, соответствующую функции, где нечто хранится, т.е. определяя замыкание мы вообще указываем не только на передачу аргументов (или их отсутствие), но и указываем способ хранения некоторых данных этого замыкания и формат этих данных (в твоём примере — пара значений)
S>Теперь ответь как способ хранения некоторых данных замыкания влияет на тип функции
Это тип функции влияет на способ хранения данных замыкания, т.к. в твоём примере
(define (cons x y)
(define (dispatch m)
(cond ((= m 0) x)
((= m 1) y)
(else (error "Argument not 0 or 1 -- CONS" m))))
dispatch)
именно описатель типа функции cons объявляет (в данном случае полностью) информацию о данных, которые хранятся в замыкании. Т.е. тип функции cons предоставляет инфомацию интерпретатору о том, какие данные нужно хранить в замыкании.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Теперь ответь как способ хранения некоторых данных замыкания влияет на тип функции
FDS>Это тип функции влияет на способ хранения данных замыкания, т.к. в твоём примере FDS>
FDS>(define (cons x y)
FDS>(define (dispatch m)
FDS>(cond ((= m 0) x)
FDS>((= m 1) y)
FDS>(else (error "Argument not 0 or 1 -- CONS" m))))
FDS>dispatch)
FDS>
FDS>именно описатель типа функции cons объявляет (в данном случае полностью) информацию о данных, которые хранятся в замыкании. Т.е. тип функции cons предоставляет инфомацию интерпретатору о том, какие данные нужно хранить в замыкании.
Запиши тип функции cons, как ты его себе представляешь
Здравствуйте, Temoto, Вы писали:
FDS>>>>А другой вопрос мы не обсуждаем, т.к. обсуждается твоё утверждение о том, что декларация типа процедуры не объявляет вообще никакой информации о хранении данных. S>>>Я имел в виду хранение данных а не передачу аргументов. Почувствуй разницу.
FDS>>Передача аргументов и есть хранение данных — этих самых аргументов. Об этом и спор — при определении типа функции определяется способ передачи аргументов, т.е. способ их хранения при передаче.
T>Он говорил о том, что функция f = 15 хранит число 15. И это число можно получить посредством вызова функции.
И? Я понимаю о чём он говорит, и странно, что ты не понимаешь, о чём говорю я. Не важно, что хранит сама функция, важно лишь то, что объявление функции ничуть не меньше, чем объявление типа, предоставляет нам информацию о хранении некоторых данных (аргументов функции, адерса возврата, адреса самой функции)
Утверждать, что объявление функции не предоставляет нам никакой информации о хранении данных примерно то же самое, что утверждать, что object a нам тоже не представляет никакой информации о хранении данных. При этом этот object может хранить кучу всего разного, но факт того, что данные об этом разном не содержаться в объявлении object a никак не умаляют того факта, что объявление object a содержит информацию о хранении данных, которую использует компилятор.
С определением функции точно так же: она может возвращать лишь заголовок некоторого списка, но это не значит, что объявление функции не содержит данных о хранении некоторой информации, просто она не содержит данных именно о формате списка.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
S>>>Запиши тип функции cons, как ты его себе представляешь
FDS>>(cons x y)
S>остряк, браво!
Ну ладно, если понятней object * object -> object
Короче говоря, функция, которая принимает кортеж из двух переменных — это есть её тип
FDS>>>Передача аргументов и есть хранение данных — этих самых аргументов. Об этом и спор — при определении типа функции определяется способ передачи аргументов, т.е. способ их хранения при передаче.
T>>Он говорил о том, что функция f = 15 хранит число 15. И это число можно получить посредством вызова функции.
FDS>И? Я понимаю о чём он говорит, и странно, что ты не понимаешь, о чём говорю я. Не важно, что хранит сама функция, важно лишь то, что объявление функции ничуть не меньше, чем объявление типа, предоставляет нам информацию о хранении некоторых данных (аргументов функции, адерса возврата, адреса самой функции)
FDS>Утверждать, что объявление функции не предоставляет нам никакой информации о хранении данных примерно то же самое, что утверждать, что object a нам тоже не представляет никакой информации о хранении данных. При этом этот object может хранить кучу всего разного, но факт того, что данные об этом разном не содержаться в объявлении object a никак не умаляют того факта, что объявление object a содержит информацию о хранении данных, которую использует компилятор. FDS>С определением функции точно так же: она может возвращать лишь заголовок некоторого списка, но это не значит, что объявление функции не содержит данных о хранении некоторой информации, просто она не содержит данных именно о формате списка.
То ли речь идёт о какой-то тонкой разнице в терминах...
То ли вот, допустим есть функция
elem :: List a -> Int -> a
, которая возвращает элемент списка по индексу. Применим частичную аппликацию:
elem_12 = elem [1,2]
. Тип функции elem_12 :: Int -> Int ничего не говорит нам о том, что она хранит список. Объявление функции не содержит данных о хранении некоторой информации (списке).
Никто не утверждал, что объявление функции вообще никакой информации не содержит. (это как раз проблемы с квантором общности или как там) Он утверждал, что объявление функции не содержит информации о данных, хранящихся в замыкании.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>>>Запиши тип функции cons, как ты его себе представляешь
FDS>>>(cons x y)
FDS> FDS>Ну ладно, если понятней object * object -> object FDS>Короче говоря, функция, которая принимает кортеж из двух переменных — это есть её тип
FDS>именно описатель типа функции cons объявляет (в данном случае полностью) информацию о данных, которые хранятся в замыкании. Т.е. тип функции cons предоставляет инфомацию интерпретатору о том, какие данные нужно хранить в замыкании.
Теперь прокомментируй это, только подумай, не мог ли я сохранить a и b в файл и оставить в замыкании путь к файлу?
Здравствуйте, Temoto, Вы писали:
T>Никто не утверждал, что объявление функции вообще никакой информации не содержит. (это как раз проблемы с квантором общности или как там) Он утверждал, что объявление функции не содержит информации о данных, хранящихся в замыкании.
Объявление функции содержит информацию о данных в замыкании, так как само замыкание невозможно без декларации функции.
Кроме этого, он как раз утверждал, что объявление функции вообще не содержит информации о данных.
Смотри, какая разница
struct cons
{
object * x;
object * y;
}
или
(define (cons x y)
(define (dispatch m)
(cond ((= m 0) x)
((= m 1) y)
(else (error "Argument not 0 or 1 -- CONS" m))))
dispatch)
И объявление структуры cons, и объявление функции cons с замыканием не содержит информации о списке, т.е. совершенно эквивалентны, т.к. содержат только информацию о структуре пары (x, y) — в одном случае кортеж (x, y) определяется как структура с полями, в другом — как аргумент функции, при этом этот кортеж хранится в лексическом замыкании и определяя замыкание мы определяем, что этот кортеж будет хранится.
samius считает, что есть разница, но где? Её не видно — и там, и там для одной и той же структуры данных (списка, например) определяются одни и те же кортежи/структуры и информация представлена при объявлении функций точно такая же, как и при объявлении типа структуры.
Так где же тогда различие, объявляем мы тип данных как структуру или через лексическое замыкание?
Здравствуйте, Temoto, Вы писали:
T>Никто не утверждал, что объявление функции вообще никакой информации не содержит. (это как раз проблемы с квантором общности или как там) Он утверждал, что объявление функции не содержит информации о данных, хранящихся в замыкании.
Все верно, но я не только замыкание имел в виду. Тип IO (a, b) не говорит нам о том, откуда извлекаются данные (a,b). Они могли храниться в замыкании, или в файле, чей хэндл хранится в замыкании.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
S>>>>>Запиши тип функции cons, как ты его себе представляешь
FDS>>>>(cons x y)
FDS>> FDS>>Ну ладно, если понятней object * object -> object FDS>>Короче говоря, функция, которая принимает кортеж из двух переменных — это есть её тип S>
FDS>именно описатель типа функции cons объявляет (в данном случае полностью) информацию о данных, которые хранятся в замыкании. Т.е. тип функции cons предоставляет инфомацию интерпретатору о том, какие данные нужно хранить в замыкании.
S>Теперь прокомментируй это, только подумай, не мог ли я сохранить a и b в файл и оставить в замыкании путь к файлу?
Мог, и что? То же самое можно сделать и при описании объектного типа: я делаю два свойства определённого типа и приватный путь к файлу. Однако и в описании этого типа я не описываю формат файла. И при описании лексического замыкания, и при описании объекта мне придётся:
1. Где-то хранить путь к файлу
2. Определять так или иначе поля a и b
3. Читать данные из файла, при этом формат файла никак ни там, ни там не определяется
Т.е. в обоих случаях я определяю абсолютно равное количество информации о полях a и b и файле, независимо от того, использую я функцию или объекты со свойствами или методами-акцессорами.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Temoto, Вы писали:
T>>Никто не утверждал, что объявление функции вообще никакой информации не содержит. (это как раз проблемы с квантором общности или как там) Он утверждал, что объявление функции не содержит информации о данных, хранящихся в замыкании.
S>Все верно, но я не только замыкание имел в виду. Тип IO (a, b) не говорит нам о том, откуда извлекаются данные (a,b). Они могли храниться в замыкании, или в файле, чей хэндл хранится в замыкании.
Тип
class IO
{
property a
{...}
property b
{...}
private fileName;
}
так же ничего не говорит нам о том, откуда извлекаются данные — данные извлекаются в методах доступа как угодно: из поля, из файла, вычисляются, получаются по сети и т.п.
Кроме этого, само определение функции cons x y говорит, что данные хранятся в памяти. Если определение будет другое, то это будет говорить о том, что данные хранятся по другому, т.е. если
class IO
{
property a
{...}
property b
{...}
private fileName;
}
то
(define (cons fileName) ...)
а если
class IO
{
property a
{return _a;}
property b
{return _b;}
private _a;
private _b;
}
то
(define (cons _a _b) ...)
Т.е. в зависимости от того, как именно мы храним данные, меняются и объявления класса, и объявления функции, из которой происходит возврат замыкания — и там, и там хранятся одни и те же данные
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, Temoto, Вы писали:
T>>Никто не утверждал, что объявление функции вообще никакой информации не содержит. (это как раз проблемы с квантором общности или как там) Он утверждал, что объявление функции не содержит информации о данных, хранящихся в замыкании.
FDS>Объявление функции содержит информацию о данных в замыкании, так как само замыкание невозможно без декларации функции. FDS>Кроме этого, он как раз утверждал, что объявление функции вообще не содержит информации о данных.
Хватит меня переиначивать. Я писал:
Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных.
Тип, а не объявление
FDS>И объявление структуры cons, и объявление функции cons с замыканием не содержит информации о списке, т.е. совершенно эквивалентны, т.к. содержат только информацию о структуре пары (x, y) — в одном случае кортеж (x, y) определяется как структура с полями, в другом — как аргумент функции, при этом этот кортеж хранится в лексическом замыкании и определяя замыкание мы определяем, что этот кортеж будет хранится.
FDS>samius считает, что есть разница, но где? Её не видно — и там, и там для одной и той же структуры данных (списка, например) определяются одни и те же кортежи/структуры и информация представлена при объявлении функций точно такая же, как и при объявлении типа структуры.
Выдумываешь тезисы за меня, ну-ну...
FDS>Так где же тогда различие, объявляем мы тип данных как структуру или через лексическое замыкание?
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, FDSC, Вы писали:
FDS>>>Ну ладно, если понятней object * object -> object FDS>>>Короче говоря, функция, которая принимает кортеж из двух переменных — это есть её тип S>>
FDS>именно описатель типа функции cons объявляет (в данном случае полностью) информацию о данных, которые хранятся в замыкании. Т.е. тип функции cons предоставляет инфомацию интерпретатору о том, какие данные нужно хранить в замыкании.
S>>Теперь прокомментируй это, только подумай, не мог ли я сохранить a и b в файл и оставить в замыкании путь к файлу?
FDS>Мог, и что? То же самое можно сделать и при описании объектного типа: я делаю два свойства определённого типа и приватный путь к файлу. Однако и в описании этого типа я не описываю формат файла. И при описании лексического замыкания, и при описании объекта мне придётся: FDS>1. Где-то хранить путь к файлу FDS>2. Определять так или иначе поля a и b FDS>3. Читать данные из файла, при этом формат файла никак ни там, ни там не определяется FDS>Т.е. в обоих случаях я определяю абсолютно равное количество информации о полях a и b и файле, независимо от того, использую я функцию или объекты со свойствами или методами-акцессорами.
На бис: и как это отражено в object * object -> object?
Здравствуйте, samius, Вы писали: S>Нет статической, значит есть динамическая. А подразумевать-то конечно можно.
Для повышения уровня философичности беседы предлагаю вспомнить, что типизация затрагивает как объекты, так и их наименования в программе.
Re[22]: Объявления типов: функциональная и ОО парадигмы
Здравствуйте, samius, Вы писали:
FDS>>Объявление функции содержит информацию о данных в замыкании, так как само замыкание невозможно без декларации функции. FDS>>Кроме этого, он как раз утверждал, что объявление функции вообще не содержит информации о данных.
S>Хватит меня переиначивать. Я писал: S>
S>Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных.
S>Тип, а не объявление
Я и говорю про тип и никого не переиначиваю. Объявление функции и объявляет её тип. Если ты не способен понять, что говоря про декларацию функции я говорю именно про декларацию её типа, то не надо на меня за это ругаться — я в этом не виноват.
Именно тип функции содержит информацию о данных в замыкании, а не что-то иное в её объявлении. Именно тип функции используется для того, чтобы определить тип кортежа, который будет хранится в лексическом замыкании.
Тип функции cons содержит данные о том, что хранится в лексическом замыкании dispatch, именно тип этой функции указывает компилятору что хранится, абсолютно как если бы мы указали определение структуры и операцию new вместо вызова cons
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, Temoto, Вы писали:
T>>>Никто не утверждал, что объявление функции вообще никакой информации не содержит. (это как раз проблемы с квантором общности или как там) Он утверждал, что объявление функции не содержит информации о данных, хранящихся в замыкании.
S>>Все верно, но я не только замыкание имел в виду. Тип IO (a, b) не говорит нам о том, откуда извлекаются данные (a,b). Они могли храниться в замыкании, или в файле, чей хэндл хранится в замыкании.
FDS>Тип
FDS>
FDS>class IO
FDS>{
FDS> property a
FDS> {...}
FDS> property b
FDS> {...}
FDS> private fileName;
FDS>}
FDS>
FDS>так же ничего не говорит нам о том, откуда извлекаются данные — данные извлекаются в методах доступа как угодно: из поля, из файла, вычисляются, получаются по сети и т.п.
Вот об этом я и писал, нконец-то до тебя дошло. Не прошло и двухсот постов...
FDS>Кроме этого, само определение функции cons x y говорит, что данные хранятся в памяти. Если определение будет другое, то это будет говорить о том, что данные хранятся по другому, т.е. если
Определение? Я утверждал про тип, а не про определение.
FDS>Т.е. в зависимости от того, как именно мы храним данные, меняются и объявления класса, и объявления функции, из которой происходит возврат замыкания — и там, и там хранятся одни и те же данные
А типы могут оставаться неизменными. МОГУТ!!! и НЕ ВСЕ ТИПЫ!!! Это на всякий случай..
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
S>>>Здравствуйте, FDSC, Вы писали:
FDS>>>>Ну ладно, если понятней object * object -> object FDS>>>>Короче говоря, функция, которая принимает кортеж из двух переменных — это есть её тип S>>>
FDS>именно описатель типа функции cons объявляет (в данном случае полностью) информацию о данных, которые хранятся в замыкании. Т.е. тип функции cons предоставляет инфомацию интерпретатору о том, какие данные нужно хранить в замыкании.
S>>>Теперь прокомментируй это, только подумай, не мог ли я сохранить a и b в файл и оставить в замыкании путь к файлу?
FDS>>Мог, и что? То же самое можно сделать и при описании объектного типа: я делаю два свойства определённого типа и приватный путь к файлу. Однако и в описании этого типа я не описываю формат файла. И при описании лексического замыкания, и при описании объекта мне придётся: FDS>>1. Где-то хранить путь к файлу FDS>>2. Определять так или иначе поля a и b FDS>>3. Читать данные из файла, при этом формат файла никак ни там, ни там не определяется FDS>>Т.е. в обоих случаях я определяю абсолютно равное количество информации о полях a и b и файле, независимо от того, использую я функцию или объекты со свойствами или методами-акцессорами.
S>На бис: и как это отражено в object * object -> object?
я отписался, как это делается на примере кода.
В частности, object * object -> object никакого отношения к хранению в файле не имеет Там сигнатура object -> object, т.к. ты в замыкании будешь хранить лишь имя файла — так это там и отражается
S>Споришь сам с собой теперь
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, samius, Вы писали: S>>Нет статической, значит есть динамическая. А подразумевать-то конечно можно. MC>Для повышения уровня философичности беседы предлагаю вспомнить, что типизация затрагивает как объекты, так и их наименования в программе.
Да, "затрагивает" — хороший термин.
10 Dim IntValue = 0
20 IntValue = "хаха!"
Но я бы предпочел "некоторым образом влияет"
Re[23]: Объявления типов: функциональная и ОО парадигмы
Здравствуйте, FDSC, Вы писали:
FDS>Именно тип функции содержит информацию о данных в замыкании, а не что-то иное в её объявлении. Именно тип функции используется для того, чтобы определить тип кортежа, который будет хранится в лексическом замыкании.
Ну вот, опять.
FDS>Тип функции cons содержит данные о том, что хранится в лексическом замыкании dispatch, именно тип этой функции указывает компилятору что хранится, абсолютно как если бы мы указали определение структуры и операцию new вместо вызова cons
Покажи, как тип функции cons содержит данные о том что хранится в замыкании dispatch.
Напомню, ты привел следующий тип: object*object -> object
FDS>samius считает, что есть разница, но где? Её не видно — и там, и там для одной и той же структуры данных (списка, например) определяются одни и те же кортежи/структуры и информация представлена при объявлении функций точно такая же, как и при объявлении типа структуры. FDS>Так где же тогда различие, объявляем мы тип данных как структуру или через лексическое замыкание?
Хорошо, лично я для себя понял точку зрения обоих сторон. А ещё, что вам (обоим) интереснее продолжать спорить, нежели придти к соглашению.
Здравствуйте, samius, Вы писали:
S>Вот об этом я и писал, нконец-то до тебя дошло. Не прошло и двухсот постов...
Ты писал не об этом. Ты как раз писал о том, что есть разница между определением через функцию и определением через тип. Спорю как раз о том, что разницы нет.
FDS>>Кроме этого, само определение функции cons x y говорит, что данные хранятся в памяти. Если определение будет другое, то это будет говорить о том, что данные хранятся по другому, т.е. если
S>Определение? Я утверждал про тип, а не про определение.
Определение говорит, что данные хранятся в памяти, а тип говорит какие именно данные, так же как оператор new говорит, что нечто будет хранится в памяти, в то время как определение типа говорит, что именно будет хранится. Мне за тебя каждый мелочный логический вывод делать? Ты вообще думать сам будешь или нет? Или ты идиот и думать сам не способен?
FDS>>Т.е. в зависимости от того, как именно мы храним данные, меняются и объявления класса, и объявления функции, из которой происходит возврат замыкания — и там, и там хранятся одни и те же данные S>А типы могут оставаться неизменными. МОГУТ!!! и НЕ ВСЕ ТИПЫ!!! Это на всякий случай..
Могут, в чём вопрос? Причём останутся они неизменными и там, и там. Где же разница между определением типа данных через struct или через замыкание?
Здравствуйте, Temoto, Вы писали:
FDS>>samius считает, что есть разница, но где? Её не видно — и там, и там для одной и той же структуры данных (списка, например) определяются одни и те же кортежи/структуры и информация представлена при объявлении функций точно такая же, как и при объявлении типа структуры. FDS>>Так где же тогда различие, объявляем мы тип данных как структуру или через лексическое замыкание?
Вряд ли это можно назвать моей точкой зрения.
T>Хорошо, лично я для себя понял точку зрения обоих сторон. А ещё, что вам (обоим) интереснее продолжать спорить, нежели придти к соглашению.
Я уже согласился с тем что FDCS победил, он упрямее.
Re[24]: Объявления типов: функциональная и ОО парадигмы
Здравствуйте, samius, Вы писали:
FDS>>Тип функции cons содержит данные о том, что хранится в лексическом замыкании dispatch, именно тип этой функции указывает компилятору что хранится, абсолютно как если бы мы указали определение структуры и операцию new вместо вызова cons
S>Покажи, как тип функции cons содержит данные о том что хранится в замыкании dispatch. S>Напомню, ты привел следующий тип: object*object -> object
object*object есть кортеж, передаваемый в функцию cons как аргумент, определение этого кортежа и есть определение типа того, что хранится в замыканиии dispatch.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>На бис: и как это отражено в object * object -> object?
FDS>Что именно отражено? В этом сообщении http://rsdn.ru/forum/philosophy/3665604.1.aspx
я отписался, как это делается на примере кода. FDS>В частности, object * object -> object никакого отношения к хранению в файле не имеет Там сигнатура object -> object, т.к. ты в замыкании будешь хранить лишь имя файла — так это там и отражается
Где отражается то что в замыкании хранится имя файла?
Здравствуйте, samius, Вы писали: S>10 Dim IntValue = 0 S>20 IntValue = "хаха!"
Я этого языка не знаю и не знаю, о чем должен говорить этот пример кода, но в любом случае найдется язык с отличным поведением.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Вот об этом я и писал, нконец-то до тебя дошло. Не прошло и двухсот постов...
FDS>Ты писал не об этом. Ты как раз писал о том, что есть разница между определением через функцию и определением через тип. Спорю как раз о том, что разницы нет.
Я допускаю что она для тебя не очевидна
S>>Определение? Я утверждал про тип, а не про определение.
FDS>Определение говорит, что данные хранятся в памяти, а тип говорит какие именно данные, так же как оператор new говорит, что нечто будет хранится в памяти, в то время как определение типа говорит, что именно будет хранится. Мне за тебя каждый мелочный логический вывод делать? Ты вообще думать сам будешь или нет? Или ты идиот и думать сам не способен?
Покажи как тип говорит какие данные будут храниться в памяти.
FDS>Где же разница между определением типа данных через struct или через замыкание?
Попробуй унаследоваться от замыкания для начала
Re[25]: Объявления типов: функциональная и ОО парадигмы
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>Тип функции cons содержит данные о том, что хранится в лексическом замыкании dispatch, именно тип этой функции указывает компилятору что хранится, абсолютно как если бы мы указали определение структуры и операцию new вместо вызова cons
S>>Покажи, как тип функции cons содержит данные о том что хранится в замыкании dispatch. S>>Напомню, ты привел следующий тип: object*object -> object
FDS>object*object есть кортеж, передаваемый в функцию cons как аргумент, определение этого кортежа и есть определение типа того, что хранится в замыканиии dispatch.
т.е. ты уверен в том, что в замыкании dispatch не может храниться хэндл файла, или даже ВООБЩЕ НИЧЕГО?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
S>>>На бис: и как это отражено в object * object -> object?
FDS>>Что именно отражено? В этом сообщении http://rsdn.ru/forum/philosophy/3665604.1.aspx
я отписался, как это делается на примере кода. FDS>>В частности, object * object -> object никакого отношения к хранению в файле не имеет Там сигнатура object -> object, т.к. ты в замыкании будешь хранить лишь имя файла — так это там и отражается
S>Где отражается то что в замыкании хранится имя файла?
А где это отражается в структуре
struct cons
{
property a {...};
property b {...};
private object fileName;
}
?
Лень внимательно прочитать сообщения?
Уже писал, это
(define (cons fileName) ...)
и
struct cons
{
...
private object fileName;
}
декларирует один и тот же кортеж object — больше ничего. Файл там или нет — никто не знает. Может быть свойство a = fileName / 2, а b = fileName * 2
Обе декларации указывают на тип object как на тип храненимых данных: в одном случае прямо как тип, в другом случае через тип аргумента функции, в которой определяется замыкание
Другие два типа декларируют кортежи object*object, которые так же указывают на то, что хранится в памяти два некоторых объекта, может быть, два имени файла — отдельно для a и отдельно для b. Тип объектов и там, и там неопределён: может быть целое, а может быть — строка.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, samius, Вы писали: S>>10 Dim IntValue = 0 S>>20 IntValue = "хаха!" MC>Я этого языка не знаю и не знаю, о чем должен говорить этот пример кода
Я тоже его не знаю, но говорит пример о том, что типизация есть, а наименования могут не соответствовать.
MC>но в любом случае найдется язык с отличным поведением.
Согласен.
Здравствуйте, samius, Вы писали: MC>>Я этого языка не знаю и не знаю, о чем должен говорить этот пример кода S>Я тоже его не знаю, но говорит пример о том, что типизация есть, а наименования могут не соответствовать.
Ну я примерно про то же. Типизация наименований может оказаться ортогональна типизации объектов (значений).
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Temoto, Вы писали:
FDS>>>samius считает, что есть разница, но где? Её не видно — и там, и там для одной и той же структуры данных (списка, например) определяются одни и те же кортежи/структуры и информация представлена при объявлении функций точно такая же, как и при объявлении типа структуры. FDS>>>Так где же тогда различие, объявляем мы тип данных как структуру или через лексическое замыкание?
S>Вряд ли это можно назвать моей точкой зрения.
Да ну? Что же тогда твоя точка зрения? Ты утверждал, что различие есть, оно какое-то другое, нежели то, о котором я говорю?
Re[26]: Объявления типов: функциональная и ОО парадигмы
Здравствуйте, samius, Вы писали:
FDS>>object*object есть кортеж, передаваемый в функцию cons как аргумент, определение этого кортежа и есть определение типа того, что хранится в замыканиии dispatch.
S>т.е. ты уверен в том, что в замыкании dispatch не может храниться хэндл файла, или даже ВООБЩЕ НИЧЕГО?
Где я такое написал?
Re[27]: Объявления типов: функциональная и ОО парадигмы
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
FDS>>>object*object есть кортеж, передаваемый в функцию cons как аргумент, определение этого кортежа и есть определение типа того, что хранится в замыканиии dispatch.
S>>т.е. ты уверен в том, что в замыкании dispatch не может храниться хэндл файла, или даже ВООБЩЕ НИЧЕГО?
FDS>Где я такое написал?
Такое ты не писал, но из выделенного следует что в замыкании dispatch не может храниться ничего кроме кортежа, переданного в cons.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, Temoto, Вы писали:
FDS>>>>samius считает, что есть разница, но где? Её не видно — и там, и там для одной и той же структуры данных (списка, например) определяются одни и те же кортежи/структуры и информация представлена при объявлении функций точно такая же, как и при объявлении типа структуры. FDS>>>>Так где же тогда различие, объявляем мы тип данных как структуру или через лексическое замыкание?
S>>Вряд ли это можно назвать моей точкой зрения.
FDS>Да ну? Что же тогда твоя точка зрения? Ты утверждал, что различие есть, оно какое-то другое, нежели то, о котором я говорю?
Я утверждал что есть варианты, кроме как определения типа данных и хранения полей в словаре. И привел вариант процедурного типа данных. Если ты считаешь, что это одно и то же, то это твои проблемы.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, FDSC, Вы писали:
FDS>>>Здравствуйте, samius, Вы писали:
S>>>>На бис: и как это отражено в object * object -> object?
FDS>>>Что именно отражено? В этом сообщении http://rsdn.ru/forum/philosophy/3665604.1.aspx
я отписался, как это делается на примере кода. FDS>>>В частности, object * object -> object никакого отношения к хранению в файле не имеет Там сигнатура object -> object, т.к. ты в замыкании будешь хранить лишь имя файла — так это там и отражается
S>>Где отражается то что в замыкании хранится имя файла?
FDS>А где это отражается в структуре
Стуктура не имеет отношения к типу cons. Мой cons возвращает процедуру
FDS>Лень внимательно прочитать сообщения?
FDS>Уже писал, это FDS>
FDS>декларирует один и тот же кортеж object — больше ничего. Файл там или нет — никто не знает. Может быть свойство a = fileName / 2, а b = fileName * 2 FDS>Обе декларации указывают на тип object как на тип храненимых данных: в одном случае прямо как тип, в другом случае через тип аргумента функции, в которой определяется замыкание
FDS>Другие два типа декларируют кортежи object*object, которые так же указывают на то, что хранится в памяти два некоторых объекта, может быть, два имени файла — отдельно для a и отдельно для b. Тип объектов и там, и там неопределён: может быть целое, а может быть — строка.
Здравствуйте, FDSC, Вы писали:
FDS>Главное, что мы выяснили: система типов позволяет организованно определять группы методов и полей, чем существенно облегчает работу программисту, т.к. иначе для кадого объекта программист вынужден был бы при создании этого объекта определять весь набор методов и полей объекта вручную.
Здравствуйте, samius, Вы писали:
S>Покажи как тип говорит какие данные будут храниться в памяти.
При создании лексического замыкания сохраняются все контексты, а значит аргументы, а значит будет сохранён кортеж object * object (кортеж, который мы в качестве примера используем как аргумент функции cons, составляющую контекст лексического замыкания)
FDS>>Где же разница между определением типа данных через struct или через замыкание?
S>Попробуй унаследоваться от замыкания для начала
Не во всех языках есть наследование, да и причём тут наследование. Мы говорим не о наследовании — это синтаксис и возможности языка, а о том, что тип функции определяет тип хранимых данных так же, как это делается для типа хранимых данных при определении структуры.
Что касается наследования "попробовать", то завсегда пожалуйста
(define (cons1 x y)
(define (getpair m)
(cond
((= m 0) x)
((= m 1) y)
)
getpair
)
(define (cons2 xy z)
(define (getThree m)
(cond
((< m 2) (xy m))
((= m 2) z)
)
getThree
)
(define (cons3 x y z) (cons2 (cons1 x y) z))
Здравствуйте, samius, Вы писали:
S>>>Где отражается то что в замыкании хранится имя файла?
FDS>>А где это отражается в структуре
S>Стуктура не имеет отношения к типу cons. Мой cons возвращает процедуру
Мы говорим о различии между определениями типов-структур и типов-функций. Поэтому необходимо провести различие
FDS>>Уже писал, это FDS>>
FDS>>декларирует один и тот же кортеж object — больше ничего. Файл там или нет — никто не знает. Может быть свойство a = fileName / 2, а b = fileName * 2 FDS>>Обе декларации указывают на тип object как на тип храненимых данных: в одном случае прямо как тип, в другом случае через тип аргумента функции, в которой определяется замыкание
FDS>>Другие два типа декларируют кортежи object*object, которые так же указывают на то, что хранится в памяти два некоторых объекта, может быть, два имени файла — отдельно для a и отдельно для b. Тип объектов и там, и там неопределён: может быть целое, а может быть — строка.
S>Я их прочитал внимательно. И пожалел об этом.
Что дальше?
Re[28]: Объявления типов: функциональная и ОО парадигмы
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
FDS>>>>object*object есть кортеж, передаваемый в функцию cons как аргумент, определение этого кортежа и есть определение типа того, что хранится в замыканиии dispatch.
S>>>т.е. ты уверен в том, что в замыкании dispatch не может храниться хэндл файла, или даже ВООБЩЕ НИЧЕГО?
FDS>>Где я такое написал? S>Такое ты не писал, но из выделенного следует что в замыкании dispatch не может храниться ничего кроме кортежа, переданного в cons.
Это так и есть, если определение dispatch такое. Вот только в кортеж ты можешь запихнуть всё что угодно, так же как и в структуру с двумя полями object
Если же ты тип процедуры cons изменишь на object -> object, то сможешь передать только имя файла — т.е. структуру из одного поля.
Здравствуйте, samius, Вы писали:
S>Я утверждал что есть варианты, кроме как определения типа данных и хранения полей в словаре.
Это не так. Ты говорил, что
Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных. Тип процедуры не то же самое, что тип данных, тем не менее процедуры позволяют хранить данные в форме отличном от "словаря переменных".
а вовсе не что "есть варианты, кроме как определение типа данных и хранения полей в словаре". Не надо отступаться от своих слов. Если утверждал — значит утверждал — так на форуме записано.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Я утверждал что есть варианты, кроме как определения типа данных и хранения полей в словаре.
FDS>Это не так. Ты говорил, что FDS>
FDS>Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных. Тип процедуры не то же самое, что тип данных, тем не менее процедуры позволяют хранить данные в форме отличном от "словаря переменных".
FDS>а вовсе не что "есть варианты, кроме как определение типа данных и хранения полей в словаре". Не надо отступаться от своих слов. Если утверждал — значит утверждал — так на форуме записано.
Я до сих пор так считаю. Тип процедуры не говорит о способе хранения данных.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
S>>>Я утверждал что есть варианты, кроме как определения типа данных и хранения полей в словаре.
FDS>>Это не так. Ты говорил, что FDS>>
FDS>>Очевидно, что процедура имеет тип, но этот тип ничего не говорит компилятору/интерпретатору о способе хранения данных. Тип процедуры не то же самое, что тип данных, тем не менее процедуры позволяют хранить данные в форме отличном от "словаря переменных".
FDS>>а вовсе не что "есть варианты, кроме как определение типа данных и хранения полей в словаре". Не надо отступаться от своих слов. Если утверждал — значит утверждал — так на форуме записано.
S>Я до сих пор так считаю. Тип процедуры не говорит о способе хранения данных.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Покажи как тип говорит какие данные будут храниться в памяти.
FDS>При создании лексического замыкания сохраняются все контексты, а значит аргументы, а значит будет сохранён кортеж object * object (кортеж, который мы в качестве примера используем как аргумент функции cons, составляющую контекст лексического замыкания)
Все — это преувеличение, потому входные параметры не обязательно будут сохранены.
FDS>>>Где же разница между определением типа данных через struct или через замыкание?
S>>Попробуй унаследоваться от замыкания для начала
FDS>Не во всех языках есть наследование, да и причём тут наследование. Мы говорим не о наследовании — это синтаксис и возможности языка, а о том, что тип функции определяет тип хранимых данных так же, как это делается для типа хранимых данных при определении структуры.
FDS>Что касается наследования "попробовать", то завсегда пожалуйста
Молодец, попробовал
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Я до сих пор так считаю. Тип процедуры не говорит о способе хранения данных.
FDS>Может и тип структуры тоже не говорит?
Это зависит от структуры
Re[29]: Объявления типов: функциональная и ОО парадигмы
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>>>т.е. ты уверен в том, что в замыкании dispatch не может храниться хэндл файла, или даже ВООБЩЕ НИЧЕГО?
FDS>>>Где я такое написал? S>>Такое ты не писал, но из выделенного следует что в замыкании dispatch не может храниться ничего кроме кортежа, переданного в cons.
FDS>Это так и есть, если определение dispatch такое. Вот только в кортеж ты можешь запихнуть всё что угодно, так же как и в структуру с двумя полями object
FDS>Если же ты тип процедуры cons изменишь на object -> object, то сможешь передать только имя файла — т.е. структуру из одного поля.
Я не собирался передавать в cons имя файла, я даже не настаиваю на хранении имени файла в замыкании. Замыкания может вообще не быть и на типе процедуры cons это никак не отразится. Хотя на объявлении тела — определенно да.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, samius, Вы писали:
S>>>Я до сих пор так считаю. Тип процедуры не говорит о способе хранения данных.
FDS>>Может и тип структуры тоже не говорит?
S>Это зависит от структуры
Каким образом тип структуры может говорить то, чего не говорит тип процедуры? Мы и там, и там объявляем один и тот же кортеж, он и там, и там говорит абсолютно одно и то же.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, FDSC, Вы писали:
FDS>>>Здравствуйте, samius, Вы писали:
S>>>>Я до сих пор так считаю. Тип процедуры не говорит о способе хранения данных.
FDS>>>Может и тип структуры тоже не говорит?
S>>Это зависит от структуры
FDS>Каким образом тип структуры может говорить то, чего не говорит тип процедуры? Мы и там, и там объявляем один и тот же кортеж, он и там, и там говорит абсолютно одно и то же.
Здравствуйте, samius, Вы писали:
FDS>>При создании лексического замыкания сохраняются все контексты, а значит аргументы, а значит будет сохранён кортеж object * object (кортеж, который мы в качестве примера используем как аргумент функции cons, составляющую контекст лексического замыкания)
S>Все — это преувеличение, потому входные параметры не обязательно будут сохранены.
Это уже вопрос оптимизации. В структуре компилятор, в принципе, тоже может убрать неиспользуемые поля (конечно, если он знает, что они действительно не используются)
Re[30]: Объявления типов: функциональная и ОО парадигмы
Здравствуйте, samius, Вы писали:
S>Я не собирался передавать в cons имя файла, я даже не настаиваю на хранении имени файла в замыкании. Замыкания может вообще не быть и на типе процедуры cons это никак не отразится.
С какой стати на объявлении процедуры cons это должно отражаться?
Если ты не используешь операцию new для некоторого типа, это как-то отражается на теле объявления типа? Никак.
Здравствуйте, Temoto, Вы писали:
T>Расскажите, пожалуйста, зачем нужны системы типов. Какие задачи они решают?
T>Например, очевидно, что типы позволяют производить проверки корректности кода, диспатчить полиморфизмы типа оператора сложения (хотя здесь я не уверен).
Я, наверное, совсем закоснел, но каковы альтернативы? Что за безтиповое программирование такое?
Допустим, вы договорились, что все объекты в обязательном порядке поддерживают интерфейс диспетчеризации. Можете для любого foo вызывать Bar(), и либо он вызовется, либо выбросит исключение. Это — безтиповая система? Нет, это duck typing. Чтобы это заработало на стороне клиента, кто-то должен разработать типы, реализовать Bar(), заполнить таблицу диспетчеризации. Или, хотя бы, определить типы в рантайме (скрестить два объекта, например). Если посмотреть на промышленные реализации, то видно будет почти одни скрипты. В которые, со временем, проникают UDT
Совсем без типов я могу вспомнить только однозначную лапшу, типа ассемблера. Вот вам память, вот вам адрес, вот регистры, вот набор команд. Такую абстракцию как тип для того и придумали, чтобы уйти от этой лапши.
T>>Расскажите, пожалуйста, зачем нужны системы типов. Какие задачи они решают?
T>>Например, очевидно, что типы позволяют производить проверки корректности кода, диспатчить полиморфизмы типа оператора сложения (хотя здесь я не уверен).
SV.>Я, наверное, совсем закоснел, но каковы альтернативы? Что за безтиповое программирование такое?
SV.>Допустим, вы договорились, что все объекты в обязательном порядке поддерживают интерфейс диспетчеризации. Можете для любого foo вызывать Bar(), и либо он вызовется, либо выбросит исключение. Это — безтиповая система? Нет, это duck typing. Чтобы это заработало на стороне клиента, кто-то должен разработать типы, реализовать Bar(), заполнить таблицу диспетчеризации. Или, хотя бы, определить типы в рантайме (скрестить два объекта, например). Если посмотреть на промышленные реализации, то видно будет почти одни скрипты. В которые, со временем, проникают UDT
SV.>Совсем без типов я могу вспомнить только однозначную лапшу, типа ассемблера. Вот вам память, вот вам адрес, вот регистры, вот набор команд. Такую абстракцию как тип для того и придумали, чтобы уйти от этой лапши.
SV.>О чем же речь?
Речь о том какие задачи решают системы типов. Может быть, вы предположили, что я спросил "а нахрена вообще нужны эти глупые типы". Нет, мне правда была интересна декомпозиция на подзадачи. Мне казалось, что так я лучше смогу понять основы. И сейчас, мне кажется, что это удалось.
Пока, увы, дополнений нет, но есть несколько интересных моментов:
во-первых, действительно, можно делать диспатчинг полиморфизмов без системы типов на основе duck typing (да, в этом контексте, я не считаю duck typing за систему типов), если после создания каждого значения отдельно ассоциировать его с набором операций. Это можно до какой-то степени подсластить. Например, x = 5 будет неявно ассоциировать с этим значением все численные операторы.
во-вторых, есть т.с. процедурный способ хранения, при котором данные "скрывают" в замыканиях. Об этом есть огромная ветка спора, слава богу, наконец-то утихшая.
Здравствуйте, Temoto, Вы писали:
T>И, благодаря совместным усилиям, нам удалось выяснить по-крайней мере некоторые функции систем типов. Об этом я написал в итогах http://www.rsdn.ru/forum/philosophy/3664785.1.aspx
Пока, увы, дополнений нет, но есть несколько интересных моментов: T>во-первых, действительно, можно делать диспатчинг полиморфизмов без системы типов на основе duck typing (да, в этом контексте, я не считаю duck typing за систему типов), если после создания каждого значения отдельно ассоциировать его с набором операций. Это можно до какой-то степени подсластить. Например, x = 5 будет неявно ассоциировать с этим значением все численные операторы. T>во-вторых, есть т.с. процедурный способ хранения, при котором данные "скрывают" в замыканиях. Об этом есть огромная ветка спора, слава богу, наконец-то утихшая.
А что насчёт отделения мух от котлет в языках с более мощными системами типов? (см. пресловутые монады как минимум)
Также о зависимых типах тут писали не раз
К>А что насчёт отделения мух от котлет в языках с более мощными системами типов? (см. пресловутые монады как минимум) К>Также о зависимых типах тут писали не раз
Если вы предлагаете обсудить конкретные системы типов, то да, конечно, это я собирался делать следующим шагом.
Здравствуйте, Temoto, Вы писали:
T>Если вы предлагаете обсудить конкретные системы типов, то да, конечно, это я собирался делать следующим шагом.
А что их обсуждать, всё более менее пригодное для практического применения у Пирса в TAPL описано, а теперь Юра Бронников и русский перевод практически сделал. Что непонятно — можно спрашивать, а так абстрактные обсуждения приводит к длинному флейму непонятно о чем
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, Temoto, Вы писали:
T>>Если вы предлагаете обсудить конкретные системы типов, то да, конечно, это я собирался делать следующим шагом.
D>А что их обсуждать, всё более менее пригодное для практического применения у Пирса в TAPL описано, а теперь Юра Бронников и русский перевод практически сделал. Что непонятно — можно спрашивать, а так абстрактные обсуждения приводит к длинному флейму непонятно о чем
Здравствуйте, Temoto, Вы писали:
T>>>Расскажите, пожалуйста, зачем нужны системы типов. Какие задачи они решают?
T>>>Например, очевидно, что типы позволяют производить проверки корректности кода, диспатчить полиморфизмы типа оператора сложения (хотя здесь я не уверен).
T>Речь о том какие задачи решают системы типов. Может быть, вы предположили, что я спросил "а нахрена вообще нужны эти глупые типы".
Я ничего не предполагал, а просто прочитал, что вы написали: "Расскажите, пожалуйста, зачем нужны системы типов".
Между вопросами "Расскажите, пожалуйста, зачем нужны системы типов" и "а нахрена вообще нужны эти глупые типы" я никакой разницы, кроме накала эмоций, не вижу. "Системы типов" это и есть типы, просто сформулировано наукообразнее. Вы сами же и пишете: "Например, очевидно, что типы позволяют", то есть, показываете, что разницы между просто типами и "системами типов" не видите тоже. Что касается тождественности "нахрена" и "зачем", а также эпитета "глупые", это обсуждать будем, или как?
То же самое касается и "какие задачи решают". Это то же самое, что "нахрена?", только культурнее.
Так вот, обсуждая вопрос "нахрена?", я предлагаю сопоставить [язык/платформу/чтотамеще] с типами и без типов. По моей мысли, ответ должен последовать автоматически.
Например, нахрена нужны колеса? С колесами — повозка, карета, телега, автомобиль. Без колес — лыжи, санки, волокуша, боб. Вторые херово ездят по асфальту. Первые — по рыхлому глубокому снегу. Вот и ответ. Или, если угодно, колеса "решают задачу" замены трения скольжения на трение качения, когда это нужно.
Какие [языки/платформы/чтотамеще] без типов вы знаете? Я знаю только "лапшу". Ассемблер, или какой-нибудь древний BASIC с нумерованными строками. Впрочем, лапшу можно получить на любом языке. Остальное все типизировано насквозь, явно или неявно.
>Нет, мне правда была интересна декомпозиция на подзадачи. Мне казалось, что так я лучше смогу понять основы. И сейчас, мне кажется, что это удалось.
T>да, в этом контексте, я не считаю duck typing за систему типов
SV.>Например, нахрена нужны колеса? С колесами — повозка, карета, телега, автомобиль. Без колес — лыжи, санки, волокуша, боб. Вторые херово ездят по асфальту. Первые — по рыхлому глубокому снегу. Вот и ответ. Или, если угодно, колеса "решают задачу" замены трения скольжения на трение качения, когда это нужно.
Послушайте, я правда не хочу защищаться, дескать, что я задал такой глупый вопрос, ведь ответ очевиден. Но я был бы очень рад, если б вы что-нибудь добавили к уже имеющимся трём ответам. Конструктивности прошу.
>>Нет, мне правда была интересна декомпозиция на подзадачи. Мне казалось, что так я лучше смогу понять основы. И сейчас, мне кажется, что это удалось. T>>да, в этом контексте, я не считаю duck typing за систему типов SV.>А как сделать duck typing без системы типов?
/повторяя сказанное выше/
a = 5 # подразумевает a.__plus = int_plus, и остальные численные операторы
a + 0
К этому можно прибавить ноль и получить целое число, значит это было целое число. Duck typing.
Или вот.
xs = [] # подразумевает xs.__append = list_append, xs.__length = list_length, и остальные операторы над списками
append xs 5
Это можно передать append, значит это — список. Duck typing.
Здравствуйте, Temoto, Вы писали:
T>>>да, в этом контексте, я не считаю duck typing за систему типов SV.>>А как сделать duck typing без системы типов?
T>/повторяя сказанное выше/ T>
T>a = 5 # подразумевает a.__plus = int_plus, и остальные численные операторы
T>a + 0
T>
T>К этому можно прибавить ноль и получить целое число, значит это было целое число. Duck typing.
T>Или вот. T>
T>xs = [] # подразумевает xs.__append = list_append, xs.__length = list_length, и остальные операторы над списками
T>append xs 5
T>
T>Это можно передать append, значит это — список. Duck typing.
Как раз систему динамических проверок в рантайме вроде "можно ли прибавить" и "можно ли передать" общепринято называть динамической типизацией. Неважно, используются ли тэги типов, или нечто большее вроде словарей полей и методов.
С тем что термин неверен, согласен и автор TAPL-а. Но он тут же пишет что употребление термина "динамическая типизация" является стандартым.
Здравствуйте, Temoto, Вы писали:
T>Послушайте, я правда не хочу защищаться, дескать, что я задал такой глупый вопрос, ведь ответ очевиден. Но я был бы очень рад, если б вы что-нибудь добавили к уже имеющимся трём ответам. Конструктивности прошу.
Почему вопрос глупый? Глупо делать вид, что вы его не задавали, а сам вопрос очень даже не глупый.
Например, я не уверен, что знаю правильный ответ. Поскольку кроме "лапши" ничего безтипового я больше не знаю, то мой ответ — типы помогают "разделять и властвовать". Это очень древний механизм, который появился на ранних этапах эволюции программирования. Как я себе это представляю: понадобилось сделать косвенную адресацию более безопасной — ввели типы указателей. Не ввели бы, например, в C — и код *(0x00ffffff) = 0; работал бы "на ура". Поверх плоской памяти наложили паттерны, кускам которых дали имена — получили структуры/юнионы. При рассмотрении куска памяти как паттерна такого-то потребовали в явном виде указывать, что с ним можно делать — получили классы и ООП. Лишили возможности рассматривать кусок памяти иначе, чем как паттерн и прибили к нему гвоздями информацию об этом паттерне — получили C# . Стали рассматривать память, которая хранит код, а не данные, тоже через паттерны — получили ФП (типы-функции).
Пишут, что введение типов решает четыре базовых задачи:
Безопасность. Многие бессмысленные применения машинных инструкций запрещаются. Иллюстрируется это примером 3 / "Hello, World". Оптимизация. Я не согласен (или не понял). Выравнивания и без типов прекрасно делаются. Документирование. Применение типов — форма документации. size_t вместо int, например. Или имена enum fields. Модульность. Типы позволяют думать о памяти как об объектах (string вместо набора символов) и делать интерфейсы.
В целом, все переплетено и вполне сводится к "разделяй и властвуй". Вроде, ничего неожиданного.
SV.>>А как сделать duck typing без системы типов?
T>/повторяя сказанное выше/ T>
T>a = 5 # подразумевает a.__plus = int_plus, и остальные численные операторы
T>a + 0
T>
T>К этому можно прибавить ноль и получить целое число, значит это было целое число. Duck typing.
T>Или вот. T>
T>xs = [] # подразумевает xs.__append = list_append, xs.__length = list_length, и остальные операторы над списками
T>append xs 5
T>
T>Это можно передать append, значит это — список. Duck typing.
А где определены __plus и __append? Вот если вам удастся привести пример каких-то подобных вещей совсем без типов, это будет интересно. Типа такого, знаете, набора команд, который был бы безопасен в применении, документировался сам собой и выстраивался в модульные системы.
Здравствуйте, SV., Вы писали:
SV.>В этом месте я сверился с википедией: http://en.wikipedia.org/wiki/Type_system#Fundamentals
SV.>Пишут, что введение типов решает четыре базовых задачи:
SV.>Безопасность. Многие бессмысленные применения машинных инструкций запрещаются. Иллюстрируется это примером 3 / "Hello, World". SV.>Оптимизация. Я не согласен (или не понял). Выравнивания и без типов прекрасно делаются. SV.>Документирование. Применение типов — форма документации. size_t вместо int, например. Или имена enum fields. SV.>Модульность. Типы позволяют думать о памяти как об объектах (string вместо набора символов) и делать интерфейсы.
SV.>В целом, все переплетено и вполне сводится к "разделяй и властвуй". Вроде, ничего неожиданного.
Сравнил с введением в TAPL
Первым пунктом идет Выявление ошибок
Вторым Абстракция — в качестве стимула для поддержания дисциплины программирования. В этом же пункте упоминается Модульность.
Затем Документация
Четвертым Безопасность языков — здесь проще привести примеры, что Безопансые — ML, Haskell, Java, LISP, Scheme, Perl, Postscript и т.п. Небезопансые — C, C++ и т.п. Эффективность — упоминаются избегание множества динамических проверок, оптимизации на основе информации, собранной процедурой проверки типов, замена вызовов сборщика мусора стековыми операциями... Другие приложения — упоминаются области безопасности компьютеров и сетей, инструменты анализа программ помимо компиляторов, автоматическое доказательство теорем системы типов, интерес специалистов по БД, вычислительная лингвистика.
SV.>Например, я не уверен, что знаю правильный ответ. Поскольку кроме "лапши" ничего безтипового я больше не знаю, то мой ответ — типы помогают "разделять и властвовать". Это очень древний механизм, который появился на ранних
[...]
Что вполне вписывается в первый пункт — проверка корректности. Спасибо.
SV.>>>А как сделать duck typing без системы типов?
[...]
SV.>А где определены __plus и __append? Вот если вам удастся привести пример каких-то подобных вещей совсем без типов, это будет интересно. Типа такого, знаете, набора команд, который был бы безопасен в применении, документировался сам собой и выстраивался в модульные системы.
a = 5 # подразумевает a.__plus = int_plus, и остальные численные операторы
xs = [] # подразумевает xs.__append = list_append, xs.__length = list_length, и остальные операторы над списками
Вот здесь и определены. Любое значение (объект) это словарь, обращение к полям через точку.
append вызывает x.__append (то есть встроенную функцию list_append). А list_append оперирует низкоуровневыми структурами, это уже реализация языка.
Я не обещал безопасности, документирования, ничего что написано в википедии. Я привёл пример диспатчинга полиморфизмов, duck typing, без типов.
Здравствуйте, Temoto, Вы писали:
T>Я не обещал безопасности, документирования, ничего что написано в википедии. Я привёл пример диспатчинга полиморфизмов, duck typing, без типов.
Что ж вы остановились на одном плюсе? Приводите дальше. Раз и навсегда, чтобы покрыть все будущие нужды. И не пришлось бы вводить "глупые" типы, чтобы программист мог повторить этот фокус своими руками.
T>>Я не обещал безопасности, документирования, ничего что написано в википедии. Я привёл пример диспатчинга полиморфизмов, duck typing, без типов.
SV.>Что ж вы остановились на одном плюсе? Приводите дальше. Раз и навсегда, чтобы покрыть все будущие нужды. И не пришлось бы вводить "глупые" типы, чтобы программист мог повторить этот фокус своими руками.
Мне решительно непонятно чего вы от меня хотите. Вы неправильно поняли мой изначальный вопрос. Я вам пояснил, что я не против типов. Но вы говорите, что прочитали всё как надо и спорите с выдуманными тезисами. И сейчас опять то же самое. Я не утверждал того с чем вы спорите (обвиняете, утверждаете, тот-глагол-который-здесь-уместен). Попросите кого-нибудь рядом перечитать наш диалог и, надеюсь, всё станет на свои места.
Здравствуйте, Temoto, Вы писали:
T>Мне решительно непонятно чего вы от меня хотите.
http://en.wikipedia.org/wiki/Duck_typing это не только вызов кряканья, но и создание разнообразной живности (не только уток, но и мутированных ежей, ужей и мышей), которая умеет крякать по-утиному. У вас утка, которая умеет складывать, реализована за кулисами и, типа, убрана из рассмотрения. Так сложения, извините, мало. Если это язык, ЧТО на нем можно будет сделать еще?
Что касается изначального вопроса, который я "не понял". Вот вам не вопрос, а утверждение — без типов нельзя сделать вообще ничего сложнее ассемблера и примитивнейших скриптов, а потому перебирать отдельные задачи, решаемые типизацией, не имеет смысла. Хотите — оспаривайте.
)
