Здравствуйте, 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-а. Но он тут же пишет что употребление термина "динамическая типизация" является стандартым.
