T>Если библиотека стандартизована, то её тоже придется поддерживать всегда, ибо без неё не будут компилироваться программы. В чем разница?
T>Что тебе дает факт "неподключения" библиотеки? В чем profit?

Профит в том что кому-то нужны одни фичи, кому-то другие, а в язык идёт то что по оценке фокус-группы будет полезно 80% широких народных масс. А 20% тех умников чьи потребности выше понимания фокус-группы или обходятся МС слишком дорого — в пролёте из года в год. Вот живой пример: у нас потоки поднимаются и мрут тоннами, часто нужен ReaderWriterLock, на C# — это блоки try/finally и куча хрени на каждый чих:

try
{
   _lock.AcquireReaderLock(Timeout.Infinite);
   ...
}
finally
{
   _lock.ReleaseReaderLock();
}

А на Nemerle я тупо скопипастил из сорцов компилятора макрос lock, чуть поправил и включил его в _свой_ солюшн. Получилась красивая и удобная штука:

readlock(this)
{
...
}

writelock(this)
{
...
}

Объяснять что это ключевое слово делает под капотом — даже не понадобилось, просто показал людям что такое появилось и все стали пользовать. Удобно — однозначно лучше чем каждый раз огораживать try/finally. Но нужна ли всем и каждому в языке такая конструкция — вряд-ли. Станут в MC её вводить в язык если даже на connect мы всей конторой зафлэшмобим? Тоже вряд-ли. Тем более что с выходом фреймворка 3.5 мы например решили обновить макру на ReaderWriterLockSlim, а кто-то другой может не дожидаясь на interlocked замутит что-то своё, а кто-то третий захочет ещё таймаут задавать.

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

Вот поэтому у МС руки так связаны — им каждое ключевое слово, каждая фича облегчающая жизнь людям — ноша на всю карму. Даже замена ReaderWriterLock на ReaderWriterLockSlim — это уже проблема — характеристики то у них разные, правила реентерабильности, и т.п. и кому-то может эта замена всё испортит. А в расширяемом языке — добавляются библиотеки, старые библиотеки заменяются на новые. Кто-то использует старый lock через using Std.Concurrency, кто-то делает using StdNew.Concurrency и использует с тем же синтаксисом уже новый, а кто-то вытаскивает себе что-то супер-новое из модного блога, и забивает на все Std.

H>Сейчас мы почти .NET 4.0 ready (почти — это потому что dynamic-ов временно не поддерживаем).
Dynamic нам не нужен совершенно, на 4.0 идём в основном за ковариантностью, новым GC и WPF. А насчёт остального — я как-бы в план вписываю пару-тройку человеко-месяцев ресурсов с конторы на допиливание чего нужно для VS2010 и самого языка. Это будет и нам выгодно, и честной платой за по сути халявное использование того что уже сделано. Но пока подписей не стоит это только планы.

Дон прямо сейчас рассказывает о type providers.
http://bit.ly/bfWDkA

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

Забавно смотреть, как он показывал как он пишет строго-типизированный код к WMI, а потом показывает, как это было бы в старом стиле и для этого использует интеллисенс нового подхода, как подсказку

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

Кэр>Хм, там видео доступно для повторных просмотров
У меня при переходе по ссылке все время говорит произошла хрен знает какая ошибка.
Другие презентации работают.
Что я делаю не так?

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

T>Ничем не отличается, если библиотека стандартизована, что фактически делает её частью языка (как, например STL).
А если билиотека не стандартизирована?

T>Это я понял. Просто обоснований этому нет. Просто вера?
Просто уже не один язык развалился под весом фич.
Ты пойми простую вещь: Если фича добавлена в язык ее придется поддерживать всегда.
Ибо без нее не будут компилироваться программы.
А если я не использую библиотеку я могу ее просто не подключить и все.
Если мне нужны type providers я подключаю макру и получаю type providers.
Если они мне не нужны я не подключаю макру. И они не путаются под ногами.

Я просто не понимаю зачем нужно обосновывать что белый это белый?

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

T>>Ничем не отличается, если библиотека стандартизована, что фактически делает её частью языка (как, например STL).
WH>А если билиотека не стандартизирована?
Ну тогда её использование при прочих равных хуже, чем использования стандартной библиотеки, или фичи встроенной в язык.

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

WH>Ты пойми простую вещь: Если фича добавлена в язык ее придется поддерживать всегда.
WH>Ибо без нее не будут компилироваться программы.
Если библиотека стандартизована, то её тоже придется поддерживать всегда, ибо без неё не будут компилироваться программы. В чем разница?

WH>А если я не использую библиотеку я могу ее просто не подключить и все.
WH>Если мне нужны type providers я подключаю макру и получаю type providers.
WH>Если они мне не нужны я не подключаю макру. И они не путаются под ногами.
Что тебе дает факт "неподключения" библиотеки? В чем profit?

WH>Я просто не понимаю зачем нужно обосновывать что белый это белый?
А зачем надо обосновывать, что Бог создал землю за семь дней?

DG>>и таких примеров можно привести множество: когда фичи введенные в язык дружат с другом, а вот внешние библиотеки между собой часто не дружат.
WH> string это тупо алиас для System.String

и чё? что-то умное что-ли сказал?
а using — это чисто shugar для библиотечного интерфейса IDisposable, foreach надстройка над enumerable-ом и т.д., и т.п.
так же как и большая часть type provider-ы из исходного поста тоже будут реализованы через библиотеку.

речь-то о том — фича в язык интегрирована, или нет?
и речь идет о том, что если фича в язык интегрирована, то она с большей вероятностью будет дружить с другими фичами, а вот если это просто внешняя либа — то интеграции скорее всего не будет, т.к. некому ее будет обеспечивать.

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

А можно в нескольких словах описать в чем идея? Не переношу видео-лекции

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

WH>>А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие.
T>Почему?
А почему бы тогда не захардкодить все библиотеки в язык?
Чем одна хуже другой?
Почему например сахар для LINQ в C# захардкодили, а сахар для DependencyProperty нет?

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

_>Объяснять что это ключевое слово делает под капотом — даже не понадобилось, просто показал людям что такое появилось и все стали пользовать. Удобно — однозначно лучше чем каждый раз огораживать try/finally. Но нужна ли всем и каждому в языке такая конструкция — вряд-ли. Станут в MC её вводить в язык если даже на connect мы всей конторой зафлэшмобим? Тоже вряд-ли. Тем более что с выходом фреймворка 3.5 мы например решили обновить макру на ReaderWriterLockSlim, а кто-то другой может не дожидаясь на interlocked замутит что-то своё, а кто-то третий захочет ещё таймаут задавать.

Ахтунг!
Вы пишите на Nemerle? ХОЧУ К ВАМ!!!

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

FR>>Чтобы файлик прочитать и т. п. нужна только нормальная поддержка compile-time вычислений (как например в D), а не мощная система типов.
WH>Прочитай еще раз то на что ты отвечаешь. И на этот раз внимательнл.

Макросы для этого тоже не нужны.

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

Кэр>Что-то другое Я код не генерю и этим процессом не управляю.
За то управляет тот кто пишет type provider?

Кэр>И очень рад этому факту. Мне реально все равно, как вы называете этот процесс внутри компилятора и почему вам так хочется выделить именно его.
Я просто называю вещи своими именами.
А тсвои попытки назвать белое черным ни к чему хорошему не приведут.
Сам же запутаешься.

WH>>Кстати если подходить к макросам немерла с твоих позиций то они кодогенерацией не занимаются... ибо с исходником ничего не делают.
Кэр>Мне довольно все равно как классифицировать макросы Немерле, так как я их не использую.
Тем не менее придется это сделать.
Иначе у тебя так и будут проблемы с пониманием того что вокруг тебя происходит.

Кэр>Архиватор еще лучше код жмет. С тем же уровнем объективности.
Но есть момент... заархивированный код читать невозможно, а вот код на немерле читать заметно проще чем код на C#.

Кэр>Поддержку среды разработки,
Автокомплит, навигация, подсветка ошибок, хинты (круче чем в студии), отладка прекрасно работают.

Кэр>плагинов вроде Решарпера, плагинов к самому Решарперу,
А что решарпер для F# уже уже есть?

Кэр>хорошую поддержку компилятора никто не отменял.
Уж точно не хуже чем у F#.

Кэр>Или может вам надо спуститься на грешную землю и понять все-таки кто для вас является целевой аудиторией?
Люди которые не хотят говнокодить в десять раз больше кода чем нужно.

Кэр>Уже ответил выше. Поддержка тулами.
Интеграция немерла прекрасно дружит с макросами.

Кэр>Я очень легко могу управлять подключениями библиотек.
Ну так и макросами можно управлять точно так же.
Сделал using SomeMacroNamespace; получил макру.
Не сделал нет макры.
В чем проблема то?

Кэр>В случае с макросами возможных side-effect'ов становится в разы больше.
Ну так головной мозг при разработке макросов никто не отменял.
А так я тебе рефлекшеном без всяких макросв таких side-effect'ов наделаю что закачаешься.

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

Кэр>10 раз взято с потолка.
Возьмем например парсер C# написанный на немерле.
175К ркописного кода и 1.7М кода сгенеренного макросом (для того чтобы по этому коду можно было отладчиком ходить). Причем там генерируется такой код что писать его руками озвереешь.

Я еще когда на С++ писал однажды написал кодогенератор который генерирует примерно столько же кода сколько занимает сам.
Казалось бы в чем смысл?
Но! Учитывая что при малейших изменениях исходных данных весь сгенерированный код существенно менялся плюс в коде была масса волшебных чисел корорые так же пересчитывались я считаю что генератор многократно окупился.

На немерле такие вещи делаются гораздо проще.

Кэр>Отсутствии поддержки языка тулами — вот это критично.
Так есть же интеграция. Но ты ее упорно игнорируешь.

Кэр>Были бы достойные причины отказаться от тулов и выиграть в чем-то другом — уже отказывались бы по все миру и использовали Немерле.
Почитай эту тему.

Автор:
Дата: 11.11.10

Как видешь люди видят выгоды. Понимают риски и готовы их нести ибо инструмент реально мощьный.

Кэр>А ну да, да. Все люди идиоты,
Не все. Но их не мало.

Кэр>а Микрософт их всех обманул.
Никого он не обманывал. Просто большенство людей не думают своей головой, а идут за стадом во главе которого стоит мелкософт.

Кэр>Пример языка, который нашел свою нишу и получил свою аудиторию. То чего не может никак сделать Немерле.
Немерле намного моложе.

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

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

_FR>который, в дефолтовом конструкторе использует некое изменяемое глобальное состояние
Изначально компилятор писали студенты.
Там еще много страшного если посмотреть.
Во второй версии ничего подобного не будет.

_FR>Кстати, как на счёт слов о том, что свойства-акессоры к открытым полям не есть гуд? А что же мы видим здесь? Открытое изменяемое поле
Осталось по недосмотру. Ща сделаю его приватным.

Здравствуйте, Klatu, Вы писали:
K>А можно в нескольких словах описать в чем идея? Не переношу видео-лекции
Запихали кодогенераторы для объектных моделей внешних данных в плагины к компилятору. Не ожидал такой скукоты от Дона.

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

WH>Здравствуйте, Кэр, Вы писали:

Кэр>>Как я сказал — мне довольно все равно, как это реализовано под капотом.
WH>Это плохой подход.
WH>Если не знать как работает инструмент хотябы в общих чертах то можно наломать дров.

О чем вы, родной? До использования тут еще как до луны. Представлен тут только прототип, идея. Ее и можно обсудить. Обсуждать подробности реализации в данном случае интересно — только если это как-то влияет на концептуальное понимание прототипа. И я пока не вижу, как это может повлиять. Тем более, что информации, как там на самом деле реализовано — у вас на руках нет. Об этом лучше самого Дона спросить

Кэр>>Expression — это expression, это объекты в памяти.
WH>Которые используются для чего?

Для интеллисенса и компиляции. Конкретно этот вызов я бы предположил что используется для вызова несуществующих методов/свойств несуществующих типов.

Кэр>>Я так думаю что там генерить код макросом, а потом компилировать код совсем необязательно. Не нужны там особо никакие сложные выражения. Либо вообще не нужны методы там, либо это будут очень простые прокси-вызовы.
WH>Они просто эту самую генерацию и компиляцию засунули прямо в компилятор.

В этом случае — нам не стоит использовать слово "кодогенерация". Ибо это процесс подготовки исходников перед процессом запуски компилятора. А макросы — это один из видов кодогенерации.

Кэр>>Да тут это обсуждалось миллионы раз. Есть другие точки зрения.
WH>И принадлежат они исключительно тем кто этими механищмами ни разу не пользовался...

Ой началось.

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

Я так и знал, что вы начнете в сотый раз на этой волынке. И что макросы там другие. И что вот давай я начну смотреть на примеры и постигать Великое Дао.

Я же вас прошу услышать (и я не первый, и я не последний) — макросы приносят проблемы. Код получается слишком гибкий. Когда семантика кода при одном и том же синтаксисе начинает очень сильно зависеть от подключенных макросов (а также их версии). И возможно порядка подключения. После этого проблемы с порядком подключения заголовков в С++ — выглядят детской шалостью.

WH>Вот например:
WH>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/ComputationExpressions/Test/EnumerableTest.n
WH>Знаешь что нужно было сделать чтобы внутри ComputationExpressions заработал интелисенс?
WH>Ничего. Он сам заработал.

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

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

Кэр>>Если бы были железные контр-примеры, что, например, C# не позволяет чего-то очень критичного, что позволяет Немерле — то у вас не было бы таких проблем в убеждении всех остальных, что эта степень свободы так необходима.
WH>Оба языка полны по тьюрингу.
WH>Проблема в том что на C# писать приходится порой раз в 10 больше.
WH>Но кого это волнует?
WH>Ведь C# сделали в майкрософт. А майкрософт как известно ошибаться не может.

Забавный вы. Вы похоже тоже верите, что МС опять обманул весь мир. Сделайте язык — который имеет внятную нишу и внятное применение — и будет у вас аудитория. Посмотрите на пример Ruby. А если МС был неправ — то МС подтянется, если сможет. Если не сможет — МС умрет и кто-то другой будет делать популярные средства разработки. И никакой теории заговора.

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

D>Можете объяснить что в этом крутого? Имхо, муть какая то. Сложность написания провайдера точно такая же как и для кодогенератора,
Что-то мне подсказывает что таки значительно ниже.

D>при этом код можно использовать в любом языке, а провайдер только в одном.
Это мелкософт при желании может очень легко исправить.

D>Может конечно F# сейчас живет в каком то своем мире где нужен инетлисенс для всех источников данных в мире, но по моему это не задача языка. Лучше бы макросы сделали.
Ну да. Макросами эта задача тоже очень легко решается.
Но сделать толковые макросы не просто. Я бы даже сказал что под это дело нужно дизайнить сам язык, а прикрутить макросы к языку который на это не рассчитан очень не просто.

Здравствуйте, Рысцов Денис, Вы писали:

Кэр>>Выглядит очень круто. Никакого генеренного кода — все типы являются виртуальными и получаются на лету, пока пишется код. При этом есть поддержка сторогой типизации и интеллисенс(!).

РД>Только что посмотрел видео, мне кажется, что type provides это, один в один, описание макросов, точнее одного из use cases'ов их применения. Интересно было бы посмотреть на реализацию, жаль что не доступна.

Какая разница как это реализовывать? Цимус идеи-то не в этом. Главное — что генеренного кода, которым надо управлять нет, а типизированный код все равно есть.

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

Кэр>Дык нет.
А ты внимательно его послушай. Там было несколько оговорок на счет того что нет явной кодогенерации.

Кэр>Там есть интерфейс провайдера типа. А компилятор и среда разработки умеет как-то с этим интерфейсом работать. Код генерить тут совсем необязательно — достаточно получить метаданные типа.
Вот собственно по этим метаданным код и генерируется.
Обрати внимание на выделенное...

 public interface ITypeProvider
    {
        Type GetType(string name, 
                     BindingFlags bindingAttr);
        
        Expression GetInvokerExpression(
                      MethodBase syntheticMethodBase, 
                      ParameterExpression[] parameters);

        event System.EventHandler Invalidate;

        Type[] GetTypes();   
    }

Кэр>Это один из вариантов реализации. Всего-навсего. Я знаю, что вы ребята тут немножко безумные по поводу того, что вариант решения проблемы Немерле — это единственный правильный и лучше просто нигде нет — практически для любых задач. Но мне даже начинать дискуссию в эту сторону не особо интересно.
Мы не безумные. Мы до мозга костей практичные.
А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие.

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

Скомпилирую два твоих сообщения, ок?

Кэр>>Это один из вариантов реализации. Всего-навсего. Я знаю, что вы ребята тут немножко безумные по поводу того, что вариант решения проблемы Немерле — это единственный правильный и лучше просто нигде нет — практически для любых задач. Но мне даже начинать дискуссию в эту сторону не особо интересно.
WH>Мы не безумные. Мы до мозга костей практичные.
WH>А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие.

Из крайности в крайность же.

Кэр>>Да тут это обсуждалось миллионы раз. Есть другие точки зрения.
WH>И принадлежат они исключительно тем кто этими механищмами ни разу не пользовался...

Макросами вообще или макросами Немерле?

P.S. Была уже тема, кстати — "Являются ли макросы свидетельством недостаточной выразительности системы типов".

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

WH>>Мы не безумные. Мы до мозга костей практичные.
WH>>А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие.
L>Из крайности в крайность же.
Какие крайности?
Ты о чем?

WH>>И принадлежат они исключительно тем кто этими механищмами ни разу не пользовался...
L>Макросами вообще или макросами Немерле?
Эти люди в лучшем случае видили макросы С.

L>P.S. Была уже тема, кстати — "Являются ли макросы свидетельством недостаточной выразительности системы типов".
Я двумя руками за то чтобы на систему типов переложить все что можно но: Попробуй на досуге из системы типов приконектиться к БД или файлик прочитать. Или как в этой теме поднять произвольный ITypeProvider и по нему нагенерировать типы и код для доступа к внешним источникам данных.

Так что система типов и макросы дополняют друг друга, а не протеворечат.

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

T>То есть введя Type providers они сделают язык слишком сложным?
Конечно.
Ведь они мало кому нужны.
И такими темпами они весь язык загадят.

WH>>Имея макросистему можно реализовать и то и другое.
T>Можно, и что?
И то что нужно делать макросистему, а не фичи накручивать.

WH>>Причем так что использовать это будут только те кому это надо. А тем кому не надо оно не будет мешать.
T>Ну да, есть очевидные плюсы, как и очевидные минусы.
Плюсы есть.
Минусов не вижу.
Ни одного.

T>Но непонятно откуда взялось это: "А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие"?
Я даже не знаю как с тобой разговаривать.
Ты же сам сказал что впихивание в язык всего подряд приведет к черезмерному усложнению языка.

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

L>>P.S. Была уже тема, кстати — "Являются ли макросы свидетельством недостаточной выразительности системы типов".
VD>Ага и там трепачи ни разу не использовашие макросы на практике пиарили свой хаскель в который захардкожена поддержка монад, а остальное им до лампочки.

Вот любишь ты людей трепачами называть, а сам болтун дальше некуда

Опыт работы со scheme, продакшн код. Макросы активно использовались для описания собственных DSL-ей. Затем перешёл на Haskell, очень сильно не хватало макросов (TH тогда был ещё не таким красивым). Ломка закончилась, когда я увидел, что макросы просто не нужны в большинстве случаев. TH использовал, конечно (generic-код, в основном, синтаксис не менял). Но, разумеется, это был не продакшн код — большей частью прототипирование.

Но ты же скажешь, что речь идёт исключительно о макросах Немерле, верно?

Плюс я там, по моему пару раз даже сказал, что я не сторонник противников макросов. Я противник фанатиков макросов.

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

DG>например, при отладке, при ошибке компиляции, при runtime-ошибке — необходимо решать обратную задачу: на основе текущего частного куска кода — необходимо восстановить на основе чего этот код был получен, и какая общая часть внесла наибольший вклад в данный частный код.

DG>при введении в язык новых понятий вместо макросов — эта задача решается, хотя бы частично. за счет задания жестких правил игры, и фиксации как будет решаться обратная задача при данных правилах.

Мощно задвинул, аж раза два пришлось перечитать. Допустим. Рассмотрим преобразование из общего к частному на примере оператора using. В случае C# варианты (3 штуки) преобразования захардкожены в компилятор. В случае Nemerle они же записаны в макробиблиотеке. В применении и порождаемом AST они вроде как эквивалентны. Теперь обратная задача. В случае Nemerle — я могу навести мыша на макрос и посмотреть в тултипе во что он переписывается, могу подключиться отладчиком к макросу в момент его применения и посмотреть что же он делает с AST и почему делает именно это, могу наконец добавить логгирование в код макроса и получить дамп по всем применениям этого макроса. А что в случае C#? Если отбросить безграничный лимит доверия к МС, то единственное средство анализа — это ILDASM или рефлектор. При этом, если преобразование нетривиальное, вроде yield, есть риск вообще не получить вменяемый исходник и остаться наедине со своими фантазиями.
Налицо несоответствие заявленных преимуществ фиксации перед фактическим положением дел.

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

А где можно скачать видео?
А то после просмотра презентации остались не ясные моменты.

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

WH>Здравствуйте, Кэр, Вы писали:

WH>А где можно скачать видео?
WH>А то после просмотра презентации остались не ясные моменты.

Хм, там видео доступно для повторных просмотров Скачать вроде пока нельзя, если трафик на учете.

Вообще, я в этот форум не просто так запостил — обсудить будет вполне интересно. Если мы тут коллективно что-то не сможем понять — то я задам вопрос Дону по внутреннему email, тут обычно довольно охотно отвечают. Из Эрика Мейерса я в свою время просто вагон полезной информации получил

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

Кэр>>Хм, там видео доступно для повторных просмотров
WH>У меня при переходе по ссылке все время говорит произошла хрен знает какая ошибка.
WH>Другие презентации работают.
WH>Что я делаю не так?

У меня проблем не было. Можно в саппорт сайта стукнуть. Узнаю про видео на скачку — выложу здесь ссылку.

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

Кэр>Выглядит очень круто. Никакого генеренного кода — все типы являются виртуальными и получаются на лету, пока пишется код. При этом есть поддержка сторогой типизации и интеллисенс(!).

Только что посмотрел видео, мне кажется, что type provides это, один в один, описание макросов, точнее одного из use cases'ов их применения. Интересно было бы посмотреть на реализацию, жаль что не доступна.

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

Кэр>Выглядит очень круто.
Можете объяснить что в этом крутого? Имхо, муть какая то. Сложность написания провайдера точно такая же как и для кодогенератора, при этом код можно использовать в любом языке, а провайдер только в одном. Может конечно F# сейчас живет в каком то своем мире где нужен инетлисенс для всех источников данных в мире, но по моему это не задача языка. Лучше бы макросы сделали.

Починили.

Здравствуйте, Рысцов Денис, Вы писали:

РД>Только что посмотрел видео, мне кажется, что type provides это, один в один, описание макросов, точнее одного из use cases'ов их применения. Интересно было бы посмотреть на реализацию, жаль что не доступна.
После того как они это зарелизят я думаю ты сможешь прикрутить это к немерле макросом за несколько часов.
Единственное что нужно будет добавить в компилятор поддержку имен с пробелами.
Можно как у них, а можно просто строковый литерал в качестве имени использовать.
Уверен что Влад это за пару часов сделает.

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

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

WH>Что-то мне подсказывает что таки значительно ниже.
В обоих случаях нам нужно знать всю информацию о типе, на основе которой либо генерируются классы, либо эта информация отдается через интерфейс провайдера. Возьмем например файл ресурсов, где там вам видется снижение сложности?


WH>Это мелкософт при желании может очень легко исправить.
Может в С# 6 оно и появится, только сейчас тогда какой в этом смысл?


WH>Но сделать толковые макросы не просто. Я бы даже сказал что под это дело нужно дизайнить сам язык, а прикрутить макросы к языку который на это не рассчитан очень не просто.
К boo же прикрутили, ничего, может они конечно и не толковые, но это лучше чем ничего.

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

Кэр>Какая разница как это реализовывать? Цимус идеи-то не в этом. Главное — что генеренного кода, которым надо управлять нет, а типизированный код все равно есть.
Видишь суслика? А он есть.
Просто код генерируется компилятором F#.
В данном случае это очевидный хардкод поддержки библиотеки в язык.
Язык с макросами с одной строны может решать эту проблему также эффективно и при этом не нужно будет тащить все это если оно не нужно.

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

WH>Здравствуйте, Кэр, Вы писали:

Кэр>>Какая разница как это реализовывать? Цимус идеи-то не в этом. Главное — что генеренного кода, которым надо управлять нет, а типизированный код все равно есть.
WH>Видишь суслика? А он есть.
WH>Просто код генерируется компилятором F#.

Дык нет. Там есть интерфейс провайдера типа. А компилятор и среда разработки умеет как-то с этим интерфейсом работать. Код генерить тут совсем необязательно — достаточно получить метаданные типа.

WH>В данном случае это очевидный хардкод поддержки библиотеки в язык.
WH>Язык с макросами с одной строны может решать эту проблему также эффективно и при этом не нужно будет тащить все это если оно не нужно.

Это один из вариантов реализации. Всего-навсего. Я знаю, что вы ребята тут немножко безумные по поводу того, что вариант решения проблемы Немерле — это единственный правильный и лучше просто нигде нет — практически для любых задач. Но мне даже начинать дискуссию в эту сторону не особо интересно.

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

D>В обоих случаях нам нужно знать всю информацию о типе, на основе которой либо генерируются классы, либо эта информация отдается через интерфейс провайдера. Возьмем например файл ресурсов, где там вам видется снижение сложности?
Как минимум нам не нужно генерировать сам код.
Текстовая кодогенерация задача не простая и багоемкая.
Также нам не нужно будет возиться с перегенерацией этого кода.

D>Может в С# 6 оно и появится, только сейчас тогда какой в этом смысл?
А этого и сейчас и в F# нет.
Оно на F#3 запланировано.

D>К boo же прикрутили, ничего, может они конечно и не толковые, но это лучше чем ничего.
Ну да. Содрали все с немерла.
Вот только я так и не понял можно ли делать так (см выделенное):

  macro whenmacro (cond, body)
  syntax ("when", "(", cond, ")", body)
  {

    def res1 = Util.locate(cond.Location,
      match (cond)
      {
        | <[ $subCond is $pattern ]> with guard = null
        | <[ $subCond is $pattern when $guard ]> =>
          def res2 = match (pattern)
          {
            | PT.PExpr.Call when guard != null =>
              <[ match ($subCond) { | $pattern when $guard => $body : void | _ => () } ]>
            | PT.PExpr.Call =>
              <[ match ($subCond) { | $pattern => $body : void | _ => () } ]>
            | _ => <[ match ($cond) { | true => $body : void | _ => () } ]>
          }
          res2
        | _ => <[ match ($cond : bool) { | true => $body : void | _ => () } ]>
      });

    res1
  }

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

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

WH>Как минимум нам не нужно генерировать сам код.
WH>Текстовая кодогенерация задача не простая и багоемкая.
У них же код как то генерируется с использованием провайдера, получается мы сравниваем то что есть с тем чего нет. Можно реализовать тот же самый генератор котрый будет использовать их интерфейс но результат будет не на лету а в файл. Задачачи же полностью эквивалетные, разница только в том где хранить то что генерируется, плюс у них часть функционала уже реализовано, но никто не запрещает сделать тоже самое для кодогенератора.
WH>Также нам не нужно будет возиться с перегенерацией этого кода.
Они же файл не каждый раз будут читать, скорее всего кешируют, значит нужно как то отслеживать актуальность кеша. Котогенератор может поступать также. Все те же проблемы и их решения.

D>>К boo же прикрутили, ничего, может они конечно и не толковые, но это лучше чем ничего.
WH>Ну да. Содрали все с немерла.
Если они даже и слабее макросов Немерла, это не умиляет их полезность.

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

D>>>К boo же прикрутили, ничего, может они конечно и не толковые, но это лучше чем ничего.
WH>>Ну да. Содрали все с немерла.
D>Если они даже и слабее макросов Немерла, это не умиляет их полезность.

В Boo есть существенная проблема — нету сопоставления с образцом. Без ПМ-а производить декомпозицию кода — безумие.

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

Кэр>>Дык нет.
WH>А ты внимательно его послушай. Там было несколько оговорок на счет того что нет явной кодогенерации.

Как я сказал — мне довольно все равно, как это реализовано под капотом. Главное тут, что мне управлять сгенерированным кодом не нужно. Даже если там есть какая-то специальная магия, которую нужно понимать для реализации своего провайдера — то она должна хорошо закрываться стандартными классами. Чтобы наружу была выставлена только логика как одни метаданные (например, WMI) конвертируются в метаданные .Net классов — большего там не надо.

Кэр>>Там есть интерфейс провайдера типа. А компилятор и среда разработки умеет как-то с этим интерфейсом работать. Код генерить тут совсем необязательно — достаточно получить метаданные типа.
WH>Вот собственно по этим метаданным код и генерируется.
WH>Обрати внимание на выделенное...
WH>

WH> public interface ITypeProvider
WH>    {
WH>        Type GetType(string name, 
WH>                     BindingFlags bindingAttr);
        
WH>        Expression GetInvokerExpression(
WH>                      MethodBase syntheticMethodBase, 
WH>                      ParameterExpression[] parameters);
WH>
WH>        event System.EventHandler Invalidate;

WH>        Type[] GetTypes();   
WH>    }
WH>

Expression — это expression, это объекты в памяти. Я так думаю что там генерить код макросом, а потом компилировать код совсем необязательно. Не нужны там особо никакие сложные выражения. Либо вообще не нужны методы там, либо это будут очень простые прокси-вызовы.

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

Да тут это обсуждалось миллионы раз. Есть другие точки зрения. Излишняя гибкость бывает тоже вредной. Например, С++ макросы, которые переписывают исходный код несколько раз — даже если там есть проверки — это уже плохой стиль. Просто потому что возникает слишком много сюрпризов при чтении кода. И язык, который позволяет сделать то, что надо с одной стороны и не позволяет отстрелить себе ногу с другой — не является никаким безумием, а является очень правильной альтернативой. Если бы были железные контр-примеры, что, например, C# не позволяет чего-то очень критичного, что позволяет Немерле — то у вас не было бы таких проблем в убеждении всех остальных, что эта степень свободы так необходима.

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

Кэр>Как я сказал — мне довольно все равно, как это реализовано под капотом.
Это плохой подход.
Если не знать как работает инструмент хотябы в общих чертах то можно наломать дров.

Кэр>Expression — это expression, это объекты в памяти.
Которые используются для чего?

Кэр>Я так думаю что там генерить код макросом, а потом компилировать код совсем необязательно. Не нужны там особо никакие сложные выражения. Либо вообще не нужны методы там, либо это будут очень простые прокси-вызовы.
Они просто эту самую генерацию и компиляцию засунули прямо в компилятор.

Кэр>Да тут это обсуждалось миллионы раз. Есть другие точки зрения.
И принадлежат они исключительно тем кто этими механищмами ни разу не пользовался...

Кэр>Излишняя гибкость бывает тоже вредной. Например, С++ макросы, которые переписывают исходный код несколько раз — даже если там есть проверки — это уже плохой стиль.

Ты же не понимаешь о чем говоришь.
Совсем не понимаешь.
Макросы немерле не имеют ничего общего с макросами С++.
Вот например:
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/ComputationExpressions/Test/EnumerableTest.n
Знаешь что нужно было сделать чтобы внутри ComputationExpressions заработал интелисенс?
Ничего. Он сам заработал.

Кэр>Просто потому что возникает слишком много сюрпризов при чтении кода.
Так не возникает.
Я тебе как практик говорю.
И это при том что код на немерле состоит из макросов чуть меньше чем полностью.

Кэр>И язык, который позволяет сделать то, что надо с одной стороны
Так ведь не позволяет.

Кэр>и не позволяет отстрелить себе ногу с другой — не является никаким безумием, а является очень правильной альтернативой.
В том же немерле граблей по факту меньше чем в C#.

Кэр>Если бы были железные контр-примеры, что, например, C# не позволяет чего-то очень критичного, что позволяет Немерле — то у вас не было бы таких проблем в убеждении всех остальных, что эта степень свободы так необходима.
Оба языка полны по тьюрингу.
Проблема в том что на C# писать приходится порой раз в 10 больше.
Но кого это волнует?
Ведь C# сделали в майкрософт. А майкрософт как известно ошибаться не может.

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

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

Почему?

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

WH>>>А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие.
T>>Почему?
WH>А почему бы тогда не захардкодить все библиотеки в язык?
Потому что язык станет слишком сложным.

WH>Чем одна хуже другой?
Универсальностью, популярностью и общеприменимостью.

WH>Почему например сахар для LINQ в C# захардкодили, а сахар для DependencyProperty нет?
Потому что слишком DependencyProperty узкоспециализирован

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

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

WH>>>А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие.
T>>Почему?
WH>А почему бы тогда не захардкодить все библиотеки в язык?
WH>Чем одна хуже другой?
WH>Почему например сахар для LINQ в C# захардкодили, а сахар для DependencyProperty нет?

Тем не менее, ответа на свой вопрос я так и не получил

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

WH>>А почему бы тогда не захардкодить все библиотеки в язык?
T>Потому что язык станет слишком сложным.
Это и есть ответ на твой вопрос.

WH>>Чем одна хуже другой?
T>Универсальностью, популярностью и общеприменимостью.
WH>>Почему например сахар для LINQ в C# захардкодили, а сахар для DependencyProperty нет?
T>Потому что слишком DependencyProperty узкоспециализирован
Это все бла-бла-бла.
Имея макросистему можно реализовать и то и другое.
Причем так что использовать это будут только те кому это надо. А тем кому не надо оно не будет мешать.
Но макросы слишком большая пушка.(С)

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

WH>>>А почему бы тогда не захардкодить все библиотеки в язык?
T>>Потому что язык станет слишком сложным.
WH>Это и есть ответ на твой вопрос.
То есть введя Type providers они сделают язык слишком сложным?

T>>Потому что слишком DependencyProperty узкоспециализирован
WH>Это все бла-бла-бла.
WH>Имея макросистему можно реализовать и то и другое.
Можно, и что?

WH>Причем так что использовать это будут только те кому это надо. А тем кому не надо оно не будет мешать.
Ну да, есть очевидные плюсы, как и очевидные минусы. Но непонятно откуда взялось это: "А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие"?

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


T>>То есть введя Type providers они сделают язык слишком сложным?
WH>Конечно.
WH>Ведь они мало кому нужны.
Очевидно, что авторы нововведения с тобой не согласны.

WH>>>Причем так что использовать это будут только те кому это надо. А тем кому не надо оно не будет мешать.
T>>Ну да, есть очевидные плюсы, как и очевидные минусы.
WH>Плюсы есть.
WH>Минусов не вижу.
WH>Ни одного.
Вот тебе минус: нестандиртизованность получившегося решения.

T>>Но непонятно откуда взялось это: "А вот хардкодить в язык то что можно сделать билиотекой это действительно безумие"?
WH>Я даже не знаю как с тобой разговаривать.
WH>Ты же сам сказал что впихивание в язык всего подряд приведет к черезмерному усложнению языка.
Всего подряд — да. А если не всего подряд?

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

T>Очевидно, что авторы нововведения с тобой не согласны.
Авторы просто макросистему не осилили.

T>Вот тебе минус: нестандиртизованность получившегося решения.
И чем это отличается от библиотеки?
Прежде чем отвечать хорошо подумай.

T>Всего подряд — да. А если не всего подряд?
Мой поинт в том что вообще ничего что можно реализовать библиотекой в язык тащить не надо.

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

T>>Очевидно, что авторы нововведения с тобой не согласны.
WH>Авторы просто макросистему не осилили.
Я не в курсе.

T>>Вот тебе минус: нестандиртизованность получившегося решения.
WH>И чем это отличается от библиотеки?
WH>Прежде чем отвечать хорошо подумай.
Ничем не отличается, если библиотека стандартизована, что фактически делает её частью языка (как, например STL).

T>>Всего подряд — да. А если не всего подряд?
WH>Мой поинт в том что вообще ничего что можно реализовать библиотекой в язык тащить не надо.
Это я понял. Просто обоснований этому нет. Просто вера?

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

T>>Всего подряд — да. А если не всего подряд?
WH>Мой поинт в том что вообще ничего что можно реализовать библиотекой в язык тащить не надо.

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

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

V>С оговоркой о приемлимом синтаксисе. Только в нем и проблема. Не хотят давать инструмент с изменяемым синтаксисом.
Ну а кто тебя заставляет жрать только то что дает мелкософт?

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

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

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

Кэр>>>Да тут это обсуждалось миллионы раз. Есть другие точки зрения.
WH>>И принадлежат они исключительно тем кто этими механищмами ни разу не пользовался...
Кэр>Ой началось.
А что разве это не так?
Просто я вижу кучу народа которая на основе своего незнания расказывает мне как в немерле все плохо из-за макросов.

Кэр>Я же вас прошу услышать (и я не первый, и я не последний) — макросы приносят проблемы.
Какие?
Давай конкретно.

Кэр>Код получается слишком гибкий.
Я не знаю что такое слишком гибкий код. Это субъективно.
За то я знаю что такое в 10 раз меньше кода. И это как ни крути объективно.

Кэр>Когда семантика кода при одном и том же синтаксисе начинает очень сильно зависеть от подключенных макросов (а также их версии).
И чем это отличается об библиотеки классов?
Хорошо подумай прежде сем ответить.

Кэр>И возможно порядка подключения.
Опять пошли фантазии.

Кэр>После этого проблемы с порядком подключения заголовков в С++ — выглядят детской шалостью.
Я же говорю опыт С++ тут не применим. Вообще.
Кстати чтоб ты знал С++ я очень хорошо знаю. И знаю о всех проблемах его макросов и шаблонов.

Кэр>Мне абсолютно неинтересно смотреть на решения до того, как была сформулирована проблема, которая вроде как решена данным кодом.
Тебя в гугле забанили?

Кэр>Об этом я писал в абзаце выше, который вы разодрали на цитаты. Я повторю еще раз — мне не жалко. Но вы, я думаю, еще раз меня не услышите. Так вот — прежде чем втирать людям решение, надо показать проблему, которая решается. Это идеально. Это то, чтобы было при переходе от ассемблера к С, от С к С++, от С++ к C#. Менее идеально — показать людям, что проблема есть, а потом показать как она будет решена. Я об этом давно говорил Владу — он меня тоже не услышал.
Ну так мы показываем.
Но они просто игнорируются.

Кэр>Вы тут кричите, какие замечательные макросы — а я вижу проблемы, которые они приносят.
Вот только практики с тими проблемами почемуто не сталкиваются.
Может по тому что ты эти проблемы придумал?

Кэр>И не вижу критичных проблем, которые они должны решить.
Ну да. Сократить код раз в 10 это конечно нихрена не критично.

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

Автор: WolfHound
Дата: 26.10.10

я приводил пример ДСЛя который можно сделать для разработки интерактивных ВЕБ приложений.
Но ты сейчас опять скажешь что тебе это не надо.
Мы просто не в состоянии найти примеры для каждого ибо вас очень много.

Кэр>Забавный вы. Вы похоже тоже верите, что МС опять обманул весь мир.
Нет.
Я просто понимаю что для огромного числа людей все инструменты на которых не стоит лычка мегакорпорации отстой по определению.

Кэр>Сделайте язык — который имеет внятную нишу и внятное применение — и будет у вас аудитория.
Так она у нас есть.
И получает существенные преимущества перед конкурентами.

Кэр> Посмотрите на пример Ruby.
И что я там должен увидить?

Кэр>А если МС был неправ — то МС подтянется, если сможет.
Не сможет.

Кэр>Если не сможет — МС умрет и кто-то другой будет делать популярные средства разработки.
Этот зомби еще очень долго будет всех пугать.

Кэр>И никакой теории заговора.
Ты не понял. Я не про заговор. Я про банальную глупость.

H>Вы пишите на Nemerle? ХОЧУ К ВАМ!!!
Что и в Минск бы переехал?

Тот проект про который я рассказываю уже пару лет как начался

Автор: hi_octane
Дата: 14.02.08

, пережил пару масштабных релизов с апгрейдами и сейчас на тех-поддержке. Кардинально новая версия, с WPF вместо WinForms, VS2010/.NET 4 вместо 2008/.Net 3.5, и всякими модными рюшечками ещё только обсужается, но что или будет Nemerle или не договоримся — 100%.

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

H>>Вы пишите на Nemerle? ХОЧУ К ВАМ!!!
_>Что и в Минск бы переехал?

Ух.

_>Тот проект про который я рассказываю уже пару лет как начался

Автор: hi_octane
Дата: 14.02.08

, пережил пару масштабных релизов с апгрейдами и сейчас на тех-поддержке. Кардинально новая версия, с WPF вместо WinForms, VS2010/.NET 4 вместо 2008/.Net 3.5, и всякими модными рюшечками ещё только обсужается, но что или будет Nemerle или не договоримся — 100%.

Сейчас мы почти .NET 4.0 ready (почти — это потому что dynamic-ов временно не поддерживаем).

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

Кэр>Для интеллисенса и компиляции. Конкретно этот вызов я бы предположил что используется для вызова несуществующих методов/свойств несуществующих типов.

А как ты думаешь тип Expression есть в текущих версиях дотнета? И если есть, то в каком нэймспэйсе находится этот класс?

И еще вопрос. Как можно компилировать несуществующий код?

F# — это статически-типизированный компилируемый язык. Интерпретатора у него нет. Даже REPL реально компилирует код перед выполнением. Так что не трудно догадаться, что вся магия завязана на LINQ-оские деревья выражений.

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

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

T>Почему?

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

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

WH>>Почему например сахар для LINQ в C# захардкодили, а сахар для DependencyProperty нет?
T>Потому что слишком DependencyProperty узкоспециализирован

Ну, вот и подумай, что мешает иметь реализацию для DependencyProperty?
Правильный ответ — усложнение языка. А если мы имеем возможность не хардкодить узкоспециализированные (Да что уж там? Любые!) возможности в язык, а подключать их в виде DLL-ки (эдакого плагина к компилятору) и открытого пространства имен (в котором описано расширение), то мы снимаем моральный аспект проблемы. Теперь можно расширять язык как угодно. Те кому это расширение нужно смогут использовать его в своих проектах. Более того, те кому это нужно смогут и сами сделать нужные им расширения.

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

T>То есть введя Type providers они сделают язык слишком сложным?

WH>>Имея макросистему можно реализовать и то и другое.
T>Можно, и что?

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

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

WH>>Ты же сам сказал что впихивание в язык всего подряд приведет к черезмерному усложнению языка.
T>Всего подряд — да. А если не всего подряд?

Дык, а кто будет решать что нужно в языке, а что нет? Дядя? А почему не я? Ведь я же язык использую!

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

T>>>Вот тебе минус: нестандиртизованность получившегося решения.
WH>>И чем это отличается от библиотеки?
WH>>Прежде чем отвечать хорошо подумай.
T>Ничем не отличается, если библиотека стандартизована, что фактически делает её частью языка (как, например STL).

У библиотеки есть ряд отличий:
1. Библиотеку можно не использовать. И именно ты будешь решать делать это или нет.
2. Библиотеку можно написать самому.
3. Библиотеку можно найти в Интернет, заказать ее разработку или купить ее у третьих лиц.

А так, да. Стандартная библиотека — фактически часть языка. Но я вот никогда не использовал процентов 50 дотнетных библиотек и никак не страдаю от их незнания. А от незнания фич языка я страдал бы.

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

L>P.S. Была уже тема, кстати — "Являются ли макросы свидетельством недостаточной выразительности системы типов".

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

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

Кэр>>Выглядит очень круто.
D>Можете объяснить что в этом крутого? Имхо, муть какая то. Сложность написания провайдера точно такая же как и для кодогенератора, при этом код можно использовать в любом языке, а провайдер только в одном. Может конечно F# сейчас живет в каком то своем мире где нужен инетлисенс для всех источников данных в мире, но по моему это не задача языка. Лучше бы макросы сделали.

А мне понравилось. В команде F# вообще ребята криативные. Они вот нам разработали все что нужно для реализации ComputationExpressions. Сейчас еще одну интересную фичу делают. Молодцы! Главное, чтобы в C# все это не помещали.

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

WH>>Что-то мне подсказывает что таки значительно ниже.
D>В обоих случаях нам нужно знать всю информацию о типе, на основе которой либо генерируются классы, либо эта информация отдается через интерфейс провайдера. Возьмем например файл ресурсов, где там вам видется снижение сложности?

На самом, деле нужно смотреть на код провайдера.

WH>>Это мелкософт при желании может очень легко исправить.
D>Может в С# 6 оно и появится, только сейчас тогда какой в этом смысл?

А может и в 5.0. Вон, в МС все детали его скрывают. Может готовят фурор?

WH>>Но сделать толковые макросы не просто. Я бы даже сказал что под это дело нужно дизайнить сам язык, а прикрутить макросы к языку который на это не рассчитан очень не просто.
D>К boo же прикрутили, ничего, может они конечно и не толковые, но это лучше чем ничего.

К Бу их 5 лет прикручивали, и все равно получилось не очень здорово. Вот немерле сразу проектировали под макры. Джае паттерн-матчинг и варианты и те для его реализации нужны, на самом деле. Так что не все так просто.

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

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

D>К boo же прикрутили, ничего, может они конечно и не толковые, но это лучше чем ничего.

А он вообще жив? А то как автора взяли на работу куда-то, новых новостей на их сайте я не видел. Последняя появилась около года назад.

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

H>В Boo есть существенная проблема — нету сопоставления с образцом. Без ПМ-а производить декомпозицию кода — безумие.

Не. Они что-то там такое (с похожим именем) сварганили (еще более года назад). Вот только похоже, что как и их макры — это пародия на сами знаете что.

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

VD>А он вообще жив? А то как автора взяли на работу куда-то, новых новостей на их сайте я не видел. Последняя появилась около года назад.
Судя по комитам, что то делается, может к релизу 1.0 готовятся.

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

VD>>А он вообще жив? А то как автора взяли на работу куда-то, новых новостей на их сайте я не видел. Последняя появилась около года назад.
D>Судя по комитам, что то делается, может к релизу 1.0 готовятся.

У них комиты как-то не видно. Где их можно поглядеть?

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


VD>У них комиты как-то не видно. Где их можно поглядеть?
http://github.com/bamboo/boo/commits/master

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

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

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

T>>Почему?

VD>Поставим вопрос по другому. Представь, что ты имеешь возможность получить одно и то же в виде бибилотеки которую ты потенциально можешь написать сам и в виде хардкода в языке или чем-то еще. Что ты выберешь?

Выберу либо стандартную библиотеку, либо хардкод в языке (без разницы).

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

VD>Теперь можно расширять язык как угодно. Те кому это расширение нужно смогут использовать его в своих проектах. Более того, те кому это нужно смогут и сами сделать нужные им расширения.
Это уже из другой оперы. Речь идет не о разработке новых расширений, а о том, чем плохи Type providers из-за того, что они будут сделаны в виде фичи языка. Усложнение языка, ок, есть такое. Что-то еще?

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

VD>А то, что если что-то можно положить в библиотеку, то не нужно это пихать в язык.
VD>К тому же возможности разработчиков языков очень ограничены. На всех фич не напасешься.
В данном случае разработчики языка таки нашли возможность реализовать фичу.

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

VD>У библиотеки есть ряд отличий:
VD>1. Библиотеку можно не использовать. И именно ты будешь решать делать это или нет.
Фичу тоже. Я вот, например, не пользуюсь указателями в C#, и мне ни жарко ни холодно от их наличия.

VD>2. Библиотеку можно написать самому. 3. Библиотеку можно найти в Интернет, заказать ее разработку или купить ее у третьих лиц.
Можно, но при наличии стандартной это делать неправильно.

VD>А так, да. Стандартная библиотека — фактически часть языка. Но я вот никогда не использовал процентов 50 дотнетных библиотек и никак не страдаю от их незнания. А от незнания фич языка я страдал бы.
Почему страдал бы?

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

VD>>Поставим вопрос по другому. Представь, что ты имеешь возможность получить одно и то же в виде бибилотеки которую ты потенциально можешь написать сам и в виде хардкода в языке или чем-то еще. Что ты выберешь?

T>Выберу либо стандартную библиотеку, либо хардкод в языке (без разницы).

Ты можешь написать стандартную библиотеку для какого либо языка?

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

VD>>2. Библиотеку можно написать самому. 3. Библиотеку можно найти в Интернет, заказать ее разработку или купить ее у третьих лиц.
T>Можно, но при наличии стандартной это делать неправильно.

Ты видел в стандартной библиотеке реализацию DependencyProperty? Или автоматическое INotifyPropertyChange?
Или автоматический маппинг объектов?

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

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

VD>>>Поставим вопрос по другому. Представь, что ты имеешь возможность получить одно и то же в виде бибилотеки которую ты потенциально можешь написать сам и в виде хардкода в языке или чем-то еще. Что ты выберешь?

T>>Выберу либо стандартную библиотеку, либо хардкод в языке (без разницы).

H>Ты можешь написать стандартную библиотеку для какого либо языка?

Разве это не очевидно?

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

H>Ты видел в стандартной библиотеке реализацию DependencyProperty? Или автоматическое INotifyPropertyChange?
H>Или автоматический маппинг объектов?
Нет, и что?

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


WH>Я двумя руками за то чтобы на систему типов переложить все что можно но: Попробуй на досуге из системы типов приконектиться к БД или файлик прочитать. Или как в этой теме поднять произвольный ITypeProvider и по нему нагенерировать типы и код для доступа к внешним источникам данных.

Чтобы файлик прочитать и т. п. нужна только нормальная поддержка compile-time вычислений (как например в D), а не мощная система типов.

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

WH>>Я двумя руками за то чтобы на систему типов переложить все что можно но: Попробуй на досуге из системы типов приконектиться к БД или файлик прочитать. Или как в этой теме поднять произвольный ITypeProvider и по нему нагенерировать типы и код для доступа к внешним источникам данных.
FR>Чтобы файлик прочитать и т. п. нужна только нормальная поддержка compile-time вычислений (как например в D), а не мощная система типов.
Прочитай еще раз то на что ты отвечаешь. И на этот раз внимательнл.

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

FR>>>Чтобы файлик прочитать и т. п. нужна только нормальная поддержка compile-time вычислений (как например в D), а не мощная система типов.
WH>>Прочитай еще раз то на что ты отвечаешь. И на этот раз внимательнл.
FR>Макросы для этого тоже не нужны.
Осталось понять чем выделенное не макросы?

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

FR>>>>Чтобы файлик прочитать и т. п. нужна только нормальная поддержка compile-time вычислений (как например в D), а не мощная система типов.
WH>>>Прочитай еще раз то на что ты отвечаешь. И на этот раз внимательнл.
FR>>Макросы для этого тоже не нужны.
WH>Осталось понять чем выделенное не макросы?

Да ни чем вроде не макросы, синтаксис и семантику не меняют, только тихо мирно считают во время компиляции.

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

FR>>>>>Чтобы файлик прочитать и т. п. нужна только нормальная поддержка compile-time вычислений (как например в D), а не мощная система типов.
хъ
FR>Да ни чем вроде не макросы, синтаксис и семантику не меняют, только тихо мирно считают во время компиляции.
Что-то твои слова не вяжутся с выделенным.

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

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

пример:
в .net 2.0 добавили generics, после этого типы string и NameValueCollection (которые были реализованы еще до .net 2.0) стали вести себя по разному: string к generic интерфейсу IEnumerable<char> конвертится, а вот NameValueCollection уже к generics интерфейсу IDictionary<string,string> — не конвертится, и это коррелирует с тем, что string — это часть языка, а NameValueCollection — тип из внешней библиотеки.

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

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

DG>это утверждение подразумевает, что при реализации в виде библиотеки нет минусов, а это не так.
DG>при решении в виде библиотеке сложнее обеспечивать интеграционную полноту.
Это очередной баззворд который я не понимаю.
За то я прекрасно понимаю сокращение кода в 10 раз за счет убирания всякого не нужного мусора.

DG>и таких примеров можно привести множество: когда фичи введенные в язык дружат с другом, а вот внешние библиотеки между собой часто не дружат.
string это тупо алиас для System.String
Те они изменили библиотеку и отнаследовали System.String от IEnumerable<char>.
А для NameValueCollection этого не сделали.
Вот собственно и все.
Чисто правки библиотеки.
Так что ты тут ни разу не угадал.

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

DG>и чё? что-то умное что-ли сказал?
Не делай вид что ты сказал что-то умное.

DG>речь-то о том — фича в язык интегрирована, или нет?
DG>и речь идет о том, что если фича в язык интегрирована, то она с большей вероятностью будет дружить с другими фичами, а вот если это просто внешняя либа — то интеграции скорее всего не будет, т.к. некому ее будет обеспечивать.
И какже люди пользуются внешними либами?
Они же страшно подумать не интегрированны.

Возьмем к примеру ASP.NET и BLToolKit.
Ну и что что они о существовании друг друга даже не подозревают. Это не мешает использовать их совместно.

С макро библиотеками таже фигня.
Уж поверь практику.

DG>речь-то о том — фича в язык интегрирована, или нет?
DG>и речь идет о том, что если фича в язык интегрирована, то она с большей вероятностью будет дружить с другими фичами, а вот если это просто внешняя либа — то интеграции скорее всего не будет, т.к. некому ее будет обеспечивать.
Уж одна контора свои фичи подружить между собой думаю сдюжит. Вот есть BCL, в которой объявлен IDisposable, и Monitor. Было бы макропрограммирование — using и lock был бы объявлены там же самим же MS, а не где-то в недрах языка. Обеспечивать совместимость своих поделок с BCL — работа авторов поделок. Точно также как поддержка новых версий фреймворка и WPF — работа авторов GUI библиотек вроде DevExpress или там Syncfusion. И если бы они в своих библиотеках объявили макру для INotifyPropertyChanged, то и совместимость своей макры с новыми версиями WPF поддерживали бы сами. Чё тут неясно?

А выбор библиотек(с макросами или нет) для проекта — уже забота и ответственность лида, иногда прожект-менеджера, а изредка даже клиента. Их работа считать риски от использования библиотек, и то насколько эти риски покрываются бенефитами вроде сэкономленных человеко-часов ну или там LOC'ов, кто в чём считает. Если вы боитесь что макросы какой-то библиотеки встанут вам боком — запретите их использование, и фигачьте код, который делает макрос, вручную. Если вы боитесь что два макроса с разных библиотек могут наделать друг-другу гадостей (не видел, но допустим) — запретите тот который вам меньше нужен. И делайте за него всю работу.

WH>Язык с макросами с одной строны может решать эту проблему также эффективно

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

generic/template-ы можно делать и через макросы, но намного лучше они решаются через специализированный инструмент generics/template.


в чем причина? причина в том — что макросы не умеют решать обратную задачу...
прямая задача — из общего представления сгенерить частное представление(код).
обратная задача — на основе частного представления понять как оно бьется с общим представлением.

макросы по сути вводит доп. абстрактный слой, но при этом они не фиксируют понятия, характеристики, операции, правила игры на этом уровне абстракции.

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

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

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

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

DG>например, при отладке, при ошибке компиляции, при runtime-ошибке — необходимо решать обратную задачу: на основе текущего частного куска кода — необходимо восстановить на основе чего этот код был получен, и какая общая часть внесла наибольший вклад в данный частный код.
Ты исходишь из не верных посылок и как следствие у тебя получается фигня совершенно не соответствуюшая действительности.
Дело в том что "обратную задачу" ни кто ни когда не решает.
Всегда решают только "прямую".
Но при ее решении нужно не забыть протащить информацию о том из чего мы трансформируем код.
Учитывая что обычно макросы выглядят примерно так:

  /** shortcut for [if (cond) () else body] */
  macro @unless (cond, body)
  syntax ("unless", "(", cond, ")", body)
  {
    <[ match ($cond) { | false => $body : void | _ => () } ]>
  }

Эта информация простаскивается автоматически.

_>В случае Nemerle — я могу навести мыша на макрос и посмотреть в тултипе во что он переписывается, могу подключиться отладчиком к макросу в момент его применения и посмотреть что же он делает с AST и почему делает именно это, могу наконец добавить логгирование в код макроса и получить дамп по всем применениям этого макроса.

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

в данном случае, есть следующие автоматически решаемые задачи, которые требуют решения обратной задачи:
1. выведение типов
2. подсветка синтаксиса
3. intellisense
4. определение области видимости
5. определение что переменные не используются без своих объявления
и т.д.

если using — макрос, то как автоматически решать все вышеприведенные задачи?

задачи 1, 4, 5 — можно пробовать решать через раскрытие макроса, и анализ получившегося кода,
но если случилась ошибка, то непонятно как привязать ошибку к месту в исходном коде.

WH>Дело в том что "обратную задачу" ни кто ни когда не решает.
WH>Всегда решают только "прямую".

в немерле может и не решают, а в других системах решают.

DG>если using — макрос, то как автоматически решать все вышеприведенные задачи?
Всё уже давно решено. Автокомплит подхватывает, интеллисенс подсказывает, синтаксис подсвечивается, типы выводятся лучше чем в C#, области видимости определяются корректно. Если действительно хочешь знать как — посмотри на сорцы Nemerle. Пруф например здесь

Автор: WolfHound
Дата: 31.10.10

, читать в окрестности слов "Он сам заработал".

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

DG>задачи 1, 4, 5 — можно пробовать решать через раскрытие макроса, и анализ получившегося кода,
DG>но если случилась ошибка, то непонятно как привязать ошибку к месту в исходном коде.
Вот только у немерла работает и подсветка синтаксиса и автокомплит и навигация и отладка и сообщения об ошибках.
И это при том что код чуть меньше чем польностью состоит из макросов.
Если не веришь можешь поставить интеграцию и посмотреть.

А во всем виноват класс

  public class Located
  {
    public mutable loc : Location;

    public this ()
    {
      loc = LocationStack.Top();
    }
    public this (loc : Location)
    {
      this.loc = loc;
    }
    public IsGenerated : bool { get { loc.IsGenerated } }

    public Location : Location
    {
      get { loc }
      set { loc = value; }
    }
  }

От которого наследуется AST

  public variant PExpr : Located

Location содержит номер файла, позицию начала и позицию конца.

Те вся информация у нас есть.
Все что нам нужно это не потерять ее при решении прямой задачи.
И на практике в подавляющем большенстве случаев для этого вообще ничего делать не приходится.

Короче заканчивай искать фатальные недостатки в том о чем ты не знаешь ровным счетом ничего.

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

DG>в немерле может и не решают, а в других системах решают.
Ссылки на статьи с описанием решения "обратной задачи" показать можешь?

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

Кэр>Дон прямо сейчас рассказывает о type providers.
Кэр>http://bit.ly/bfWDkA

Да, забавно. Эдакий интером с динамичским миром для статически-типизированных языков. Намного лучше чем денамики в 4-ом Шарпе. Еще бы не затягивать презентацию на столько времени, а говорить по сути... плюс по больше информации и было бы совсем здорово.

Кэр>Выглядит очень круто. Никакого генеренного кода — все типы являются виртуальными и получаются на лету, пока пишется код. При этом есть поддержка сторогой типизации и интеллисенс(!).

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

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

H>>Ты видел в стандартной библиотеке реализацию DependencyProperty? Или автоматическое INotifyPropertyChange?
H>>Или автоматический маппинг объектов?
T>Нет, и что?

А то, что это как раз то что невозможно положить в обычную библиотеку потому, но слишком специфично чтобы встраивать в язык. По этому ты никогда не увидишь средств автоматизирующих DependencyProperty и INotifyPropertyChange. Меж тем в виде макроса эти проблемы автоматизируются на раз. Вот здесь можно найти пример автоматизации DependencyProperty.

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

WH>>Я двумя руками за то чтобы на систему типов переложить все что можно но: Попробуй на досуге из системы типов приконектиться к БД или файлик прочитать. Или как в этой теме поднять произвольный ITypeProvider и по нему нагенерировать типы и код для доступа к внешним источникам данных.

FR>Чтобы файлик прочитать и т. п. нужна только нормальная поддержка compile-time вычислений (как например в D), а не мощная система типов.

Он об этом и говорил. Только мощная как в Немреле, а не как в Ди. Потому как в Ди пока что жалкое подобие.

ЗЫ

Вообще, конечно надо реализовать немерл в нэйтив виде и закрыть тем самым тему Ди .

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

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

Врешь. Если они ничего не меняют, то и смысла в них нет.

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

WH>А во всем виноват класс

WH>  public class Located
WH>  {
WH>    public mutable loc : Location;

WH>    public this ()
WH>    {
WH>      loc = LocationStack.Top();
WH>    }
WH>    public this (loc : Location)
WH>    {
WH>      this.loc = loc;
WH>    }
WH>    public IsGenerated : bool { get { loc.IsGenerated } }

WH>    public Location : Location
WH>    {
WH>      get { loc }
WH>      set { loc = value; }
WH>    }
WH>  }

WH>От которого наследуется AST

WH>Короче заканчивай искать фатальные недостатки в том о чем ты не знаешь ровным счетом ничего.

Мне это только кажется, или во главе всего, получается, изменяемый тип, который, в дефолтовом конструкторе использует некое изменяемое глобальное состояние

Кстати, как на счёт слов о том, что свойства-акессоры к открытым полям не есть гуд? А что же мы видим здесь? Открытое изменяемое поле

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

WH>От этого никуда не дется ибо в режиме интелисенса при редактировании нужно корректировать локешены.
WH>Изначально компилятор писали студенты.
WH>Там еще много страшного если посмотреть.
WH>Во второй версии ничего подобного не будет.
WH>Осталось по недосмотру. Ща сделаю его приватным.

Спасибо, всё понятно, всё отлично

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

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

H>>>Ты видел в стандартной библиотеке реализацию DependencyProperty? Или автоматическое INotifyPropertyChange?
H>>>Или автоматический маппинг объектов?
T>>Нет, и что?

VD>А то, что это как раз то что невозможно положить в обычную библиотеку потому, но слишком специфично чтобы встраивать в язык. По этому ты никогда не увидишь средств автоматизирующих DependencyProperty и INotifyPropertyChange. Меж тем в виде макроса эти проблемы автоматизируются на раз. Вот здесь можно найти пример автоматизации DependencyProperty.

Какое это имеет отношение к Type providers?

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

T>Какое это имеет отношение к Type providers?
Type providers без проблем делаются макросом.

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

WH>Осталось по недосмотру. Ща сделаю его приватным.
Вот собственно все что пришлось поправить:
http://code.google.com/p/nemerle/source/detail?r=9326#
3 использования в компиляторе.
1 в стандартной библиотеке
13 в интеграции. Причем как я понимаю тот кусок по факту не используется.
2 в сниппетах.

Короче это поле почти не использовалось.

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

WH>Короче это поле почти не использовалось.

Не сомневаюсь. Кстати, можно ещё поправить: AST.n/TextPoint/Offcet на Offset

А автосвойств с авто-mutable полем нет?

"Util.ice" — замечательно

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

_FR>А автосвойств с авто-mutable полем нет?

Их есть:

class Foo { public Bar : string { get; set; } }

_FR>"Util.ice" — замечательно

Это тот самый "internal compiler error".

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

_FR>>А автосвойств с авто-mutable полем нет?

H>Их есть:

H>class Foo { public Bar : string { get; set; } }

Отлично, а почему не используется (в данном конкретном месте)?

_FR>>"Util.ice" — замечательно
H>Это тот самый "internal compiler error".

Util.vodka и Util.juice в стандартной поставке имеются или нужно самому изобретать?

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

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

_FR>>>А автосвойств с авто-mutable полем нет?

H>>Их есть:
_FR>

H>>class Foo { public Bar : string { get; set; } }
_FR>

_FR>Отлично, а почему не используется (в данном конкретном месте)?

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

_FR>>>"Util.ice" — замечательно
H>>Это тот самый "internal compiler error".

_FR>Util.vodka и Util.juice в стандартной поставке имеются или нужно самому изобретать?

Вот этого не понял.

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

H>>Их есть:
_FR>

H>>class Foo { public Bar : string { get; set; } }
_FR>

_FR>Отлично, а почему не используется (в данном конкретном месте)?

Есть даже круче вещи:

class Foo {
  public Bar : string { mutable bar : string; get { bar } set { bar = value } }
}

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

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

WH>>Дело в том что "обратную задачу" ни кто ни когда не решает.
WH>>Всегда решают только "прямую".

DG>в немерле может и не решают, а в других системах решают.

Дай угадаю — это при генерации кода текстовыми генераторами вроде T4?

Ну, так даже для них есть средства — #pragma line. Неудобно, конечно, но проблему решить можно.
В прочем, текстовая генерация есть текстовая генерация.

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

VD>>А то, что это как раз то что невозможно положить в обычную библиотеку потому, но слишком специфично чтобы встраивать в язык. По этому ты никогда не увидишь средств автоматизирующих DependencyProperty и INotifyPropertyChange. Меж тем в виде макроса эти проблемы автоматизируются на раз. Вот здесь можно найти пример автоматизации DependencyProperty.

T>Какое это имеет отношение к Type providers?

Дык их тоже можно было бы положить в мако-библиотеку... при наличии макросов.

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

Кэр>Забавно смотреть, как он показывал как он пишет строго-типизированный код к WMI, а потом показывает, как это было бы в старом стиле и для этого использует интеллисенс нового подхода, как подсказку

Битва

Автор: alexeiz
Дата: 18.09.10

с гидрой по имени WMI продолжается! На этот раз в бой брошены функциональные языки. Но сдается мне, что это еще не конец. У гидры на одну отрубленную голову отростает две.

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

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

Что-то другое Я код не генерю и этим процессом не управляю. И очень рад этому факту. Мне реально все равно, как вы называете этот процесс внутри компилятора и почему вам так хочется выделить именно его.

Кэр>>В этом случае — нам не стоит использовать слово "кодогенерация". Ибо это процесс подготовки исходников перед процессом запуски компилятора. А макросы — это один из видов кодогенерации.
WH>Не надо играть словами.
WH>Генерация кода она и есть генерация кода.
WH>А кто и в каком виде этим занимается дело десятое.

Весь смысл термина заключается именно в том, кто и чем занимается. В классике кодогенерация — это как раз генерирование исходников перед компиляцией.

WH>Кстати если подходить к макросам немерла с твоих позиций то они кодогенерацией не занимаются... ибо с исходником ничего не делают.

Мне довольно все равно как классифицировать макросы Немерле, так как я их не использую.

Кэр>>Код получается слишком гибкий.
WH>Я не знаю что такое слишком гибкий код. Это субъективно.
WH>За то я знаю что такое в 10 раз меньше кода. И это как ни крути объективно.

Архиватор еще лучше код жмет. С тем же уровнем объективности. Поддержку среды разработки, плагинов вроде Решарпера, плагинов к самому Решарперу, хорошую поддержку компилятора никто не отменял. А вы махаете флагом — а ну все побежали на Немерле с C# — у нас все здорово. JetBrains уже выпускает версию Решарпера с поддержкой Немерле? Или может вам надо спуститься на грешную землю и понять все-таки кто для вас является целевой аудиторией?

Кэр>>Когда семантика кода при одном и том же синтаксисе начинает очень сильно зависеть от подключенных макросов (а также их версии).
WH>И чем это отличается об библиотеки классов?
WH>Хорошо подумай прежде сем ответить.

Уже ответил выше. Поддержка тулами. Я очень легко могу управлять подключениями библиотек. В случае с макросами возможных side-effect'ов становится в разы больше. В общем случае это большая проблема, потому что резко увеличивает область, которую нужно проверять, когда что-то идет не так.

Кэр>>Мне абсолютно неинтересно смотреть на решения до того, как была сформулирована проблема, которая вроде как решена данным кодом.
WH>Тебя в гугле забанили?

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

Кэр>>Об этом я писал в абзаце выше, который вы разодрали на цитаты. Я повторю еще раз — мне не жалко. Но вы, я думаю, еще раз меня не услышите. Так вот — прежде чем втирать людям решение, надо показать проблему, которая решается. Это идеально. Это то, чтобы было при переходе от ассемблера к С, от С к С++, от С++ к C#. Менее идеально — показать людям, что проблема есть, а потом показать как она будет решена. Я об этом давно говорил Владу — он меня тоже не услышал.
WH>Ну так мы показываем.
WH>Но они просто игнорируются.

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

Кэр>>И не вижу критичных проблем, которые они должны решить.
WH>Ну да. Сократить код раз в 10 это конечно нихрена не критично.

10 раз взято с потолка. Отсутствии поддержки языка тулами — вот это критично. Были бы достойные причины отказаться от тулов и выиграть в чем-то другом — уже отказывались бы по все миру и использовали Немерле.

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

Автор: WolfHound
Дата: 26.10.10

я приводил пример ДСЛя который можно сделать для разработки интерактивных ВЕБ приложений.
WH>Но ты сейчас опять скажешь что тебе это не надо.
WH>Мы просто не в состоянии найти примеры для каждого ибо вас очень много.

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

Кэр>>Забавный вы. Вы похоже тоже верите, что МС опять обманул весь мир.
WH>Нет.
WH>Я просто понимаю что для огромного числа людей все инструменты на которых не стоит лычка мегакорпорации отстой по определению.

А ну да, да. Все люди идиоты, а Микрософт их всех обманул.

Кэр>>Сделайте язык — который имеет внятную нишу и внятное применение — и будет у вас аудитория.
WH>Так она у нас есть.
WH>И получает существенные преимущества перед конкурентами.

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

Кэр>> Посмотрите на пример Ruby.
WH>И что я там должен увидить?

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

Кэр>>А если МС был неправ — то МС подтянется, если сможет.
WH>Не сможет.

Точно. Пора бежать продавать последние акции MS — конец он уже близок.

Кэр>>Если не сможет — МС умрет и кто-то другой будет делать популярные средства разработки.
WH>Этот зомби еще очень долго будет всех пугать.

Фуф. Ну хоть прямо сразу бежать продавать акции не надо.

Кэр>>И никакой теории заговора.
WH>Ты не понял. Я не про заговор. Я про банальную глупость.

Ага, я тоже. Но вы можете тратить свое время как вам будет угодно