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

E>Тем не менее, этих явно поверхносных знаний оказывается достаточно, чтобы утверждать, что между D и C++ возможна прозрачная интероперабильность, да еще с учетом шаблонов, множественного наследования, различных объектных моделей, разных систем поддержки исключений и сборки мусора?

И снова бинарное мышление. Или всё, или ничего.
Кстати, это оказывается довольно распространенное явление, которое называется "патологический перфекционизм".

E>Значит, у меня получилось!!!
E>В свое время апологеты Nemerle спасибо мне говорили за то, что я поддерживаю интерес к этому языку у читателей форума. Видимо, не зря говорили.

Так вот в чем дело! Буду знать

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

Там написано вполне определенно, что писать с прописной буквы надо всегда при обращении к конкретному лицу. "вы" с маленькой буквы пишется при обращении к аудитории.

E>Да и для пояснения: когда я написал "Вы", то это означало всего лишь привлечение внимания к тому факту, что мы с вами используем разные способы обращения к собеседнику.

Предлагаю не разводить неуместный официоз и обращаться на "ты"

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

L>>1. Сам примитив call/cc. Я хочу, чтобы мои вычисления не знали о том, что они используются как продолжения.
L>>В принципе, если yield является first-class order, то этого должно быть достаточно.
WH>Функция в который использован yield превращается в генератор последовательности.

Т.е. можно так (я просто не знаю)?

Yield[T](value: T): T
{
    yield value;
}

Foo[T](fn: T -> T)...
{
    ...fn(T);
}

Foo(Yield)

За синтаксис прошу прощения, не знаю языка.

L>>2. Классический оператор amb. В частности, пример с (if (amb #t #f) 1 (amb)) в котором amb обязан возвращать #t.
WH>А по русски можно?

amb — это оператор, которому мы передаём кучу аргументов, а он возвращает то из них, которое сработает (не приведёт к выбросу amb-исключения) при дальнейшем исполнении программы.

Примеры:

(amb) — ошибка (нечего возвращать)

(amb 1 2 3 (amb) 4 (amb)) — вернёт 1, 2, 3 или 4

(if (eq? 3 (amb 1 2 3 4 5))
1
(amb)) — первый amb обязательно вернёт 3, иначе будет ошибка в программе (второй amb).

L>>4. shift/reset примитивы
WH>Это что?

palm_mute очень интересно про них рассказывал здесь:
http://palm-mute.livejournal.com/12291.html

L>>5. То, что вытворяет Олег Киселёв даже просить не буду
WH>А что он вытворяет?

http://okmij.org/ftp/Computation/Continuations.html

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

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

WH>Где?

По моему где то здесь, в философии. Тема называлась "Являются ли макросы свидетельством..."

Там Generics из Хаскеля предлагалось, как возможное решение без макросов.

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

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

E>>Тем не менее, этих явно поверхносных знаний оказывается достаточно, чтобы утверждать, что между D и C++ возможна прозрачная интероперабильность, да еще с учетом шаблонов, множественного наследования, различных объектных моделей, разных систем поддержки исключений и сборки мусора?

AF>И снова бинарное мышление. Или всё, или ничего.
AF>Кстати, это оказывается довольно распространенное явление, которое называется "патологический перфекционизм".

хм... Как я вас понял, интероп с C++ нужен для того, чтобы в D использовать существующие наработки из C++. Итак, мне по работе приходится использовать такие библиотеки, как Crypto++ и ACE. Интересно было бы услышать, как мог бы выглядеть в D интероп с этими библиотеками.

В особенности интересно использование каркасов ACE_Reactor и ACE_Acceptor/ACE_Connector. Вкратце: для того, чтобы использовать ACE_Acceptor, необходимо сделать класс, производный от ACE_Svc_Handler -- он будет обрабатывать входящие соединения. При этом класс ACE_Svc_Handler шаблонный и должен параметризоваться типом транспорта. Так же нужно создать наследника ACE_Acceptor для того, чтобы переопределить методы создания и настройки конкретных Svc_Handler-ов, при этом ACE_Acceptor так же параметризуется. Аналогичные классы нужно создавать и при работе с ACE_Connector.

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

Каким образом это будет выглядеть без патологического перфекционизма?

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

WH>Там разговор шол о том чтобы сделать идентичный синтакс. А оно надо идентичный?

Ну!

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

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

Обоснуй. Лично я с этим утверждение не согласен.

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

Нет в ФП никаких специальных средств проектирования. ФП это развитие идей структурного программирования. "Сахар", можно сказать (чур меня ).

VD>>2. В том то и дело, что если знать Шарп (а таких программистов очень много), то фунциональные вещи осваиваются довольно легко и, что не маловажно, прямо во время работы над каким-нибудь проектом. Желательно только чтобы при этом рядом с новичком работал кто-то кто уже прошел этот пукть и может потихоничку направлять новичка в нужное русло.

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

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

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

FR>Даже я могу кучу вещей придумать в которых полные по тьюрингу макросы мало чем помогут, например добавь подержку продолжений ( http://en.wikipedia.org/wiki/Continuation ), или мультиметов в стиле CLOS, или нормальную ленивость, думаю в этот список можно еще немало вещей добавить и со временем список будет только расти.

Все это реализуется (если уже не реализовано) на макросах. Так что просто кончай сотрясать воздух.

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

AF>>Если учесть размер команды, то при разработке на языке без макросов никаких контрактов не было бы вообще.

E>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.

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

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

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

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

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

AF>>>Если учесть размер команды, то при разработке на языке без макросов никаких контрактов не было бы вообще.

E>>В Sign# есть, в D есть, в Nice есть такие же контракты. И команды там были не на много больше, чем у Nemerle.

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

Смысла этой сентенции не уловил, тем более, что для проверки контрактов Spec# использует сторонний инструмент, реализованный другой компанией на Java.

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

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

Никто?

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

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

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

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

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

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

FR>>Даже я могу кучу вещей придумать в которых полные по тьюрингу макросы мало чем помогут, например добавь подержку продолжений ( http://en.wikipedia.org/wiki/Continuation ), или мультиметов в стиле CLOS, или нормальную ленивость, думаю в этот список можно еще немало вещей добавить и со временем список будет только расти.

VD>Все это реализуется (если уже не реализовано) на макросах. Так что просто кончай сотрясать воздух.

И как, позвольте поинтересоваться, amb реализуется на макросах?
А еще хочется узнать, как реализуется на макросах LINQ.

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

EC>>Можешь пояснить, что этот код делает? То же, что и ранееприведённый?
WH>Угу.
В общем yield ниразу не макрос, тогда к чему ты привёл код с yield как обоснование их нужности?
То что yield это не continuuation я так понимаю даже и упоминать бесполезно.

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

FR>>В общем извини, дальше беседовать с тобой мне не интересно, и работать надо, и пришло опять к тому о чем я сразу и подумал, к разбрызгиванию соплей.
WH>Зеркало принести?

Не поможет
Жаль у меня по работе завал, так что флеймить некогда.
В общем останемся при своих

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

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

VD>Обоснуй. Лично я с этим утверждение не согласен.

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

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

VD>Нет в ФП никаких специальных средств проектирования. ФП это развитие идей структурного программирования. "Сахар", можно сказать (чур меня ).

Gaperton со своей Problem K очень наглядно показал что есть.
Мне кажется ты просто не докурил ФП.
Я вот тихонько докуриваю но идет туго

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

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

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

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

FR>Угу тогда функторы аля STL это замыкания
FR>Сходи все таки по ссылке, посмотри как в схеме сделано.

В схеме всем плевать на производительность, от того и сделано. Для аттически типизированного языка это смысла не имеет, так как все выродится в файберы которые уже сто лет как есть. Континюэшоны действующие на метод есть, это и есть итераторы. Сделать континюэшоны для класса или даже для ряда классов можно. Возможно если будет время то займусь этим.

FR>>>или мультиметов в стиле CLOS,
WH>>Мультиметоды зло ибо их семантика слишком размыта.
WH>>Слишком много если...

FR>То есть все что не можем сделать на макросах зло, понятно.

В том то идело, что можно. Только не нужно. О том как реализовать мультиметоды была тема в немерловой конфе. Автор вопроса согласился с камилом, что на макросах все прекрасно реализуюется. Просто учитывая, что есть паттерн-матчинг решающий проблему множественной динамической димпетчиризации, особой необходимости именно в мультиметодах нет. По существу мультиметоды и есть только в КЛОС-е который является макробиблиотекой для ЛИСП-а в котором оных нет. И есть они в КЛОС-е в не малой мере потому, что в ЛИСП-е нет паттерн-матчинга (а потребность в мультидиспатче есть).

Так что не гони.

FR>>>или нормальную ленивость,
WH>>Что значит нормальную?
WH>>Эта нормальная или нет http://nemerle.org/Lazy_evaluation

FR>Сравнивай с хаскелем или клейном.

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

FR>>>думаю в этот список можно еще немало вещей добавить и со временем список будет только расти.
WH>>Попробуй.

FR>А зачем, ты скажешь или не нужно или приведешь частично коряво сделаную реализацию и скажешь что этого достаточно. Это все равно что обчитавшемуся Александреску говорить что boost::lambda корявое убожество.

Если честно, то с тобой вообще разговаривать забавно. Ты как и другие "критики" сами не пробовавшие то о чем рассуждаешь выискиваешь в отдельных языках отдельные фичи которые или не сделаны, или сделаны по другому и на основании этого пыташся найти фатальный недостаток. Вот только проблема в том, что язяки где эти фичи есть обладают куда большим количеством недостатков. Многие из которых действительно фатальны. Вот те же Ди и С++, например в подметки Немерлу не годятся с точки зрения удобства программирвоания. Они вообще только в битовыжимании сильны. Но это же ты в рассчет не берешь?

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

FR>Настоящей тотальной ленивости нет, этого как и продолжений макросами не сделать.

Вообще-то можно попытаться.
Вот только зачем нужно делать все на макросах?
И нужно ли вообще делать что-то только на том основании, что кто-то кто слышал о этом "чем-то" приводит это в качеств примера?

Что ты вообще сказать то хочешь этими примерами? Что макросы не всесильны? Ну, это езжу понятно. От этого что-то меняется?

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

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

Именно. Вот только у полноценной компилируемой программы таким контекстом является вся память включая стеки потоков. Продолжения в любом языке "неполноценны", так как не делают слепок процесса. Итераторы это частный случай. Конечно он не воспроизводит все паттерны использования континюэшонов, но больую часть их покрывает. Главное, что он позволяет развернуть управление.

Ну, а полные континюэшоны — это файберы (или зеленые потоки как их еще называют). Их можно использовать уже сейчас. Они будут медленее континюэшонов в некторых языках, так как сохраняют больше данных. Но при этом сам язык будет быстрее, так как он компилируемый. В прочем, виртуальная машина позволяет и ограничить контекст. Но это сложна работа. Когда нибудь ее сделают. И работать это решение будет для всех языков дотнета или явя. В Яве подобные работы уже ведутся. Есть котнинюэшон-серверы.

FR>Дежавю почти , помню на питоне тут подобное показывал, правда у тебя как всегда только наброски.

Тебе они нужны, ты и делай. Остальным просто не нужны.

FR>Здесь также, порядок тоже можно сделать естественный по мере объвления.

Какого к черту объявления? У тебя сборка может динамически подгрузиться. И в ней может быть расширение мультиметода. В общем, не веди беседы о том, в чем ни в зуб ногой.
Кроме не однозначностей я тебе еще две проблемы раскро:
1. Производительность мультиметодов обратно пропорционально количеству параметров. Хроший универсальный алгоритм тут не существует.
2. Проблемы с днимической загрузкой и безопастностью.

WH>>Благодоря этому можно проверить что все паттрены доступны и покрываются все варианты входных значений.

FR>Ну бывают и полиморфные варианты и их паттерн матчинг, там точно такие же проблемы.
FR>Кстати немерле подерживает полиморфные варианты? И если нет (или бы не подерживал) то можно их прикрутить макросами?

Все варианты полиморфны априори. Есть понятие GADT. Вот их Немерле не поддерживает по политическим соображениям (это к ошибкам приводит). За то он позволяет наследовать варианты от классов. Вот только боюсь, что для тебя это все птичий язык.

FR>Мне сейчас все хватает, я же Блаб в продолжениях

И не только в них.

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

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

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

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

L>Да нет, мне это не особо интересно. Просто разговор позабавил

L>- на макросах можно сделать всё
L>- сделай мультиметоды!
L>- мультиметоды — зло

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

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

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

EC>Эта штука макросами реализована? Я про yield.

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

[Yield]
public MapFilteredLazy[T, U](this lst : list[T], fn : T -> option[U]) : SCG.IEnumerable[U]
{
    def loop(_)
    {
        | head :: tail =>
            match (fn(head))
            {
            | Some(result) => yield result;
            | None => ();
            }
            loop(tail);
        | [] => ();
    }
    loop(lst);
}

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

EC>Можешь пояснить, что этот код делает?

Читает код исходного метода помеченного метаатрибутом, меняет его так чтобы вместо него использовался конечный автомат.

EC> То же, что и ранееприведённый?

А, ты о результате? Да.

EC> Зачем атрибут [YieldSupport] установлен?

Это и есть макрос. Это указание компилятору запустить макрос который перепишет код метода в другой использующий конечнй автомат.

EC>И почему yield не макросом сделан?

По больше части как раз чтобы не иметь такого синтаксиса. Сама реализация делается через макро-АПИ.