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

>> Давай лучше футбольных хулиганов запретим. Хоть аналогия будет по прямее.
>> МН — это багодром. Далее см. выделенное жирным выше.
C>Ага, а GC — это костыль для тех, кто не умеет с памятью работать

Ты сам с собой что ли разговр ведешь?
Причем тут костыли, ЖЦ?

C>Я изначально говорил про большие языковые возможности ParrotVM. MH — это
C>одна из таких возможностей, которых нет в CLI.

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

На сегодня есть ряд решений заменяющих МН и они вводятся в язык без именения виртуальной машины. Так что встраивание МН в ВМ не очень разумное решение.

Кстати, Эфил и С++ таки поддерживают МН не смотря на его отсуствие в ВМ дотнета.

C>Прекрасно знаю, еще со времен Java — просто переменные кладутся не в
C>стек а в поля служебного объекта.

И зачем тогда поддержка в рантайме? Ты не понимашь того что чем проще рантайм, тем проще его перенос?

Лучше потратить время на оптимизации устраняющие котокоживущие локальные объекты заменя их где можно стэковыми переменными.

C>А вот где continuation'ы? Настоящие, а не в виде сгенерированых конечных
C>автоматов?

continuation-ы — это алгоритмические сущьности. Их можно реализоывать разными путями. В том числе и на конечных автоаматах. Так что прежде чем продолжать обсуждение "настоящих" continuation-ов потрудись объяснить чем плохи решения на базе переписывания кода с использованием те хе КА.

>> Продолжения вообще алгоритмическая сущьность. Что тут будет поддерживать
>> VM? Сохранение полного своего состояния что ли?
C>"Легкие" потоки, например.

Легкие потоки уже есть в чистом виде. Эмулировать их на базе continuation-ов смысла нет.

C> Чтобы можно было нормально представлять
C>веб-навигацию, например (см. http://www.seaside.st).

Это можно сделть даже на базе итераторов, которые являются одним из вариантов реализации continuation-ов (хотя и ограниченым). Вот, напиример, очень похожая задача решенная с использованием итераторов Михаликом http://blogs.gotdotnet.ru/personal/mihailik/PermaLink.aspx?guid=cb5f993a-2371-4365-80cf-0605461a49c4

C>Ну и такую деталь, что методы являются частным случаем мультиметодов я
C>уж вообще говорить не буду.

Спорный вопрос. Эдак и глобальные функции можно считать частным случаем методов.

Мултиметоды могжно реализовать в языках вообще к ООП отношения не имеющим. Так что это именно алгоритмическая фича. К тому же заменяемая другими решениями.

>> Те же мультиметоды не ясно как связывать с вновь загруженными типами.
C>В ParrotVM — совершенно ясно, так как код динамический.

Дык а смысл тогда что-то было делать?

C> В .NET —
C>действительно ничего нормального не получится (о чем я говорил уже раза
C>три).

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

>> C>Нет их.
>> Да? Ну, ты, былин, эксперт. Жаль что ты мне раньше не сказал. А то я уже
>> 4 года их использую.
C>Еще раз говорю — это _рефлексивные_ вызовы, а не динамические.

Сеньезно? И делегаты? Ну, ты действительно эксперт. К тому же поведуй мне разницу между "рефлективными" и "динамическими" вызовами.

C> Динамику
C>можно эмулировать с помощью словарей делегатов и рефлексии, но в CLI ее нет.

Кого "её"?

C>Опять же _тебе_ они нафиг не упали, а вот мне они очень даже нужны.

Воспользуешся классом, если что. В нормальном языке разнины ты не заметишь.

>> Если что их не трудо
>> будет оформить в виде класса. Если конечно компилятор полноценный.
C>Оформите quadchar (32-битный символ) в виде класса на C#, пожалуйста.

Зачем? Проще и разумнее строку. Только опять же смысла нет. С поддержкой юникода и так все ОК.

C>Чтобы с ним работать было не хуже чем с обычным char'ом, JIT его понимал
C>и использовал оптимизации типа SSE2/AltiVec и т.п.

Оптимизации — это проблемы джита. А символы всегда хоаняться в базовых типах. char в дотнете это просто UInt16. Нет проблем использовать вместо него хоть UInt64. Бросто как всегда на фиг не упало. Для возни с юникодом есть соотвествющий API.

>> C>Не надо говорить слова "поддержка ООП", пожалуйста. Это абсолютно
>> C>бессмысленная фраза.
>> Дык, не говори. Это же твои слова.
C>Где я это сказал? Вроде я ничего такого в последнее время не пил...

Ну, ты эта... следи за тем, что говоришь. А говорил ты это выше по теме. Ты же начал обсуждение поддржки ООП ВМ-мами.

>> C>Ну да, а все С-программы тоже совместимы. Я ведь могу экспортировать и
>> C>импортировать Сшные функции!
>> Попробуй импортировать в Borland C++ 3.1 функцию из библиотеки созданной
>> GCC, к примеру.
C>В BC3.1 не получится. А вот в Watcom — элементарно.

Неполучится? А что так? А вот между Моно и Дотнетам полная бинарная совместимось. Забавно правда?

Выходит, что у С++ хреново даже в совместимости между собственными компиляторам. О чем тогда говорить на междязыковом и межплатформном уровне?