AndrewVK wrote:

> Учить, разумеется. ИМХО объяснить, что если в начале файла написано
> autogenerated, do not touch, то ни в коем случае этот файл не трогать
> совсем не сложно. В особо запущенных случаях можно для SVN скрипт
> написать, который запретит коммитить генерируемые файлы.
Обычно достаточно их в svn:ignore засунуть.

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

.>Обычно достаточно их в svn:ignore засунуть.

Ну, судя по всему, IT сгенерированные файлы таки в репозиторий запихал.

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

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

Это как?

IT>>Гапертон пока предпочитает молчать, может быть ты мне ответишь на этот вопрос? Чем принципиально отличается плоходокументированный макрос от плоходокументированного метода?

AVK>Тем же, чем отличается незнакомое русское слово в русской речи от речи, скажем, на турецком языке.

Это неверная аналогия. Турецкий — это DSL на XML. А макросы и методы это один и тот же язык.

IT>> Можно перефразировать в текущем контексте. Чем принципиально отличается необходимость разбираться в незнакомом коде, в котором используются незнакомые тебе классы от от кода, в котором используются незнакомые тебе макросы?

AVK>Тем, что возможые эффекты от метода несопоставимы с эффектами от макроса. Т.е. метод делает всегда одно и то же — получает на вход параметры, возможно меняет состояние, и возвращает результат. А вот макрос может делать за кадром что угодно, возможности у него значительно шире (собственно, для этого макросы и придумывали).

Именно. И в этом вся прелесть. Особенно учитывая, что индустрии больше некуда расширяться "шире возможности' — это как раз то, что надо.

AVK>Too big gun и этим все сказано.

Too big gun это только для Хэйлсберга. Ну и его последователей, конечно.

IT>>Интересно, почему тогда народ с таким самозабвением извращается на плюсовых шаблонах?

AVK>Спроси у них. Практически все мои лично знакомые программисты относятся к этому крайне негативно.

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

AVK>Должны же быть какие то причины отсуствия макросов в мейнстриме.

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

IT>>А у моих ума хватило за полгода. Что теперь делать?

AVK>Учить, разумеется.

В 2002-2003-м, когда это происходило ещё сами учителя учились.

AVK>ИМХО объяснить, что если в начале файла написано autogenerated, do not touch, то ни в коем случае этот файл не трогать совсем не сложно.

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

AVK>В особо запущенных случаях можно для SVN скрипт написать, который запретит коммитить генерируемые файлы.

Я даже не помню в каком состоянии тогда был SVN, был ли он тогда вообще в каком-либо состоянии. Мы пользовались VSS и студия сама решала что запрешать, а что нет.

AVK>А я тебе как специалист говорю — в случае применения для кодогенерации LWCG достаточно в параметре skipVisibilityCheck передать true, и можно спокойно обращаться к приватным полям любых классов в любой сборке.

Да ни фига. LCG появилось только в 2.0. Я тебе как специалист говорю.

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

.>>Обычно достаточно их в svn:ignore засунуть.

AVK>Ну, судя по всему, IT сгенерированные файлы таки в репозиторий запихал.

IT ничего никуда не пихал. У IT была студия, которая занималась этим как ей хотелось.

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

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

G>>Также, для прямого оптимизированного перехода между двумя нелинейними пространствами (что надо делать по показаниям) — никто не мешает определить специализированный метод.

AVK>Если преобразования описываются матрицей (а если я не совсем позабыл соотв. раздел прикладной математики, то матрицей можно описать очень широкий класс аналоговых функций)

а если ещё немного поднапрячь память, то матрицей описываются только линейные преобразования

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

IT>IT ничего никуда не пихал. У IT была студия, которая занималась этим как ей хотелось.

А AVK всегда говорил, что студийная поддержка VCS — кака.

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

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

IT>Это как?

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

AVK>>Тем же, чем отличается незнакомое русское слово в русской речи от речи, скажем, на турецком языке.

IT>Это неверная аналогия. Турецкий — это DSL на XML. А макросы и методы это один и тот же язык.

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

IT>Именно. И в этом вся прелесть.

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

IT> Особенно учитывая, что индустрии больше некуда расширяться "шире возможности'

Это ты зря. Возможностей масса. Мозгов не хватает. И в прямом и в переносном смысле.

AVK>>Too big gun и этим все сказано.

IT>Too big gun это только для Хэйлсберга. Ну и его последователей, конечно.

Ну а для последователей N, очевидно, нет. Ты что сказать то хотел?

AVK>>Спроси у них. Практически все мои лично знакомые программисты относятся к этому крайне негативно.

IT>Тут даже по знакомым не нужно ходить. Достаточно глянуть на наш плюсовый форум и посмотреть с какой периодичностью встречаются вопросу по бусту.

А меня оно как то слабо волнует.

AVK>>Должны же быть какие то причины отсуствия макросов в мейнстриме.

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

Паттерн-матчинг в мейнстриме присутствует, но не в шарпе. Лямбды в том же шарпе есть уже давно. Ну а прочие полезные вещи ... Gaperton не зря на PL/1 намекал. Мейнстрим на нем весьма обжегся в свое время. Возможно, сейчас дуют на воду конечно, но тем не менее.

AVK>>Учить, разумеется.

IT>В 2002-2003-м, когда это происходило ещё сами учителя учились.

Ну а теперь?

IT>Это всё слова.

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

AVK>>В особо запущенных случаях можно для SVN скрипт написать, который запретит коммитить генерируемые файлы.

IT>Я даже не помню в каком состоянии тогда был SVN, был ли он тогда вообще в каком-либо состоянии.

Скрипты, помнится, и в CVS были.

IT> Мы пользовались VSS и студия сама решала что запрешать, а что нет.

Ну а теперь?

IT>Да ни фига. LCG появилось только в 2.0. Я тебе как специалист говорю.

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

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

IT>>IT ничего никуда не пихал. У IT была студия, которая занималась этим как ей хотелось.

AVK>А AVK всегда говорил, что студийная поддержка VCS — кака.

Какую MS туда воткнул, такая и была. Бывает ещё хуже. Например, p4.

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

AVK>Это так. У меня нет никакого желания что то тебе доказывать. Если тебе интересно мое мнение — я могу его пояснить, если интересно поспорить — я в этом участвовать не хочу. А то вон ваши молодые орлы уже подтянулись, только и ждут.

Мнение всегда интересно. А выводы скорее нет, чем да.

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

Ну и что? В том же шарпе 99% девелоперов не знают всех возможностей языка. Например, многие понятия не имеют что такое '??'. Так что мне теперь не использовать эти возможности? Так мы договоримся до того, что нам нужно сузить использования языка до рамок, ограниченных ограниченностью большинства девелоперов. Как ты правильно сказал, учить надо. И всё. Обучить вменяемого человека 10-ти макросам — это вообще не проблема.

AVK>Ага. И в этом, как обычно, еще и главная пакость. И кодогенерацией, и макросами я увлекался намного раньше, чем вы начали махать флагом с буквой N.

Интересно какими же ты макросами увлекался намного раньше?

AVK>Только вот на моих задачах я вдоволь наелся и побочных эффектов. И эти эффекты совсем не в том, что кто то где то автогенеренный код поправил.

А в чём?

IT>> Особенно учитывая, что индустрии больше некуда расширяться "шире возможности'

AVK>Это ты зря. Возможностей масса. Мозгов не хватает. И в прямом и в переносном смысле.

Мозгов не хватает, а те что есть занимаются в основном размазыванием императивного кода тонким слоем по приложению. Не лучше ли одному человеку выделить несколько наиболее используемых паттернов, разработать под них макросы и дать их в руки размазывателям. И кода станет меньше и его качество заметно возрастёт.

IT>>Too big gun это только для Хэйлсберга. Ну и его последователей, конечно.

AVK>Ну а для последователей N, очевидно, нет. Ты что сказать то хотел?

То, что он это может быть брякнул не сильно подумав и сразу забыл, а кое-кому потом стыдно будет признаться, что он потом эту чушь за ним так часто повторял.

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

AVK>Паттерн-матчинг в мейнстриме присутствует, но не в шарпе.

А где?

AVK>Лямбды в том же шарпе есть уже давно.

Лямб пока нет. Есть убожество, называемое анонимными делегатами. Но хотя бы это. Да и оно не сразу появилось. Но вот что радует, так это то, что всё таки появилось. Есть надежда, что может тому же Хейлсбергу придёт в голову ещё какая-нибудь идея вроде линка и в качестве побочного эффекта мы получим в языке паттерн-матчинг или те же макросы.

AVK>Ну а прочие полезные вещи ... Gaperton не зря на PL/1 намекал. Мейнстрим на нем весьма обжегся в свое время. Возможно, сейчас дуют на воду конечно, но тем не менее.

Думаю, ни тебе, ни Гапертону на PL/1 писать не приходилось. А мне немного довелось. PL/1 был редкостным говном сам по себе. Например, в нём, чтобы объявить рекурсивный метод нужно было слегка пошаманить. Бред, блин. Это в то время, когда уже во всю свирепствовал C, да и C++ с Паскалем были не самыми распоследними языками. Я как раз тогда, сравнивая PL/1 с Паскалем и C, долго удивлялся по поводу рекурсий и не мог понять в чём прикол, что тут такого сложного. PL/1 кроме кучи фич впитал в себя ещё и всю языковую дремучесть предков. Такое ощущение, что его делали не смотря в будущее, а постоянно оглядываясь, пока в конце концов у создателей не заклинило башку в положении 180 градусов глядя назад.

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

IT>>В 2002-2003-м, когда это происходило ещё сами учителя учились.
AVK>Ну а теперь?

А теперь учителя предали pre-compile time генерацию анафеме и живут в счастье со своими учениками и учениками учеников с run-time кодогенерацией, мечтая при этом о compile-time кодогенерации.

IT>> Мы пользовались VSS и студия сама решала что запрешать, а что нет.
AVK>Ну а теперь?

А теперь я пользуюсь хренью, которая на порядок хуже VSS. Называется перфорс.

IT>>Да ни фига. LCG появилось только в 2.0. Я тебе как специалист говорю.
AVK>Ну так появилось же. Какое мне дело до того что было раньше, если здесь отнюдь не ретроспектива обсуждается?

Такое ощущение, что ты никогда не поддерживал кода, который может быть скомпилирован только одной версией единственного компилятора.

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

IT>Теперь у кого-то точно также заклинивает башку и он в упор не видит преимуществ расширяемых компиляторов.

Можно поподробней о преимуществах расширяемых парсеров?

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

IT>>Теперь у кого-то точно также заклинивает башку и он в упор не видит преимуществ расширяемых компиляторов.

M>Можно поподробней о преимуществах расширяемых парсеров?

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

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

IT>Не совсем понял вопрос. Я не говорил о парсерах. Речь о расширяемых компиляторах. В частности, Немерле умеет в процессе парсинга расширять лишь список ключевых слов. И то, это скорее вопрос имплементации, чем идеологии. Расширение компилятора подразумевает не только и не столько парсинг, а скорее взаимодействие с компилятором во время всевозможных изврашений с AST.

Да, виноват, почему-то прочитал слово "парсер", хотя там было написано "компилятор".
Осталось только уточнить — речь идёт именно о компиляторах? Если да — то почему вы остановились именно на них, а не продолжили эту же идею на остальные инструменты разработки и исполнения программ?
Если у нас будет только компилятор расширяемый — то прости-прощай IDE, который превратится из ненешнего продвинутого инструмента в обычный редактор. А если мы включаем IDE в понятие "компилятор", то достаточно быстро приходим к тому, что расширения языка должны комплексно описывать изменения — и то, как его компилировать (извращаться с AST), и то, как его должен понимать IDE.
Далее, понятие компилятора в последнее время размывается, поскольку между исходным кодом и скомпилированными инструкциями CPU всё больше встаёт тень виртуальной машины, с её JIT компилятором или компиляцией при установке на конкретное железо, ОС и т.д. В сторону расширения VM вы как смотрите? Было-бы логично (по крайней мере — последовательно) иметь расширяемую VM, и по видимому, расширения VM могут описываться так-же, как и расширения компилятора (поскольку VM — это рантайм + компиляция из инструкций псевдо-процессора в инструкции hardware процессора). Там на горизонте виднеется ещё и расширяемость железа, но пока не будем трогать.

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

PS Вопрос про расширяемые парсеры предполагал, что сам по себе парсер — это не очень-то большая часть компилятора (языка программирования), и его расширяемость не даёт больших бонусов, зато даёт ощутимые потери (вроде той-же проблемы с IDE). Расширяемость компилятора — даёт намного больше плюсов, но суть проблемы не меняется.

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

IT>Мнение всегда интересно. А выводы скорее нет, чем да.

Мнение это и есть выводы.

IT>Ну и что?

Чем более базовый уровень подвергается изменениям, тем сложнее вхождение.

IT> В том же шарпе 99% девелоперов не знают всех возможностей языка. Например, многие понятия не имеют что такое '??'. Так что мне теперь не использовать эти возможности?

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

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

Суживать ничего не надо. Надо чтобы рамки были и менялись эти рамки крайне редко. Тогда есть шанс массового соответствия этим рамкам.

IT> Как ты правильно сказал, учить надо. И всё. Обучить вменяемого человека 10-ти макросам — это вообще не проблема.

А 20? А 100?

IT>Интересно какими же ты макросами увлекался намного раньше?

Да были всякие разные типа Open C++. Но, как я предполагал, разговор скатывается во флейм.

AVK>>Только вот на моих задачах я вдоволь наелся и побочных эффектов. И эти эффекты совсем не в том, что кто то где то автогенеренный код поправил.

IT>А в чём?

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

IT>Мозгов не хватает, а те что есть занимаются в основном размазыванием императивного кода тонким слоем по приложению. Не лучше ли одному человеку выделить несколько наиболее используемых паттернов, разработать под них макросы и дать их в руки размазывателям.

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

IT>>>Too big gun это только для Хэйлсберга. Ну и его последователей, конечно.

AVK>>Ну а для последователей N, очевидно, нет. Ты что сказать то хотел?

IT>То, что он это может быть брякнул не сильно подумав и сразу забыл, а кое-кому потом стыдно будет признаться, что он потом эту чушь за ним так часто повторял.

Ну понеслась. IT, мне не интересно доказывать свою правоту тебе. Пускай ты будешь прав. Если хочешь, я закончу сюда писать, только не надо переходит на банальную перепалку.

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

AVK>>Паттерн-матчинг в мейнстриме присутствует, но не в шарпе.

IT>А где?

SQL например. Или XSLT.

AVK>>Лямбды в том же шарпе есть уже давно.

IT>Лямб пока нет. Есть убожество, называемое анонимными делегатами.

Во первых анонимными МЕТОДАМИ. Во-вторых это те же лямбды, вид в профиль. В-третьих, оставь подобные флеймогонные эпитеты.

IT>Думаю, ни тебе, ни Гапертону на PL/1 писать не приходилось.

Не угадал. Приходилось, хотя и в небольших объемах.

IT>Теперь у кого-то точно также заклинивает башку и он в упор не видит преимуществ расширяемых компиляторов.

Я вот думаю, это Nemerle делает вас столь непримиримыми, или функциональное программирование вообще?

IT>Такое ощущение, что ты никогда не поддерживал кода

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

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

IT>А теперь я пользуюсь хренью, которая на порядок хуже VSS. Называется перфорс.

А чем он не угодил? По мне так на порядок лучше VSS'а.

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

M>Осталось только уточнить — речь идёт именно о компиляторах? Если да — то почему вы остановились именно на них, а не продолжили эту же идею на остальные инструменты разработки и исполнения программ?

Потому что речь идёт именно о языковых средствах. Если интересно пообсуждать IDE или VM, то это тоже можно сделать, но этот топик не об этом.

M>Если у нас будет только компилятор расширяемый — то прости-прощай IDE, который превратится из ненешнего продвинутого инструмента в обычный редактор. А если мы включаем IDE в понятие "компилятор", то достаточно быстро приходим к тому, что расширения языка должны комплексно описывать изменения — и то, как его компилировать (извращаться с AST), и то, как его должен понимать IDE.

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

M>Далее, понятие компилятора в последнее время размывается, поскольку между исходным кодом и скомпилированными инструкциями CPU всё больше встаёт тень виртуальной машины, с её JIT компилятором или компиляцией при установке на конкретное железо, ОС и т.д. В сторону расширения VM вы как смотрите? Было-бы логично (по крайней мере — последовательно) иметь расширяемую VM, и по видимому, расширения VM могут описываться так-же, как и расширения компилятора (поскольку VM — это рантайм + компиляция из инструкций псевдо-процессора в инструкции hardware процессора). Там на горизонте виднеется ещё и расширяемость железа, но пока не будем трогать.

Если я понимаю как можно сделать расширение компилятора, то как сделать расширяумую VM я без понятия. Если есть идеи, то можно обсудить.

M>Так как вы считаете — расширять только компилятор, или весь набор средств разработки и исполнения программ?

Пока мы говорим только о компиляторе.

M>PS Вопрос про расширяемые парсеры предполагал, что сам по себе парсер — это не очень-то большая часть компилятора (языка программирования), и его расширяемость не даёт больших бонусов, зато даёт ощутимые потери (вроде той-же проблемы с IDE). Расширяемость компилятора — даёт намного больше плюсов, но суть проблемы не меняется.

Это неверное утверждение. Как я уже сказал, интеграция Немерле со студией автоматически подхватывает все расширения. Есть определённые технические проблемы, которые решаемы, но принципиальных проблем нет.

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

IT>>А теперь я пользуюсь хренью, которая на порядок хуже VSS. Называется перфорс.

EC>А чем он не угодил? По мне так на порядок лучше VSS'а.

Глючным плагином к студии.

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

IT>>>А теперь я пользуюсь хренью, которая на порядок хуже VSS. Называется перфорс.

EC>>А чем он не угодил? По мне так на порядок лучше VSS'а.

IT>Глючным плагином к студии.

Вот ведь, из-за какого-то там плагина обгадить приличную вещь.

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

IT>Потому что речь идёт именно о языковых средствах. Если интересно пообсуждать IDE или VM, то это тоже можно сделать, но этот топик не об этом.

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

IDE и VM были упомянуты не для перевода стрелок и отвлечения внимания. Они имеют непосредственное отношение к макросам, о чём я и написал достаточно подробно. Если вы этого не видите и не хотите видеть — так бы и сказали, мол обсуждать не хочу.

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

Конечно это невозможно. Или мы о разных IDE.
Скажем, у нас есть "расшитрение" для enum типов, и их использования в выражениях и switch/case. Для case value мы бы хотели в IDE иметь автодополнение, которое предлагало бы список перечислымых значений из декларации enum.
Так вот, никаким образом этот тип автодополнения не появится автоматически из правил преобразования enum->class на уровне AST.
IDE уровня Eclipse или IntelliJ Idea понимает код, работает с ним на уровне семантики. Поэтому и является настолько удобным инструментом. А вы под IDE подразумеваете редактор+обработчик сообщений компилятора?

IT>Если я понимаю как можно сделать расширение компилятора, то как сделать расширяумую VM я без понятия. Если есть идеи, то можно обсудить.

Так я же написал — VM это рантайм плюс компилятор.
Собственно говоря, после того как исходный код разобран (parsed & resolved), проверен на отсутствие ошибок — дальнейшая работа компилятора полностью автоматизирована (и представляет собой трансформацию дерева/графа), и может быть спокойно перемещена из source-to-bytecode компилятора в bytecode-to-native компилятор. Конечно, это самый первый уровень расширяемости VM, но у вас уже есть повод поразмышлять, если интересно.

IT>Это неверное утверждение. Как я уже сказал, интеграция Немерле со студией автоматически подхватывает все расширения. Есть определённые технические проблемы, которые решаемы, но принципиальных проблем нет.

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

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

IT>>Глючным плагином к студии.
E>Вот ведь, из-за какого-то там плагина обгадить приличную вещь.

Более пакостной поделки я не видел. При этом приличная или не приличная вещь сам перфорс меня уже не интересует. Плагин, кстати, той же конторы

И ещё, кстати. Смешно читать рекомендации разработчиков перфорса по эмуляции shared folders VSS. Типа, мы это не будем делать, т.к. считаем принципиально неправильным использовать shared folders, но если вам надо, то делайте так и так. Почему просто не сказать, мы это не будем делать, т.к. наша архитектура не рассчитана на такую фичу, но если вам надо, то делайте так и так

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

IT>>Потому что речь идёт именно о языковых средствах. Если интересно пообсуждать IDE или VM, то это тоже можно сделать, но этот топик не об этом.

M>Кодогенераторы тоже не являются языковыми средствами, но они тут активно обсуждаются, поскольку имеют много общего с макросами.

Именно поэтому и абсуждаются. Это ближайшая альтернатива и относится к тому же классу задач — метапрограммированию.

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

VM без разницы на каком языке был сгенертрован байт-код и с помощью каких расширений. Это как бы одна из основополагающих идей.

M>IDE и VM были упомянуты не для перевода стрелок и отвлечения внимания. Они имеют непосредственное отношение к макросам, о чём я и написал достаточно подробно. Если вы этого не видите и не хотите видеть — так бы и сказали, мол обсуждать не хочу.

Давай обсуждать, если очень хочется. Why not?
По-моему мнению VM не имеет никакого отношения к расширению компилятора. Т.е. вообще никакого. Продукт компиляции — это байт-код. Как он был получен это не важно. Я генертрую байт код вручную с помошью emit'а без всякой компиляции. Тем не менее VM на меня за это вовсе не в обиде.
Об IDE ниже.

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

M>Конечно это невозможно. Или мы о разных IDE.



M>Скажем, у нас есть "расшитрение" для enum типов, и их использования в выражениях и switch/case. Для case value мы бы хотели в IDE иметь автодополнение, которое предлагало бы список перечислымых значений из декларации enum.

Что такое "расширение" для enum типов? Это новый тип типов или новый enum?

M>Так вот, никаким образом этот тип автодополнения не появится автоматически из правил преобразования enum->class на уровне AST.
M>IDE уровня Eclipse или IntelliJ Idea понимает код, работает с ним на уровне семантики. Поэтому и является настолько удобным инструментом. А вы под IDE подразумеваете редактор+обработчик сообщений компилятора?

Я понимаю это как редактор + компилятор. Не секрет, что тот же Resharper включает в себя большую часть самописного компилятора C#. Фактически для IDE не нужна лишь последняя фаза кодогенерации. Остальное в ней присутствует в полный рост. Не думаю, что Idea и Eclipse в этом сильно отличаются. Что касается Немерле, то его интеграция с VS использует непосредственно сам компилятор. Соотвественно, если макрос, например, сгенертровал новый тип или метод в существующем типе, то он автоматически появится в списке интелисенс. Тоже самое касается новых ключевых слов.

IT>>Если я понимаю как можно сделать расширение компилятора, то как сделать расширяумую VM я без понятия. Если есть идеи, то можно обсудить.

M>Так я же написал — VM это рантайм плюс компилятор.

VM и компилятор напрямую никак не связаны.

M>Собственно говоря, после того как исходный код разобран (parsed & resolved), проверен на отсутствие ошибок — дальнейшая работа компилятора полностью автоматизирована (и представляет собой трансформацию дерева/графа), и может быть спокойно перемещена из source-to-bytecode компилятора в bytecode-to-native компилятор. Конечно, это самый первый уровень расширяемости VM, но у вас уже есть повод поразмышлять, если интересно.

Пофантазировать можно конечно. MS research работает над проектом Феникс, возможно это из этой серии.

IT>>Это неверное утверждение. Как я уже сказал, интеграция Немерле со студией автоматически подхватывает все расширения. Есть определённые технические проблемы, которые решаемы, но принципиальных проблем нет.

M>Расскажите мне о решении принципиальной проблемы изложенной выше. Как будет происходить пониание кода средой разработки на основании одних только правил преобразования AST, не говоря уже о расширениях вроде изменения системы типов.

Интеграция с VS использует сам компилятор. Т.е. исходный код проекта банально пропускается через компилятор и в результате IDE получает в своё распоряжение AST. В процессе компиляции выполняются в том числе и макросы. Соответственно, все сделанные ими изменения попадают в результирующее AST.