Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, eao197, Вы писали:
E>>Disclaimer: насколько я помню, об удобстве вычисления факториала заговорил Oyster
O>Факториал — это шелуха, как ты сам понимаешь. То, почему на Nemerle может быть удобнее делать compile-time вычисления, уже звучало неоднократно...
А кому они нужны compile-time вычисления? Вы бы еще число ПИ в компайл тайме вычислили.
Реально делается все проще: вставляется константа или таблица констант и все.
У меня в проекте например юзается предварительно посчитанная таблица биномиальных коэффициентов. За пять секунд была написана программка которая считает и выводит эти коэффициенты в виде обьявления сишного массива который затем был вставлен в сырец.
VladD2 wrote: > C>Вы еще скажите, что остальные языки .NET кардинально отличаются от C#... > Еще как скажу. Сравни, например, F# (Caml), Лисп или Питон. Неужели они > копии C#-а?
.NET-языки это: J#, C#, VB.NET. Все. Ну еще можно туда добавить F#.
Всякие Iron.Python'ы и Ruby.NET — это интерпретаторы, написаные на .NET
Здравствуйте, Cyberax, Вы писали:
C>Всякие Iron.Python'ы и Ruby.NET — это интерпретаторы, написаные на .NET
Да ну?
Optionally static — IronPython also supports static compilation of Python code to produce static executables (.exe's) that can be run directly or static libraries (.dll's) that can be called from other CLR languages including C#, VB, managed C++ and many more. Note: static compilation is only partially implemented in the 0.6 public release. This will need further development before being useful.
Our goal is to create a compiler for the Ruby language that targets the .NET CLR. We aim to support 100% of Ruby language semantics, including all dynamic constructs such as closures and continuations. We plan to generate 100% managed and verifiable CIL code.
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, Cyberax, Вы писали:
C>>Всякие Iron.Python'ы и Ruby.NET — это интерпретаторы, написаные на .NET
O>Да ну?
O>
O>Optionally static — IronPython also supports static compilation of Python code to produce static executables (.exe's) that can be run directly or static libraries (.dll's) that can be called from other CLR languages including C#, VB, managed C++ and many more. Note: static compilation is only partially implemented in the 0.6 public release. This will need further development before being useful.
Скорее всего псевдо exe, то есть exe c интерпретатором внутри (для обычного питона такое делает py2exe). Судя по скорости работы точно. Кстати java реализация питона тоже делает class файлы, но интерпретатор внутри остается. Настоящий компилятор питона (нативный) делают тут: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html
Здравствуйте, FR, Вы писали:
FR>Скорее всего псевдо exe, то есть exe c интерпретатором внутри (для обычного питона такое делает py2exe).
Ну а как же тогда
... or static libraries (.dll's) that can be called from other CLR languages including C#, VB, managed C++ and many more.
? Получается, при вызове каждого метода происходит, грубо говоря, интерпретация некой строки?
Кстати, он у тебя стоит (судя по словам "судя по скорости работы точно")? Можно попробовать скомпилить какую-нить сборку, а потом посмотреть Reflector-ом.
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, FR, Вы писали:
FR>>Скорее всего псевдо exe, то есть exe c интерпретатором внутри (для обычного питона такое делает py2exe).
O>Ну а как же тогда
O>
O>... or static libraries (.dll's) that can be called from other CLR languages including C#, VB, managed C++ and many more.
O>? Получается, при вызове каждого метода происходит, грубо говоря, интерпретация некой строки?
А какая в этом проблема?
Реально в нативном питоне каждый раз интерпретации не происходит, выполняется байт код.
O>Кстати, он у тебя стоит (судя по словам "судя по скорости работы точно")? Можно попробовать скомпилить какую-нить сборку, а потом посмотреть Reflector-ом.
Стоит но там вроде ничего кроме интерпретатора нет.
Oyster wrote: > Получается, при вызове каждого метода происходит, грубо говоря, > интерпретация некой строки?
В общем случае — да. В некоторых случаях, когда точно известен тип —
вызов можно заинлайнить.
Сам подумай, в Python'е и Ruby можно к объекту динамически подключать и
удалять методы. Как ты себе это представляешь в CLR без интерпретатора?
> Кстати, он у тебя стоит (судя по словам "судя по скорости работы > точно")? Можно попробовать скомпилить какую-нить сборку, а потом > посмотреть Reflector-ом.
Проще сделать RTFS.
Здравствуйте, Cyberax, Вы писали:
C>Oyster wrote: >> Получается, при вызове каждого метода происходит, грубо говоря, >> интерпретация некой строки? C>В общем случае — да. В некоторых случаях, когда точно известен тип — C>вызов можно заинлайнить.
C>Сам подумай, в Python'е и Ruby можно к объекту динамически подключать и C>удалять методы. Как ты себе это представляешь в CLR без интерпретатора?
Тут http://codespeak.net/pypy/dist/pypy/doc/dynamic-language-translation.html люди пытаются приблизить интерпретаторы к компиляторам, но там и интерпретатор используется и вообще сплошной jit. В IronPython а раних версиях тоже вроде про компилятор говорилось, а что сейчас по документации идущей с ним не понял (никаких упоминаний о компиляции ни нашел), а сайт висит.
У них статический JIT происходит с большими ограничениями, фактически
запрещены все фичи динамических языков — нельзя изменять наборы методов
и типы переменных, например.
А вообще, цель PyPy — сделать динамически оптимизирующий JIT-транслятор.
Нечто типа Java HotSpot, но для динамических языков.
Еще интересен проект Parrot VM — они примерно такое же хотят сделать. У
них своя bytecode VM с поддержкой мультиметодов, множественного
наследования, динамических вызовов и т.п. прямо в самой VM.
Здравствуйте, eao197, Вы писали:
E>Анекдот в тему: E>
E>Экзаменатор и студент.
E>Э: Вы будете отвечать на один сложный вопрос или на три простых?
E>С: На один сложный.
E>Э: Хорошо. Сколько байт в мегабайте?
E>С: Много!
E>Э: Сколько "много"?
E>С: Это уже второй вопрос!
E>)
Смешно. Но твой ответ ровно как в этом анекдоте. Так же точен как и бессмысленнен.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Если же ты о том, что для реализации compile-time вычислений приходиться писать свой код вместо библиотечного, то у меня на этот счет совсем другое мнение -- я думаю, что кодогенерация здесь может быть выгоднее. Зачем при каждой компиляции повторно перевычислять то, что можно вычислить один раз, сохранить в файле и все.
В общем, это уже не смешно. Софистика меня не интересует.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Oyster, Вы писали:
E>>Если же ты о том, что для реализации compile-time вычислений приходиться писать свой код вместо библиотечного, то у меня на этот счет совсем другое мнение -- я думаю, что кодогенерация здесь может быть выгоднее. Зачем при каждой компиляции повторно перевычислять то, что можно вычислить один раз, сохранить в файле и все.
O> Полностью согласен с тобой — давай экономить время на этапе компиляции! Миллисекунды на дороге не валяются!! Про удобство использования такой схемы скромно умолчу...
Странный способ экономить время. Большие прокты на С++ компилирются часами, а у Немерла даже есть интерпретатор работающий в реальном времени.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Про отладку compile-time вычислений, которую можно делать только отладочными печатями, доступными только при запуске компилятора, я тоже не буду распространяться...
Действительно. Зачем позориться и говорить откровенную фигню. Тут ты прав. То ли дело в С++? Нет отладки и нет проблем.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Сам подумай, в Python'е и Ruby можно к объекту динамически подключать и удалять методы. Как ты себе это представляешь в CLR без интерпретатора?
А в чем проблема? Во втором фрэймворке для этого даже отдельный класс сделали — DynamicMethod. Да и мало лич, что можно нахимичить?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Эту химию настклько трудно понять, что я бы бил линейкой по рукам всем тем кто пытается писать код так.
На самом деле, это были исходники этой химии, но их понимать необязательно. Суть в том, что создаются типизированные аналоги простым типам, т.е. типизированные синонимы int, float, double и т.д., соответственно синтаксис использовани аналогичен использованию этих встроенных типов. В прикладном коде будет не за что бить линейкой...
VD>К тому же не трудно придставить диагностику ошибок выдаваемую компилятором. Нормальная система типов в хорошо расширяемом языке не должна требовать каких-то подпорок.
Да, с диагностикой ошибок в этих случаях сложнее... Вернее, сложнее с сообщениями об ошибках. Слава богу, что компилятор VC7.х выдает "свернутые" сообщения, т.е. суть понятна в первой же строчке: "не могу привести один тип к другому".
VD>Например, в Немерле можно делать операторы макросами. При этом во время компиляции доступны любые проверки типов. То есть мы можем контролировать любые аспекты поведения оператора явно, используя те же возможности языка, что и в прикладных программах. По-моему, это намного более простой, понятный и гибкий подход.
Нет, на Немерле ты не сможешь спроектировать подобную систему для произвольной получаемой размерности и их произвольных комбинаций.
VD>Ну, а вот такие примеры — это восхищение тем, что проблема решается хоть как-то хотя совершенно не очевидными средствами.
Она решается очень чудесно на С++, в том плане, что оба, как пользовательский код, так и итоговый бинарник аналогичен использованию встроенных типов. А вся "химия" работает только в compile-time.
VD>Мне вот интересно если Мэерс не описал этот прикол, то сколько бы программистов доперли до него? Боюсь, что еденицы. VD>И еще один вопрос. Склько программистов используют подобные приколы в своем коде?
Более упрощенные варианты используют практически ВСЕ (без комбинаторики, просто различные заменители целевым типам, очень часто такие типы называют с приставкой tagged_).
Т.е. выделение домена — это как бы естественно при проектировании прикладного кода.
Полностью согласен с тобой — давай экономить время на этапе компиляции! Миллисекунды на дороге не валяются!! Про удобство использования такой схемы скромно умолчу...
