Здравствуйте, EvilChild, Вы писали:
EC>Здесь явно какая-то путаница — в схеме же есть продолжения, хотя она и близко не чистый язык.
Вот и я о томже... что-то FR путает...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, EvilChild, Вы писали:
EC>Эта штука макросами реализована? Я про yield.
Конкретно эта нет.
Но если пойти на необходимость вешать макрос на метод то можно и макросами
[YieldSupport]
public static MapFilteredLazy[T, U](this lst : list[T], fn : T -> option[U]) : SCG.IEnumerable[U]
...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, lomeo, Вы писали:
WH>>>Коротко нельзя да и НДА. EC>>Тогда как аргумент в пользу макросов это звучит малоубедительно.
L>Представь любую ситуацию, при которой обычно ты пользуешь кодогенерацию, дабы не плодить мануальный копи-пейст.
L>Иногда подобные ситуации связаны с ограничениями в языке. Поскольку я работаю на Яве, то могу много про это рассказать В C# с этим получше, но не замечательно. Вообще, ИМХО, чем больше в языке конструкций являются first-class citizen, тем лучше — нет ограничений на их применение. Если же ограничения есть, то приходится для двух схожих задач, отличных только по этим ограничениям применять два схожих куска кода вместо одного. Эту дыру можно прикрыть кодогенерацией или макросами (на них можно смотреть, как на один из способов кодогенерации).
Я примерно представляю для чего они нужны, но было сказано, что возникла реальная необходимость,
и как только захотелось узнать подробности — так сразу НДА и прочие отмазки.
Вот если бы LINQ приделали на макросах это был бы убийственный аргумент.
Здравствуйте, WolfHound, Вы писали:
EC>>Эта штука макросами реализована? Я про yield. WH>Конкретно эта нет. WH>Но если пойти на необходимость вешать макрос на метод то можно и макросами WH>
WH> [YieldSupport]
WH> public static MapFilteredLazy[T, U](this lst : list[T], fn : T -> option[U]) : SCG.IEnumerable[U]
WH> ...
WH>
Можешь пояснить, что этот код делает? То же, что и ранееприведённый? Зачем атрибут [YieldSupport] установлен?
И почему yield не макросом сделан?
Здравствуйте, EvilChild, Вы писали:
EC>Я примерно представляю для чего они нужны, но было сказано, что возникла реальная необходимость, и как только захотелось узнать подробности — так сразу НДА и прочие отмазки.
Так эта... см код компилятора там их полно... например SupportRelocation
EC>Вот если бы LINQ приделали на макросах это был бы убийственный аргумент.
Если бы оно было сильно надо...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, EvilChild, Вы писали:
EC>Можешь пояснить, что этот код делает? То же, что и ранееприведённый?
Угу. EC>Зачем атрибут [YieldSupport] установлен?
Это макрос. EC>И почему yield не макросом сделан?
Я еще не слишком глубоко компилятор копал.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
FR>>То есть все что не можем сделать на макросах зло, понятно. WH> WH>
WH>class A {}
WH>class B : A {}
WH>...
WH>void fn(A, B)...
WH>void fn(B, A)...
WH>...
WH>fn(new B(), new B());
WH>
WH>Какую функцию вызывать будем?
Никакую, ошибка "неоднозначность вызова" (в зависимости от модели — ошибка компиляции, линковки или даже исключение типа NullObjectException) . Если так надо вызвать функцию для двух В, то придется реализовать fn(B, В).
То же самое мы имеем и сейчас с обычной перегрузкой, единственная разница — нужно учитывать, что перекрытая функция в случае мультиметодов может прийти из другой библиотеки/сборки/файла.
Здравствуйте, eao197, Вы писали:
E>И история показывает, что Брайт зачатую принимает решения, от которых впоследствии сам же и отказывается. Нет никаких гарантий, что даже такая поддержка C++ не является очередным ошибочным шагом.
Это уже отдельный вопрос, не надо увиливать. Нужны были доказательства, что там была написана глупость? Я их предоставил.
E>Раньше я думал, что ваша настойчивость определяется только вашим упрямством. Но теперь видно, что это следствие элементарного незнания ни D, ни C++.
Я абсолютно уверен, что есть немало людей, которые знают С++ лучше меня. Но я еще больше уверен, что ты в их число не входишь и вряд ли когда-нибудь будешь.
Что касается D, то я знаю о нем вполне достаточно, чтобы не хотеть узнавать больше.
E>Возможно, вам бы помогло изучение этих языков и обдумывание того, почему у MS с чистым C++ом в .NET ничего не получилось.
E>Польщен тем, что мои высказывания стали следствием исследования.
Мне интересно читать темы о Немерле. А не заметить там такой объемистый и невежественный вклад было просто невозможно.
E>Однако, если бы вы читали то, что я пишу здесь, то могли бы увидеть, что я разговариваю с вами на "Вы" и был бы признателен, если бы вы поступали так же.
Если есть желание поупражняться в формально-канцелярском стиле речи — ради бога. Но это надо хотя бы делать грамотно. "Вы" при обращении к одному лицу всегда пишется с большой буквы.
В общем извини, дальше беседовать с тобой мне не интересно, и работать надо, и пришло опять к тому о чем я сразу и подумал, к разбрызгиванию соплей. Хотя было-бы инетересно конечно нормально поговорить от том что могут макросы а чего нет.
Здравствуйте, WolfHound, Вы писали:
EC>>Вот если бы LINQ приделали на макросах это был бы убийственный аргумент. WH>Если бы оно было сильно надо...
Ну уж? Не надо лукавить. Я даже переписку читал, где авторам языка предлагали добавить новый тип макросов специально для того, чтоб можно было реализовать тот же LINQ.
IT не раз говорил, что в таком случае стоит признать, что макросы не могут создавать нормальные DSL, и что все обходные пути реализации LINQ (как то <# select... #> и прочее) — это фигня, а не решение.
Здравствуйте, Andrei F., Вы писали:
E>>Раньше я думал, что ваша настойчивость определяется только вашим упрямством. Но теперь видно, что это следствие элементарного незнания ни D, ни C++.
AF>Я абсолютно уверен, что есть немало людей, которые знают С++ лучше меня. Но я еще больше уверен, что ты в их число не входишь и вряд ли когда-нибудь будешь.
Аминь!
AF>Что касается D, то я знаю о нем вполне достаточно, чтобы не хотеть узнавать больше.
Тем не менее, этих явно поверхносных знаний оказывается достаточно, чтобы утверждать, что между D и C++ возможна прозрачная интероперабильность, да еще с учетом шаблонов, множественного наследования, различных объектных моделей, разных систем поддержки исключений и сборки мусора?
Показательно однако.
E>>Польщен тем, что мои высказывания стали следствием исследования.
AF>Мне интересно читать темы о Немерле. А не заметить там такой объемистый и невежественный вклад было просто невозможно.
Значит, у меня получилось!!!
В свое время апологеты Nemerle спасибо мне говорили за то, что я поддерживаю интерес к этому языку у читателей форума. Видимо, не зря говорили.
E>>Однако, если бы вы читали то, что я пишу здесь, то могли бы увидеть, что я разговариваю с вами на "Вы" и был бы признателен, если бы вы поступали так же.
AF>Если есть желание поупражняться в формально-канцелярском стиле речи — ради бога. Но это надо хотя бы делать грамотно. "Вы" при обращении к одному лицу всегда пишется с большой буквы.
На счет "всегда" вы опять горячитесь. Несложный поиск по Интернету приводит к простому выводу: здесь
Таким образом, местоимения Вы, Ваш пишутся с прописной буквы при обращении к одному лицу в текстах следующих жанров:
(а) личное письмо (адресат конкретное лицо; факультативное написание выбор определяет сам пишущий, выражая/ не выражая вежливое или уважительное отношение к адресату);
(б) официальные документы (адресат конкретное лицо, отношение пишущего к адресату не имеет значения);
(в) анкеты (адресат неконкретное лицо; отношение пишущего к адресату не имеет значения).
Еще раз напомним, что при обращении к нескольким лицам или неопределенному кругу лиц местоимения вы, ваш пишутся со строчной буквы (см. выше).
По-моему мнению, публичная переписка в публичном же форуме не попадает ни под одну из вышеперечисленных категорий.
Да и для пояснения: когда я написал "Вы", то это означало всего лишь привлечение внимания к тому факту, что мы с вами используем разные способы обращения к собеседнику.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, WolfHound, Вы писали: WH>В немерле полные по Тьюрингу имеющие доступ ко всему API компилятора макросы. WH>Те при особом жилании на них можно сделать практически все.
Это не верно просто потому, что эти макросы не работают в run-time.
Здравствуйте, WolfHound, Вы писали:
L>>continuations — это call/cc. Нарисуй его, пожалуйста. Как решить частные случаи, которые решает call/cc, не особо интересно. Вопрос был о поддержке продолжений.
WH>Покажи случай который не делается через yield. Тебе это должно быть не трудно.
1. Сам примитив call/cc. Я хочу, чтобы мои вычисления не знали о том, что они используются как продолжения.
В принципе, если yield является first-class order, то этого должно быть достаточно.
2. Классический оператор amb. В частности, пример с (if (amb #t #f) 1 (amb)) в котором amb обязан возвращать #t.
3. call/cc легко использовать как исключение, а yield? Смысла для основной канвы спора имеет мало, т.к. исключения уже есть, но для того, чтобы придраться к словам "Покажи случай который не делается через yield" можно
4. shift/reset примитивы
5. То, что вытворяет Олег Киселёв даже просить не буду
На самом деле всё это совершенно неважно. call/cc мощнее yield, так как он позволяет сделать то, что делает yield, а yield не позволяет сделать то, что делает call/cc. Только в отрыве от языка это мало что значит.
Как аргумент того, что язык есть куда расширять это может и не покатит — может эти продолжения нафиг не сдались пользователям Немерле, а может предложение рождает спрос — хз. Но вот то, что не всё сделаешь на макросах, по крайней мере, с практической точки зрения — вполне покатит.
L>>Мультиметоды — зло, хотя бы по той причине, что их нет в Немерле WH>Я уже сказал чем плохи мультиметоды. WH>Если ты скажешь как разрешить их противоречия я их без проблем сделаю.
Да нет, мне это не особо интересно. Просто разговор позабавил
— на макросах можно сделать всё
— сделай мультиметоды!
— мультиметоды — зло
L>>На самом деле тут о чём разговор? О том, что если макросы есть, то всё — можно уже не расширять язык или что? WH>По большей части да. По крайней мере в той что любит крутиться Aлександреску. WH>Что касается всего остального то тут больше вопросов чем ответов. WH>Например ленивость по умолчанию мягко говоря сомнительна. WH>Хотя при жилании можно сделать и болие общую ленивость что уже сделана вопрос лишь в том, а оно надо?
Про ленивость по умолчанию вроде как никто не говорил — это вообще вопрос выбора, спорить тут не о чем. Прочее — это, по моему, отголоски дискуссии о том, что макросы — это индикаторы недоделок в языке. Так что на макросы можно смотреть и с другой стороны — если макросы есть, значит есть что расширять
Здравствуйте, WolfHound, Вы писали:
EC>>Я примерно представляю для чего они нужны, но было сказано, что возникла реальная необходимость, и как только захотелось узнать подробности — так сразу НДА и прочие отмазки. WH>Так эта... см код компилятора там их полно... например SupportRelocation
Кстати, этот SupportRecolation (если это то, о чём я думаю) — уже обсуждался. Насколько я помню, там показывалось, что на некоторых языках это можно красиво сделать без макросов. И то, что здесь он был сделан на макросах, может говорить о некоторых недостатках (ну или по крайней мере отсутствии некоторых фич) в языке.
Здравствуйте, WolfHound, Вы писали:
AF>>>С трудом представляю, что можно менять в ядре, тем более — постоянно FR>>Я думаю просто нужно чтобы Aлександреску заинтересовался Немерле WH>Он ничего не придумает. WH>Да и что можно придумать если уже есть полные по Тьюрингу макросы?
Как сделать классы типов на макросах?
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, lomeo, Вы писали:
L>Кстати, этот SupportRecolation (если это то, о чём я думаю) — уже обсуждался. Насколько я помню, там показывалось, что на некоторых языках это можно красиво сделать без макросов. И то, что здесь он был сделан на макросах, может говорить о некоторых недостатках (ну или по крайней мере отсутствии некоторых фич) в языке.
Где?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VoidEx, Вы писали:
VE>Ну уж? Не надо лукавить. Я даже переписку читал, где авторам языка предлагали добавить новый тип макросов специально для того, чтоб можно было реализовать тот же LINQ.
Там разговор шол о том чтобы сделать идентичный синтакс. А оно надо идентичный?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, lomeo, Вы писали:
L>1. Сам примитив call/cc. Я хочу, чтобы мои вычисления не знали о том, что они используются как продолжения. L>В принципе, если yield является first-class order, то этого должно быть достаточно.
Функция в который использован yield превращается в генератор последовательности.
L>2. Классический оператор amb. В частности, пример с (if (amb #t #f) 1 (amb)) в котором amb обязан возвращать #t.
А по русски можно?
L>4. shift/reset примитивы
Это что?
L>5. То, что вытворяет Олег Киселёв даже просить не буду
А что он вытворяет?
L>Как аргумент того, что язык есть куда расширять это может и не покатит — может эти продолжения нафиг не сдались пользователям Немерле, а может предложение рождает спрос — хз. Но вот то, что не всё сделаешь на макросах, по крайней мере, с практической точки зрения — вполне покатит.
С практической точки зрения былобы жилание.
L>Про ленивость по умолчанию вроде как никто не говорил — это вообще вопрос выбора, спорить тут не о чем.
FR говорил. L>Прочее — это, по моему, отголоски дискуссии о том, что макросы — это индикаторы недоделок в языке. Так что на макросы можно смотреть и с другой стороны — если макросы есть, значит есть что расширять
Угу... паскаль совершенство...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Это не верно просто потому, что эти макросы не работают в run-time.
Данное утверждение не верно.
Компилятор и как следствие макросы можно использовать в run-time...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, FR, Вы писали:
FR>В общем извини, дальше беседовать с тобой мне не интересно, и работать надо, и пришло опять к тому о чем я сразу и подумал, к разбрызгиванию соплей.
Зеркало принести?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
В C# с этим получше, но не замечательно. Вообще, ИМХО, чем больше в языке конструкций являются first-class citizen, тем лучше — нет ограничений на их применение. Если же ограничения есть, то приходится для двух схожих задач, отличных только по этим ограничениям применять два схожих куска кода вместо одного. Эту дыру можно прикрыть кодогенерацией или макросами (на них можно смотреть, как на один из способов кодогенерации).
