Здравствуйте, geniepro, Вы писали:
VD2>> Ага, проще уговорить себя в том, что вокруг одни недоумки, чем признать очевидное.
G>А вот этого я не утверждал. G>Однако, ну сколько людей из отметившихся в этой теме являются глубокими теоретиками в области ФП и ООП?
Ты считаешь, что, чтобы ответить на вопрос Влада, необходимо быть профессором семи университетов?
G>Тот же Хаскелл — не так уж он и чист, как об этом твердят.
Если под "чист" имеется в виду чистота в смысле отсутствия побочных эффектов — чист на 100%.
Здравствуйте, BulatZiganshin, Вы писали:
G>> Clu, Ada-83, Modula-2 считались "объектными" языками
BZ> честно говоря, такую характеристику впервые слышу. подозреваю, что это то же самое, что АТД-язык?
Так назывались языки, в которых были АТД (сокрытие информации), но не было возможности организовывать иерархии типов объектов с перегрузками и прочим ООП...
То есть, недо-ООП...
. Иди поспорь. За одно поспорь с википедией и половиной мира.
VD>>Что за языки имеются в виду? В Симуле концепция АТД вроде поодериживалась.
BZ>каким образом?
Прямым. Созданием интерфейсных классов.
BZ>ты её вообще отличаешь от концепции наследования?
Ссылку на вики тебе дали. Кури.
VD>>ОК. Допустим так. Ну, и что по-твоему, АТД не были промежуточным этапом на пути к ООП? Или ООП не включила эту концепцию в себя?
VD>>А вот где эта концепция в ФП я лично не вижу.
BZ>бу-га-га. значит, если в ФП что-то не сразу появилось — то эта концепция для ФП не естественна?
Проблема в том, что в концепциях именно ФП нет ни АТД, ни интерфейсов, ни да вообще ничего что могло бы дать чистую абстракцию. В нем одна абстрация — сигнатура фукции. Хорошая конечно абстракция, но не везде ее хватает.
BZ> а если в ооп что-то не сразу появилось — значит оно было только промежуточный звеном на пути развития ооп? а симула в таком разрезе вообще не была ооп языком?
В ООП эта концепция была, есть и будет есть (с).
ЗЫ
В общем, конструктива — 0. Я завязал с тобой общаться. Будут умные мысли на этот счет, подходи, так... всех благ в личной жизни.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>вы так и будете продолжать говорить о разных вещах? мы же с Сергеем давно разобрались — я говорил про method override, при котором невозможен диспатчинг по типу возвращемого объекта ввиду особенностей ООП
При переопределении (override) не появляется новых методов. Так что говорить о каком-то там выборе вообще бессмысленно. Как в прочем бесмысленно говорить о "диспатчинге" так как при перегрузке производится выбор из множества имен (т.е. статическое действие), а не перача управления в рантайме.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>ФП? Замечательно. Что в нем есть если отбросить фанатство и кастовость? Паттерн матчинг и алгебраические типы? Замечательно! Они позволяют более естественно решать некоторые задачи. Значит будем их применять. В прочем, к ФП как таковому они отностяс только потому, что были изобретены в рамках ФЯ. Рекусия? Помилуйте, я ее в С 15 лет назад использовал. Оптимизация концевой рекурсии? Замечательно! Берем! Хотя это всего лишь оптимизация компилятора, ну да ладно. Неизменяемые переменные? Хорашая идея. Тоже берем, при условии, что это не единственный способ работы. VD>Ну, а зацикливание на приемах/фичах исключительно ФП мне лично не нравится. Темболее, что ФП явно ограничен. Лично мне нужен быстрый код. Жить на списках и повсеместной ленивости мне не интересно.
Забавно, что самое главное, что есть в ФП ты не рассмотрел.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, geniepro, Вы писали:
G>>Кстати, я где-то встречал упоминание, что Олег Киселёв реализовал вычисление факториала на классах типов, однако так и не нашёл этого кода.
D>Не Олег, но... D>здесь
Здравствуйте, VladD2, Вы писали:
VD>В нем присуствует расширение которое не имеет отношния к ООП. Хаскель обладает мощьной стистемой типов которая очень похожа на то, что мы выидим в ООП. Только в ООП это прямая заслуга парадигмы, а в Хаскеле исключительно его разработчиков.
Хиндли и Милнер разрабатывали Хаскель?
VD>Меня больше занимает другой вопрос. Имеет ли смысл вообще рассматривать ФП как отдельную прарадигму. Похоже, что в чистом виде она ущербна, и имеет смысл только в купе с некой иделогией типов которая в чистом виде имеется только в ООП.
Это вопрос взгляда. Чем больше я читаю теорию типов, тем больше убеждаюсь в ущербности именно ООП.
Чистый ООП — это объекты, получающие сообщения, — эдакий смолтолк без блоков, и даже наследования, он решает поставленную тобой проблему. Тем не менее каждый ОО язык расширяет эту схему. Точно так отличаются ФЯ от ФП. Чистое (в смысле "только") ФП — это лямбды.
Здравствуйте, VladD2, Вы писали:
VD>В общем, вопрос можно закрывать. Лично мне все стало полностью ясно. С этого времени я буду отровенно ражать над пропагандистами "чистого" ФП. Я и раньше предпологал, что чистый ФП — это вакуумный сфероконяра, а тепель я в этом просто уверен.
Откровенно рАжать над пропагандистами?? Боюсь даже представить себе эту сцену.
Здравствуйте, lomeo, Вы писали:
L>Возможно, я чего то не знаю. Правильно ли я понимаю, что можно написать функцию (аналогов в чистом ОО нет — что то вроде метода класса, вызываемого без указания этого класса), которая, в зависимости от контекста вызова вернет нам 1 или 'a'?
Процесс вызова метода в IL выглядит так. Мы помещаем параметры возова в стек виртуальной машины. Далее указываем инструкцию call или callvirt. Затем мы указываем полную сигнатуру метода который хотим вызвать.
Например:
L>Т.е. 41 + foo() будет 42, а putch(foo()) выведет нам на консоль 'a'?
В такой постановке задачи ответ будет — да.
Но при приведенной тобой записи компилятор языка программирования должен уметь понять, что за сигнатуру метода нужно засунуть в IL. Компилятор C# туп и не может это сделат. А вот алгоритм вывода типов Немерле в 99% случаев способен вывести тип, так как делает это из всего использования. В первом случае он увидит, что есть две сигнатуры:
int foo()
char foo()
и отложит разрешение до лучших времен. Потом он увидит сложнеие с int и снова попробует произвести разрешение. В этот раз оно пройдет удачно, так как подойдет только первая сигнатура.
В о втором случае все будет то же самое, но вместо сложения с целым будет использована информация о параметрах фукнции putch.
Самое смешное, что даже компилятор C# "балуется" разрешением вызова по возвращаемому значению когда он подбирает правлиьный оператор приведения типов.
Мы узнали о том, что Немерловый компилятор может подобные финты ушами делать когда правился баг с разрешением прегрузки. Непрле делал ее не как Шарп. В процессе правки кто-то заметил, что если не дописать некоторое ограничение, то компилятор допускает перегрузку по возвращаемому значению. Но так как это на фиг никому было не нужно ее закрыли.
ЗЫ
Блин. Что-то я снова погряз в форумах. Пора нафиг от сюда валить .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, awson, Вы писали:
A>Хоть горшком назови. Напишите мне на Nemerle аналог printf со статической проверкой типов без синтаксического оверхеда при вызове и без метапрограммирования. Если напишете, я признАю, что нужного Вам метапрограммирования классы типов не обеспечивают.
Для этого достаточно перегрузки. Метод Console.WriteLine так и делает.
Но вообще для этой задачи какраз метапрограммирование подходит хорошо. Но ты же говорил про вызов метода, а не про проверку соответствия списка параметров некому шаблону.
VD>>Это — да. Но исключения есть: VD>>1. Лисп. VD>>2. Руби. VD>>3. Питон. VD>>4. Немерле. VD>>... VD>>Я уже не говорю о разных эксперементах вроде ТемлеэйтХаскеля, МетаМЛ-я и т.п.
VD>>Все живые языки с не плохими реализациями.
A>Вы вообще читаете текст на который отвечаете? Я пишу "кроме лиспообразных", Вы в ответ — "Но исключения есть: 1. Лисп."
А пункты 2-4 ты как бы незаметил?
A>На питон есть стандарт? На руби есть стандарт? На немерле есть стандарт и больше одной имплементации???
Есть стандарты де факто. А Лисп хоть формально стандартизирован, но я не смог скопилировать половину приперов на разных компиляторах которые казалось бы поддерживали стандарт CL.
Так что в твоем привязывании к стандарту я вижу попытку зацепиться за что-то чтобы обосновать неверное утверждение.
Наличие единой реализации — это намного лучше стадарта. Отчасти потому Руби и Питон во всю использются на практике, а Лисп при пенесометрии.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ> была целая бмблиотека матвычислений. typenats, afair
TypeNats
Description
This module defines type-level natural numbers and arithmetic operation on them including addition, subtraction, multiplication, division and GCD.
Numbers are represented as a list of binary digits, terminated by a distinguished type Z. Least significant digits are outermost, which makes the numbers little-endian when read.
Because a binary representation is used, reasonably large numbers can be represented. I have personally done tests with numbers at the order of 10^15 in GHC. However, larger numbers require the GHC '-fcontext-stack' option. For example, the test suite sets '-fcontext-stack64'.
Because of the limitations of typeclasses, some of the algorithms are pretty messy. The division algorithm is particularly ugly. Suggestions for improvements are welcome.
Впечатляет...
А что за limitations of typeclasses имеются в виду?
Здравствуйте, geniepro, Вы писали:
L>> Если под "чист" имеется в виду чистота в смысле отсутствия побочных эффектов — чист на 100%.
G>Боюсь, это миф... Или, как написал мне как-то Булат, "наш агитпункт".
G>Хотя в стандарте Хаскелл-98 нет, но реально во всех реализациях Хаскелла имеются те же самые IORef, MVar, unsafePerformIO...
IORef, MVar — не делают функции грязными. unsafePerformIO — увы.
Здравствуйте, geniepro, Вы писали:
G>Хотя в стандарте Хаскелл-98 нет, но реально во всех реализациях Хаскелла имеются те же самые IORef, MVar, unsafePerformIO...
IORef и MVar — чистые на 100%. unsafePerformIO... — нет. Но так и RTS написана на C. Что теперь делать? Можно допустить формально грязные вещи, если вы покажете, что результат чист, (Киселев здесь употреблял термин trusted kernel). В библиотеках, входящих в поставку GHC, unsafePerformIO применяется безопасно. При практическом програмировании на GHC вы всегда можете исходить из презумпции абсолютной чистоты, если САМИ не применяете вовсе или применяете unsafe... безопасно. Это все очевидные вещи, тут не о чем говорить.
Здравствуйте, VladD2, Вы писали:
VD>Так что в твоем привязывании к стандарту я вижу попытку зацепиться за что-то чтобы обосновать неверное утверждение.
Да вовсе нет. Просто для GHC наличие Template Haskell было указано как "нестандартное расширение", на что я и возразил резонно, что у большинства воображаемых конкурентов нет даже ситуации "стандарт + несколько реализаций".
Здравствуйте, VladD2, Вы писали:
VD>Процесс вызова метода в IL выглядит так. Мы помещаем параметры возова в стек виртуальной машины. Далее указываем инструкцию call или callvirt. Затем мы указываем полную сигнатуру метода который хотим вызвать.
Прикольно, т.е. теоретически можно вывести и запихнуть, но вот с полиморфизмом (когда от них зависят другие функции) уже не сработает, потому что надо пихать сразу. Но хоть так, интересно.
VD>ЗЫ
VD>Блин. Что-то я снова погряз в форумах. Пора нафиг от сюда валить .
