DLR, Бу и JVM

Question

Я только начинаю пытаться больше узнать об основах .Net VM, и меня тут же что-то сбрасывает.Я знаю, что есть новая вещь, называемая DLR, которая учитывает все динамические вещи в C # и работу с языками IronX.Но сейчас я читаю об этом языке, называемом Boo, и, очевидно, он имел динамические возможности задолго до появления DLR.Итак,

1) Как это вообще возможно?

2) Что DLR добавляет к уравнению?

3) Будет ли такой язык, как Бу, выиграть что-нибудьпутем повторной реализации себя в терминах DLR?

Из того, что я вроде как собирал здесь и там, похоже, что DLR появился из IronPython, когда они разобрали все, что было необходимо для поддержки DL.в .Net, и поместите его в форму для повторного использования.Так что я предполагаю, что DLR не является чем-то особенным, просто некоторые библиотеки, которые помогают с динамическими объектами в Microsoft.Scripting.dll, но ничего такого, что вы не могли бы просто выйти и написать самостоятельно, если у вас было время, котороеЯ думаю, что случилось с Бу?И затем для 2 и 3, я предполагаю, что общность и возможность повторного использования DLR позволят автоматически выполнять любые будущие улучшения DLR, но что нет срочной «необходимости» повторной реализации с использованием DLR, если вы уже сделали свойсобственное время выполнения?Или у DLR есть какой-то секретный соус MS, который делает его лучше, чем все, что мы могли бы сделать поверх .Net?

4) Действительно ли DLR - это среда выполнения или просто набор библиотек?(В любом случае, что такое время выполнения? Мне, вероятно, нужно узнать больше теории компилятора, прежде чем я смогу понять ответ на этот вопрос, или это вообще вопрос, который что-то значит. Игнорировать этот вопрос. Или нет.)

5) Как работает компиляция IronPython?Компилируется ли она в новую динамическую версию CIL или просто добавляет команду «ironpython.exe» к строке с текстом программы?Хм, хорошо, если динамическое - это ключевое слово в C #, тогда должна быть динамическая версия CIL, верно?Так как же .Net узнает, использовать ли CLR или DLR в CIL?

6) Отличается ли проект DaVinci для JVM?Похоже, что это реальная реализация самой JVM.Каковы последствия этого подхода?Я предполагаю, что есть огромный прирост производительности, но что-нибудь еще?По какой причине MS не пошла по этому пути?

7) Делает ли DLR Boo несколько устаревшим для создания DSL?

Answer 1

DLR в основном приносит 3 вещи на вечеринку:

• Расширенный набор деревьев выражений (впервые представлен с LINQ), которые позволяют компилировать полные программы.Они обеспечивают гораздо более простой способ генерации кода, чем генерация IL-кода напрямую - он избавляет от многих случаев возможности генерировать недопустимый IL-код и превращает многие другие случаи в легко отлаживаемые исключения времени выполнения.
• Встроенное кэширование сайта вызововмеханизм, поэтому вам не нужно создавать свой собственный (очень полезно для хорошей производительности в динамических языках).Это включает в себя такие вещи, как многоуровневый кэш и устаревание неиспользуемых элементов.
• Протокол мета-объектов, который позволяет динамическим языкам общаться друг с другом во время выполнения и согласовывать правильный результат для языка вызова (например, возвращая неопределенныйв JavaScript, когда член не существует или выдает AttributeError в Python независимо от языка, на котором был написан динамический объект).

Протокол мета-объектов - это единственная часть, которой абсолютно необходимо поделиться - все остальное, что вы можете создать самостоятельно.

IronPython полностью строится поверх DLR - так что его модель компиляции на самом деле компилируется в деревья выражений.Внутренний уровень DLR, поставляемый с .NET 4.0, используется для компиляции этих деревьев выражений, и мы используем интерпретатор, являющийся частью внешнего уровня, для интерпретации этих деревьев выражений.Затем мы можем лениво компилировать деревья выражений после того, как интерпретированные версии стали горячими.Эта компиляция включает создание сайтов вызовов, которые мы используем для динамической отправки различных операций (получение, установка членов, вызывающие объекты и т. Д.), И снова мы используем DLR - в данном случае это механизм сайта вызова.IronPython использует комбинацию обоих стандартных связывателей DLR для этих операций вместе с пользовательскими связывателями, которые выполняют специфические действия IronPython (поток через контекст кода, поддерживая вызовы * args и ** args и т. Д.), Которые затем возвращаются к стандартным связывателям DLR дляInterop.

Проект Davinci добавит «дескрипторы методов» в JVM, которые CLR уже имеет в виде делегатов.Это также добавит новый "invokedynamic" код операции, который CLR не имеет и не получил с работой DLR.Вместо этого DLR просто использует существующие примитивы (делегаты, reified generics) плюс библиотеки для определения протокола взаимодействия.Оба добавляют концепцию сайтов вызовов, и они могут быть довольно похожи между ними.

Answer 2

Здесь много вопросов! Я не уверен, что могу ответить на все из них, но я сделаю столько, сколько смогу:

1. Boo не является динамическим в том же смысле, что и (Iron) Python. Это в основном статически типизированный язык со строгим выводом типов и синтаксисом Python. Это, в сочетании с опциональной типизацией утки, дает ощущение динамичности, но, конечно, не то же самое, что Python. Boo больше похож (кроме синтаксиса) на C # 4, чем на Python.

2. DLR добавляет динамическую поддержку для языковых разработчиков поверх CLR, которая больше ориентирована на статически типизированные языки (такие как VB.NET, C #, F #)

3. Не совсем ИМХО. Это стало бы слишком похоже на IronPython. Одна из характеристик Бу состоит в том, что он статически типизирован.

4. Runtime - это библиотеки , которые поддерживают некоторые базовые конструкции в языке. VB.NET, C #, F #, Boo, все они имеют библиотеки времени выполнения. Обычно вы никогда не видите среды выполнения VB.NET или C #, потому что они поставляются с платформой .NET. Эрик Липперт получил от SO отличный ответ на этот вопрос, но я не могу его найти.

5. Не можете это прокомментировать, у вас мало практического опыта работы с IronPython.

6. Не знаю о проекте DaVinci, не могу это прокомментировать.

7. Нет. Насколько я знаю, макросы и расширяемый компилятор Boo довольно уникальны для языка .NET ( Nemerle имеет аналогичные возможности макросов). Я не могу точно сказать, могут ли Boo DSL быть более или менее мощными, чем IronPython DSL. Что я могу сказать наверняка, так это то, что реализация Boo DSLs сильно отличается от внедрения DSL Python.