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

FR>>Я пока только изучаю продолжения, но кажется файберы тоже только частный случай, они без проблем на call/cc реализуются.

VD>Файберы работают вне языков. Так что это очередная ерунда. Ты можешь написаать call/cc который я смогу использовать из Шарпа? Файберы это те же потоки, только без раздачи квантов времени и с ручным переключением.

Файберы это вообще абстракция из другой оперы, ты их по ходу с coroutines путаешь.

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

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

VE>>Конечно, но вся соль синтаксического сахара ( ) как раз в синтаксисе. А LINQ все-таки сахар. Фича — это call/cc, type classes, которые макросам неподвластны. Хотя кто знает.

VD>Очередно обсуждение того о чем ничего не понимашь. Мне это надоело. Бредьте в одиночистве. Когда сделаем этот самый ЛИНК не забудьте сказать, что были не правы.

Так чего ж обсуждаешь?

Не смеши, текущими макросами LINQ не сделаешь, хоть убейся, я в курсе почему. Либо другой синтаксис, либо <# #> (что тоже другой синтаксис) или еще какие костыли. Надо систему макросов менять.
Главное, чтобы ее не приходилось менять на каждый чих
Только, чего ты так бесишься, не пойму, а, ну да... Ты ж сам написал.
Я вообще-то в спор WolfHound и FR встрял, в котором то и дело слышно было, что на макросах можно все, а чего нельзя, то и не нужно. Вот только call/cc как-то не пошел. А тут и выяснилось, что в нем никто ничего не понимает

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

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

FR>>Gaperton со своей Problem K очень наглядно показал что есть.

VD>Чушь.

Видно что ты и курить не пытался

FR>>Я вот тихонько докуриваю но идет туго

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

Угу надо жевать это же сахар

FR>>Очень просто, используются фичи (практически только локальные) из ФП помогающие делать код короче, при этом все, часто даже то, что легко и красиво можно сделать функционально, пишется в смешаном функционально-императивном стиле. Функциональная декомпозиция вообще не применяется. Я не говорю что это одназначно плохо.

VD>Бред, да и только. Тут и обсуждать не чего. Так что ты дава, докуривай. А потом еще раз обсудим.

Так если я докурю, я же на недокуривших и смотреть не буду, не то что общатся, у злобных функциональщиков так принято

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

L>>На самом деле тут о чём разговор? О том, что если макросы есть, то всё — можно уже не расширять язык или что?

VD>Нет конечно. Это у FR аргументы кончились вот он и подменил обсуждаемый вопрос. А тема, вообще-то про С++ была. Вот только что-то тут его совсем не обсуждают .

При чём здесь FR? Это я понял со слов WolfHound'а, поэтому переспросил его.

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

L>>Кстати, этот SupportRecolation (если это то, о чём я думаю) — уже обсуждался. Насколько я помню, там показывалось, что на некоторых языках это можно красиво сделать без макросов. И то, что здесь он был сделан на макросах, может говорить о некоторых недостатках (ну или по крайней мере отсутствии некоторых фич) в языке.

VD>Обсуждался. Вот только аргумента что для конкретных мест нужен анали другой стороной принято не было, так как если его принять, то без генерации кода обойтись бы уже не получилось. Плюс, Хаскелевская фунция сама может быть создана на базе макроса.

Если говорить откровенно, то я этого момента не помню. Напомни, плз, что за конкретные места и что за анализ, для которых нужна генерация кода? Или ссылку дай на сообщение.

А так — да, если обязательно нужна кодогенерация (т.е. язык не может предложить лучшее решение), то макросы рулят. С этим никто не спорит.

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

VD>Я правильно понял, что по реализуемости мультиметодов и т.п. вопрос отпал?

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

С одной стороны — неточность формулировки, с другой — придирка к словам. Обе стороны отличились, а спор выеденного яйца не стоит, т.к. целей у него два

1. Либо доказать WolfHound-у (и компании), что на макросах сделать всё нельзя, но я думаю, он это и так понимает.
2. Либо доказать FR (и компании), что мультиметоды Немерле не нужны. Но его это тоже мало интересует.

Остальное — детали. Коротко — о разном говорят, IMHO.

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

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

VD>Это личное мнение, а не обоснование. Мое мнение, что дело в тех кто учит.

Может быть. Мне труднее учить ФП, чем было ООП.

Если дело в нас, то открой секрет, как же учить надо? Ну или скажи, что ты под ФП понимаешь, ну то есть, что ты учил?

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

VD>Вообще, конечно на макросах можно сделать не все. Но и не нужно все делать на макросах. Но то что делается на них, по-моему, не стоит хардкодить в компиляторе.

О! Спор свернул в конструктивное русло

С последней мыслью немного не согласен. Хардкодить в компиляторе, наверное, да, не стоит. На все случаи не напасёшься. Однако, если есть фича, смотрящаяся достаточно стройно в языке, то это лучше, чем макрос в языке, где этой фичи нет.

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

VD>Все варианты полиморфны априори.

Полиморфные варианты — это не АТД Это такие конструкторы, отвязанные от типа. Они есть, например, в OCaml.

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

VD>Сравнивл. Разницы не обнаружил. Просто другие умолчания. В нем по умолчанию все лениво, а в Немерле нет. Вот тормозит Хаскель по черному (чтобы его фанаты не говорили) — это да.

Насколько ленивый код в Немерле быстрее, чем аналогичный ленивый код в Хаскель?

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

E>Итак, я хочу использовать ACE, но создавать наследников ACE_Svc_Handler и ACE_Acceptor/ACE_Connector в D, а потом передавать указатели на обратно в ACE (в ACE_Reactor, в частности).

В данном случае, видимо, надо поумерить желания и поискать более простой способ интеропа.

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

AF>В данном случае, видимо, надо поумерить желания и поискать более простой способ интеропа.

В таком случае очень большую часть C++ библиотек будет невозможно использовать.
Более простой и ограниченный интероп уже есть.

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

FR>В таком случае очень большую часть C++ библиотек будет невозможно использовать.

Библиотеки — это как раз не самое важное. Главная проблема при миграции — это свои собственные проекты, которые обычно нельзя взять и целиком переписать на другом языке. Поэтому нужен интероп. Но ему не обязательно поддерживать абсолютно все возможные случаи, если возникает проблема — код можно упростить.

FR>Более простой и ограниченный интероп уже есть.

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

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

AF>Библиотеки — это как раз не самое важное. Главная проблема при миграции — это свои собственные проекты, которые обычно нельзя взять и целиком переписать на другом языке. Поэтому нужен интероп. Но ему не обязательно поддерживать абсолютно все возможные случаи, если возникает проблема — код можно упростить.

Пойми реально D сильно отличается от C++. Практически не меньше чем шарп. И продолжить на нем проект не получится.

FR>>Более простой и ограниченный интероп уже есть.

AF>Там даже модификаторы соглашения о вызовах не поддерживаются Но вообще, это шаг в правильном направлении.

Это дело наживное.

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

FR>Пойми реально D сильно отличается от C++. Практически не меньше чем шарп. И продолжить на нем проект не получится.

Я понимаю. C# от C++ еще больше отличается, но организовать между ними интероп у МС получилось очень даже неплохо. И поддерживать проекты, где они существуют бок о бок — это совсем не проблема.

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

AF>Я понимаю. C# от C++ еще больше отличается, но организовать между ними интероп у МС получилось очень даже неплохо. И поддерживать проекты, где они существуют бок о бок — это совсем не проблема.

На таком уровне с D тоже получится, каких то принципиальных ограничений не видно.

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

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

E>>Собственно, против этого я и не спорил (по крайней мере здесь ). Изначально я хотел узнать, почему это будущее есть только у языков, построенных по принципу Nemerle.

VD>А чего тогда осбуждашь совсем другое?

Потому, что Andrei.F так и не смог обосновать свою точку зрения.

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

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

VD>>>У D есть автор пашуший на фул-тайм и при этом сделавший язык уступающий Немерлу почти во всем. Кстати, Немерле поддерживает два вида контрактов. Первый как в Ди проверяется в рантайме, а торой как в Sign# по возможности проверяется во время компиляции. Так что и здесь Ди лузер.

E>>Смысла этой сентенции не уловил,

VD>Объсяняю доходчиво. Автор Ди пока еще слов таких как теорем прувер не знает. Стало быть говорить о поддержке этого в Ди пока бессмысленно.

А никто и не говорил о поддержке в D доказательства корректности контрактов в compile-time.

Для тех, кто в танке, объясняю еще раз: оригинальный Design By Contract, реализованный в Eiffel, содержит специальное ключевое слово old, которое можно использовать только в постусловиях. Оно возвращает значение атрибута/метода, предшествовавшее исполнению тела метода. И именно оно делает возможным проверку в постусловнии корректности работы метода в ряде случаев.

Ни в D, ни в Nice, ни в Nemerle, я не видел возможности использования old в постусловях. Т.е. ни один из этих языков не реализует оригинальной концепции Design By Contract. И компиляторы этих языков созданы на разных принципах. Так какое же преимущество имеет микроядро с макросами Nemerle, если контракты там такие же ущербные, как и в других языках?

E>>>>Так что хотелось бы увидеть обоснованный какими-либо фактами и примерами взгляд на то, что только микроядро и метапрограммирование сейчас являются правильным подходом к разработке современных языков программирования.

VD>>>А зачем? Такого никто не утверждал.

E>>Никто?
E>>

E>>А настоящее будущее — за Немерле или другими языками, которые будут устроены по тому же принципу.

E>>Хотя потом выяснилось, что это было даже не утверждение, а частное мнение.

VD>А где в этих словах "только микроядро и метапрограммирование сейчас являются правильным подходом"?

Я полагал, что в словах "которые будут устроены по тому же принципу".
Но если Andrei.F имел в виду что-то другое, пусть уточнит.

VD>>>Но то что это полезные вещи даже ты наверно не возьмешся опровергать. Не так ли?

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

VD>А как же твои рассказы о конфигах на Руби? Это то самое метапрограммирование и есть. Тебе в руки попался инструмент с гибким синтаксисом и метавозможностями и ты использовал его для того, на что он и рассчитан то не был.

Не понял, что здесь понимается под "гибким синтаксисом". Синтаксис в Ruby менять нельзя. Можно делать только run-time кодогенерацию.

Более того, использование синтаксиса и блоков кода Ruby для декларативных описаний -- это общепринятая практика в Ruby, так что нельзя говорить, что язык на это расчитан не был. И в Ruby вся эта магия делается не макросами, не изменением синтаксиса, а обычными библиотеками.

VD>Или это ты тоже поставишь под большое сомнение?

Вынужден поставить, поскольку видел, во что превращают неокрепшие умы возможности Ruby.

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

FR>>Угу только по моему в резулmтате получаются больше "пользователи сахара"

VD>Если переведешь это предожение на Русский, то можно будет осбудить его.

Ну эта, шуга-юзеры получаюцца.

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

VD>На половину. Сам код в компиляторе, но используется макросистема и ее АПИ. В приципе можно было бы и макросом залудить. Тут важна сама возможность анализировать фунцию и генерировать иной ее код. Эта возможность есть. Просто будучи реализованным на макросах синтаксис был бы иной. Например:

А что с функциями, которые вызываются из данной функции. Их нужно переписывать или нет?