Здравствуйте, Klapaucius, Вы писали:
K>Как сделать классы типов на макросах?
Их и без оных не сделать если базова система типов на это не рассчитана.
Вообще, конечно на макросах можно сделать не все. Но и не нужно все делать на макросах. Но то что делается на них, по-моему, не стоит хардкодить в компиляторе.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
EC>>>Вот если бы LINQ приделали на макросах это был бы убийственный аргумент. WH>>Если бы оно было сильно надо...
VE>Ну уж? Не надо лукавить. Я даже переписку читал, где авторам языка предлагали добавить новый тип макросов специально для того, чтоб можно было реализовать тот же LINQ. VE>IT не раз говорил, что в таком случае стоит признать, что макросы не могут создавать нормальные DSL, и что все обходные пути реализации LINQ (как то <# select... #> и прочее) — это фигня, а не решение.
VE>А потом решили, что оно не сильно надо. Понятно.
Есть огромная разница между тем можно ли полностью повторить синтаксис другого языка и тем можно ли реализовать фичу на макросах. Вопрос был можно ли реализовать фичу на макросах. Ответ — да. Если вопрос будет можно ли при этом полностью повторить синтаксис Шарпа, то пока ответ будет нет. Но это только пока .
Собственно ЛИНК и будет реализован на макросах. Просто пока до него руки не доходят. То что хочет ИТ есть некоре расширение макросов чтобы они могли полностью брать управление разбором токенов в свои руки и допускать любую модификацию языка. Сейчас же любой макрос обязан удовлетворять некоторым требования Немерле. Среди требований обязательная парность скобок и привязка разделителей к скобкам (например, внутри крулгых скобок разделители должны быть запятыми, а внутри фигурных точками с запятой).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Кстати, этот SupportRecolation (если это то, о чём я думаю) — уже обсуждался. Насколько я помню, там показывалось, что на некоторых языках это можно красиво сделать без макросов. И то, что здесь он был сделан на макросах, может говорить о некоторых недостатках (ну или по крайней мере отсутствии некоторых фич) в языке.
Обсуждался. Вот только аргумента что для конкретных мест нужен анали другой стороной принято не было, так как если его принять, то без генерации кода обойтись бы уже не получилось. Плюс, Хаскелевская фунция сама может быть создана на базе макроса.
Так что не надо.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Use the limited ability described here to connect directly to C++ functions and classes.
AF>Вот этот пункт — это интересно, не знал что такая возможность есть. Но реально она настолько "limited", судя по описанию, что использовать ее практически нереально.
Реально ее просто нет. Это планы, как я понял. Но если их реализуют, то это уже будет отличным ходом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Я по секрету сознаюсь, что этот компилятор с Модулы уже на пределе допустимой сложности, и я бы чувствовал себя совершенно неспособным создать хороший компилятор для Ады.
Т>Н. Вирт
И ведь не врет ведь! Действительно компилятор для Ады он не сделал!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Собственно, против этого я и не спорил (по крайней мере здесь ). Изначально я хотел узнать, почему это будущее есть только у языков, построенных по принципу Nemerle.
А чего тогда осбуждашь совсем другое?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Есть огромная разница между тем можно ли полностью повторить синтаксис другого языка и тем можно ли реализовать фичу на макросах. Вопрос был можно ли реализовать фичу на макросах. Ответ — да. Если вопрос будет можно ли при этом полностью повторить синтаксис Шарпа, то пока ответ будет нет. Но это только пока .
Конечно, но вся соль синтаксического сахара ( ) как раз в синтаксисе. А LINQ все-таки сахар. Фича — это call/cc, type classes, которые макросам неподвластны. Хотя кто знает.
Здравствуйте, VladD2, Вы писали:
VD>Что ты вообще сказать то хочешь этими примерами? Что макросы не всесильны? Ну, это езжу понятно. От этого что-то меняется?
Я просто тихо мирно именно это и сказал, что макросы не всесильны. Из-за чего WolfHound вцепился в меня мертвой схваткой
Здравствуйте, WolfHound, Вы писали:
EC>>Я примерно представляю для чего они нужны, но было сказано, что возникла реальная необходимость, и как только захотелось узнать подробности — так сразу НДА и прочие отмазки. WH>Так эта... см код компилятора там их полно... например SupportRelocation
Ты или коротко поясняй или ссылку давай — я без понятия, что это за штука. Ты ведь не ожидаешь от читателей знания поторохов компилятора?
EC>>Вот если бы LINQ приделали на макросах это был бы убийственный аргумент. WH>Если бы оно было сильно надо...
Так оно надо хоть зачем-нибудь, за пределами задач решаемых при создании компилятора?
Здравствуйте, VladD2, Вы писали:
VD>В схеме всем плевать на производительность, от того и сделано. Для аттически типизированного языка это смысла не имеет, так как все выродится в файберы которые уже сто лет как есть. Континюэшоны действующие на метод есть, это и есть итераторы. Сделать континюэшоны для класса или даже для ряда классов можно. Возможно если будет время то займусь этим.
Я пока только изучаю продолжения, но кажется файберы тоже только частный случай, они без проблем на call/cc реализуются.
FR>>То есть все что не можем сделать на макросах зло, понятно.
VD>В том то идело, что можно. Только не нужно. О том как реализовать мультиметоды была тема в немерловой конфе. Автор вопроса согласился с камилом, что на макросах все прекрасно реализуюется. Просто учитывая, что есть паттерн-матчинг решающий проблему множественной динамической димпетчиризации, особой необходимости именно в мультиметодах нет. По существу мультиметоды и есть только в КЛОС-е который является макробиблиотекой для ЛИСП-а в котором оных нет. И есть они в КЛОС-е в не малой мере потому, что в ЛИСП-е нет паттерн-матчинга (а потребность в мультидиспатче есть).
Я тоже думаю что можно, их даже на метаклассах питона можно реализовать, но полностью ОО систему из CLOS думаю будет тяжеловато повторить (то что не надо понятно )
FR>>Сравнивай с хаскелем или клейном.
VD>Сравнивл. Разницы не обнаружил. Просто другие умолчания. В нем по умолчанию все лениво, а в Немерле нет. Вот тормозит Хаскель по черному (чтобы его фанаты не говорили) — это да.
Я вижу разницу, в немерле как и в Ocaml (lazy) и в схеме получается слабее.
FR>>>>думаю в этот список можно еще немало вещей добавить и со временем список будет только расти. WH>>>Попробуй.
FR>>А зачем, ты скажешь или не нужно или приведешь частично коряво сделаную реализацию и скажешь что этого достаточно. Это все равно что обчитавшемуся Александреску говорить что boost::lambda корявое убожество.
VD>Если честно, то с тобой вообще разговаривать забавно. Ты как и другие "критики" сами не пробовавшие то о чем рассуждаешь выискиваешь в отдельных языках отдельные фичи которые или не сделаны, или сделаны по другому и на основании этого пыташся найти фатальный недостаток. Вот только проблема в том, что язяки где эти фичи есть обладают куда большим количеством недостатков. Многие из которых действительно фатальны. Вот те же Ди и С++, например в подметки Немерлу не годятся с точки зрения удобства программирвоания. Они вообще только в битовыжимании сильны. Но это же ты в рассчет не берешь?
Здравствуйте, VoidEx, Вы писали:
VE>И как, позвольте поинтересоваться, amb реализуется на макросах? VE>А еще хочется узнать, как реализуется на макросах LINQ.
Молча стиснув зубы. Последнее увидите сами. Первое мне без надобности.
ЗЫ
Я правильно понял, что по реализуемости мультиметодов и т.п. вопрос отпал?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
VD>>У D есть автор пашуший на фул-тайм и при этом сделавший язык уступающий Немерлу почти во всем. Кстати, Немерле поддерживает два вида контрактов. Первый как в Ди проверяется в рантайме, а торой как в Sign# по возможности проверяется во время компиляции. Так что и здесь Ди лузер.
E>Смысла этой сентенции не уловил,
Объсяняю доходчиво. Автор Ди пока еще слов таких как теорем прувер не знает. Стало быть говорить о поддержке этого в Ди пока бессмысленно.
E>тем более, что для проверки контрактов Spec# использует сторонний инструмент, реализованный другой компанией на Java.
Какая разница, что там используется? Оно есть и работает. И Немерле это дело пддерживает благадоря тем же макросам, а Ди не поддерживает и в билжайшие 5 лет вряд ли будет поддерживать.
К сведению, Москаль перед переходом на работу в МС работал над теорем прувером. И писал он его на Немерле. Почти уверен, что взяли его в МС как раз в связи с этой работой.
E>>>Так что хотелось бы увидеть обоснованный какими-либо фактами и примерами взгляд на то, что только микроядро и метапрограммирование сейчас являются правильным подходом к разработке современных языков программирования.
VD>>А зачем? Такого никто не утверждал.
E>Никто? E>
E>А настоящее будущее — за Немерле или другими языками, которые будут устроены по тому же принципу.
E>Хотя потом выяснилось, что это было даже не утверждение, а частное мнение.
А где в этих словах "только микроядро и метапрограммирование сейчас являются правильным подходом"?
Зачем вообще подменять обсуждаемую тему?
VD>>Но то что это полезные вещи даже ты наверно не возьмешся опровергать. Не так ли?
E>Когда этими вещами пользуются разработчики компилятора -- мне фиолетово. E>Когда этот инструмент предоставляется в руки прикладных программистов, то их полезность я бы поставил под большое сомнение.
А как же твои рассказы о конфигах на Руби? Это то самое метапрограммирование и есть. Тебе в руки попался инструмент с гибким синтаксисом и метавозможностями и ты использовал его для того, на что он и рассчитан то не был. Или это ты тоже поставишь под большое сомнение?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>По личным опыту кривая обучения намного круче чем для ООП, теория сложнее и более разработана, чтобы реально понимать нужно прилагать больше умственных усилий чем при изучении ООП.
Это личное мнение, а не обоснование. Мое мнение, что дело в тех кто учит.
VD>>Нет в ФП никаких специальных средств проектирования. ФП это развитие идей структурного программирования. "Сахар", можно сказать (чур меня ).
FR>Gaperton со своей Problem K очень наглядно показал что есть.
Чушь.
FR>Мне кажется ты просто не докурил ФП.
Это твои проблемы, что тебе там кажется.
FR>Я вот тихонько докуриваю но идет туго
Это видно. Надо не курить, а пользоваться. Тогда понимание придет само собой.
- А это курица?
— Не это хавается!
FR>>>Угу только по моему в резулmтате получаются больше "пользователи сахара"
VD>>Если переведешь это предожение на Русский, то можно будет осбудить его.
FR>Очень просто, используются фичи (практически только локальные) из ФП помогающие делать код короче, при этом все, часто даже то, что легко и красиво можно сделать функционально, пишется в смешаном функционально-императивном стиле. Функциональная декомпозиция вообще не применяется. Я не говорю что это одназначно плохо.
Бред, да и только. Тут и обсуждать не чего. Так что ты дава, докуривай. А потом еще раз обсудим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Я пока только изучаю продолжения, но кажется файберы тоже только частный случай, они без проблем на call/cc реализуются.
Файберы работают вне языков. Так что это очередная ерунда. Ты можешь написаать call/cc который я смогу использовать из Шарпа? Файберы это те же потоки, только без раздачи квантов времени и с ручным переключением.
FR>Я тоже думаю что можно, их даже на метаклассах питона можно реализовать, но полностью ОО систему из CLOS думаю будет тяжеловато повторить (то что не надо понятно )
Можно и полну. Вот только зачем если в дотете уже готовая есть?
Вообще в Лиспе макросы очень пожожи. Так что противопоставлять их бессмысленно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VoidEx, Вы писали:
VE>Конечно, но вся соль синтаксического сахара ( ) как раз в синтаксисе. А LINQ все-таки сахар. Фича — это call/cc, type classes, которые макросам неподвластны. Хотя кто знает.
Очередно обсуждение того о чем ничего не понимашь. Мне это надоело. Бредьте в одиночистве. Когда сделаем этот самый ЛИНК не забудьте сказать, что были не правы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Именно. Вот только у полноценной компилируемой программы таким контекстом является вся память включая стеки потоков. Продолжения в любом языке "неполноценны", так как не делают слепок процесса. Итераторы это частный случай. Конечно он не воспроизводит все паттерны использования континюэшонов, но больую часть их покрывает. Главное, что он позволяет развернуть управление.
Не надо меня за совецкую власть агитировать
VD>Ну, а полные континюэшоны — это файберы (или зеленые потоки как их еще называют). Их можно использовать уже ейчас. Они будут медленее континюэшонов в некторых языках, так как сохраняют больше данных. Но при этом сам язык будет быстрее, так как он компилируемый. В прочем, виртуальная машина позволяет и ограничить контекст. Но это сложна работа. Когда нибудь ее сделают. И работать это решение будет для всех языков дотнета или явя. В Яве подобные работы уже ведутся. Есть котнинюэшон-серверы.
Файберы тоже частный случай.
FR>>Здесь также, порядок тоже можно сделать естественный по мере объвления.
VD>Какого к черту объявления? У тебя сборка может динамически подгрузиться. И в ней может быть расширение мультиметода. В общем, не веди беседы о том, в чем ни в зуб ногой. VD>Кроме не однозначностей я тебе еще две проблемы раскро: VD>1. Производительность мультиметодов обратно пропорционально количеству параметров. Хроший универсальный алгоритм тут не существует. VD>2. Проблемы с днимической загрузкой и безопастностью.
Ну значит запишем тогда что фиг реализуешь на макросах
FR>>Ну бывают и полиморфные варианты и их паттерн матчинг, там точно такие же проблемы. FR>>Кстати немерле подерживает полиморфные варианты? И если нет (или бы не подерживал) то можно их прикрутить макросами?
VD>Все варианты полиморфны априори. Есть понятие GADT. Вот их Немерле не поддерживает по политическим соображениям (это к ошибкам приводит). За то он позволяет наследовать варианты от классов. Вот только боюсь, что для тебя это все птичий язык.
Конечно, куда уж мне, у меня от простого call/cc мозги закипают
FR>>Мне сейчас все хватает, я же Блаб в продолжениях
VD>И не только в них.
Здравствуйте, VladD2, Вы писали:
VD>Файберы работают вне языков. Так что это очередная ерунда. Ты можешь написаать call/cc который я смогу использовать из Шарпа? Файберы это те же потоки, только без раздачи квантов времени и с ручным переключением.
При чем тут реализация?
Тот же call/cc интересен тем что через него легко реализуются такие вещи которые в языках не подерживающих продолжения можно только хардкорно сделать. Вообще их интересно изучить даже только ради этого. В общем очень мощная штука, хотя склероз подсказывает что в том же Forth есть механизмы (игра со стеком возвратов) почти ему не уступающие.
Здравствуйте, FR, Вы писали:
VD>>Ну, а полные континюэшоны — это файберы (или зеленые потоки как их еще называют). Их можно использовать уже ейчас. Они будут медленее континюэшонов в некторых языках, так как сохраняют больше данных. Но при этом сам язык будет быстрее, так как он компилируемый. В прочем, виртуальная машина позволяет и ограничить контекст. Но это сложна работа. Когда нибудь ее сделают. И работать это решение будет для всех языков дотнета или явя. В Яве подобные работы уже ведутся. Есть котнинюэшон-серверы.
FR>Файберы тоже частный случай.
Я так понимаю это Влад coroutines имеет в виду, которые, вроде тоже частный случай.
.
). Изначально я хотел узнать, почему это будущее есть только у языков, построенных по принципу Nemerle.
Тут и обсуждать не чего. Так что ты дава, докуривай. А потом еще раз обсудим.
