Re[8]: C# 7 - названия и прочее
От: Ziaw Россия  
Дата: 12.05.15 03:04
Оценка:
Здравствуйте, VladD2, Вы писали:

Z>>Темпы развития радуют

VD>Издеваешься?

Да не сильно. Видя, какую бурную негативную реакцию провоцирует каждое нововведение (восторги тоже бурные, но я сейчас про батхерт), становится понятно, что быстрее не получится.
Re[9]: C# 7 - названия и прочее
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.05.15 03:11
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Да не сильно. Видя, какую бурную негативную реакцию провоцирует каждое нововведение (восторги тоже бурные, но я сейчас про батхерт), становится понятно, что быстрее не получится.


С их то баблом? Они зарядили бы 100500 евангелистов, которые бы за пол года убедили бы всех промайкросовтовских программистов, что МС совершил революцию в программировании...
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: C# 7 - названия и прочее
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.05.15 03:33
Оценка: 36 (1)
Здравствуйте, Sinix, Вы писали:

S>Для aop — это безусловно так. Для макросов, которые расширяют синтаксис и/или требуют реврайта вызывающего кода — чойто я сомневаюсь.


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

АОП не более чем разновидность МП. Разновидность куцая и мало полезная. Даже ты подразумеваешь под АОП нечто вроде МП без синтаксических расширений. Но это тоже макросы. Просто урезанная версия. В Скалу сейчас встраиваются именно такие макросы. Причем там используется типизированный подход (когда компилятор сначала типизирует код, а потом уже позволяет макросам сгенерировать вместо него другой код.

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

Дело в том что 100% МП — это в том или ином роде создание ДСЛ-ей. Ограничивая язык фиксированным синтаксисом мы вынуждаем авторов реинтерпретировать синтаксис. Это ни разу не делает получаемые ДСЛ более понятными. Наоборот, это делает код сложнее и отвращает людей от использования языка.

ЗЫ

Похоже Ziaw прав. Причем как в том, что Шарп неминуемо, но очень медленно дрейфует в сторону Немерла. Так и в том, что медленность этого процесса обусловлена медленностью эволюции сознания пользователей языка. Я только добавлю, что дело не только в пользователях, но и авторах. Эволюция их сознания так же тормозит процесс. Если бы они прошли этот путь быстрее, то проблему эволюции сознания пользователей можно было бы решить за счет пиара и евангелистов.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: C# 7 - названия и прочее
От: Sinix  
Дата: 12.05.15 06:55
Оценка:
Здравствуйте, VladD2, Вы писали:

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


У нас там недоразумение мелкое получилось.
Ziaw говорил про "в шарп добавляют фишки, которые 100 лет как в N", я — про "в шарпе не будет части фишек N из-за заточенности на мейнстрим и из-за того, что поздняк метаться". Разные вещи короче обсуждали


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


Опыт был, приходилось наблюдать проект с использованием самописных DSL и чего-то типа макросов на комментариях в коде. Про то, как эти "макросы" прикручены были не будем — там страх и боль Но нас сейчас не это интересует, один фиг с точки зрения пользователей разницы никакой.

Так вот, с DSL всё было оччень зашибись — поддерживалось, записывалось и читалось понятнее, чем в коде, тут полностью за. С "макросами" было столько проблем, что день когда их наконец выпилили был праздником у всей команды.

Проблемы были не технического характера, тем более что ошибиться с чем-то типа
/*@DTO@*/
class A { public int B { get; set; } } // INotifyPropertyChanged + IEquatable + ещё какие-то свои интерфейсы

или с
void Do(string b, SomeType b)
{
  /*@ValidateArgs@*/

  // real code
}

было сложно. Засада была в другом:

1. Ошибка была в том, что "макросы" добавлялись по всему проекту целиком. Если кто-то добавлял макрос для своей локальной задачи — он рано или поздно использовался не по назначения кам-то ещё, при изменении макроса всё сыпалось. И хорошо ещё, если при компиляции.

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

там были ещё проблемы, но по сравнению с первыми двумя они были совсем мелочью.



VD>Ну, и твои подозрения, что расширения синтаксиса это что-то сложное, страшное и опасное ничем не отличаются от подозрений оп поводу того, что "var" сделает код программ нечитабельным.

Чтоб не спорить впустую — можешь привести реальный полезный пример расширения синтаксиса?
Потому что для AOP я с ходу десяток примеров приведу, для расширения синтаксиса — только мелочёвка типа счётчика в foreach или foreach ... else. Ну несерьёзно это


VD>Дело в том что 100% МП — это в том или ином роде создание ДСЛ-ей. Ограничивая язык фиксированным синтаксисом мы вынуждаем авторов реинтерпретировать синтаксис. Это ни разу не делает получаемые ДСЛ более понятными. Наоборот, это делает код сложнее и отвращает людей от использования языка.

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



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

"У любой сложной проблемы всегда есть простое неправильное объяснение"

Другой планеты у нас нет, поэтому или делаем то, что действительно полезно для _большинства_ пользователей, или фейлимся, или получаем очень классный, но очень узкоспециализированный язык. Других вариантов я что-то не видел
Re[13]: C# 7 - названия и прочее
От: agat50  
Дата: 12.05.15 07:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>ЗЫ


VD>Похоже Ziaw прав. Причем как в том, что Шарп неминуемо, но очень медленно дрейфует в сторону Немерла. Так и в том, что медленность этого процесса обусловлена медленностью эволюции сознания пользователей языка. Я только добавлю, что дело не только в пользователях, но и авторах. Эволюция их сознания так же тормозит процесс. Если бы они прошли этот путь быстрее, то проблему эволюции сознания пользователей можно было бы решить за счет пиара и евангелистов.


А я вот согласен. Вспоминая недавние терки на roslyn codeplex по поводу string interpolation — они явно не читали http://rsdn.ru/article/nemerle/NemerleStingFormating.xml
Автор(ы): Владислав Чистяков
Дата: 09.12.2006
В статье на базе практических примеров разбирается что такое макросы Nemerle, что они могут и как их создавать.
. И следовательно даже не ждут таких фич — иначе string interpolation от компилятора даже не стали бы обсуждать.
Re[14]: C# 7 - названия и прочее
От: Sinix  
Дата: 12.05.15 07:53
Оценка:
Здравствуйте, agat50, Вы писали:


A>А я вот согласен. Вспоминая недавние терки на roslyn codeplex по поводу string interpolation — они явно не читали http://rsdn.ru/article/nemerle/NemerleStingFormating.xml
Автор(ы): Владислав Чистяков
Дата: 09.12.2006
В статье на базе практических примеров разбирается что такое макросы Nemerle, что они могут и как их создавать.
. И следовательно даже не ждут таких фич — иначе string interpolation от компилятора даже не стали бы обсуждать.


В отличие от любого мелкого проекта, в мейнстриме работает закон больших чисел вместе с законом Мёрфи. Т.е. вместо "чотам думать, очевидно же" неплохо бы предусмотреть правильный синтаксис, расширяемость и поддержку кучи сценариев использования от оптимизаций для простых случаев и вплоть до локализации строк . Ну, или пару десятков лет поддерживать код напичканный последствиями ваших неправильных решений. Других вариантов (эмиграцию к эльфам и розовым пони не предлагать) увы нет.

Ну а как всю эту радость реализовать — это уже дело десятое, если не сотое. Тем более что с точки зрения разработчиков шарпа тут нет никакой разницы есть макросы/нет макросов. Они и так имеют полный доступ ко всем этапам обработки AST.
Re[15]: C# 7 - названия и прочее
От: agat50  
Дата: 12.05.15 08:09
Оценка:
Здравствуйте, Sinix, Вы писали:

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



A>>А я вот согласен. Вспоминая недавние терки на roslyn codeplex по поводу string interpolation — они явно не читали http://rsdn.ru/article/nemerle/NemerleStingFormating.xml
Автор(ы): Владислав Чистяков
Дата: 09.12.2006
В статье на базе практических примеров разбирается что такое макросы Nemerle, что они могут и как их создавать.
. И следовательно даже не ждут таких фич — иначе string interpolation от компилятора даже не стали бы обсуждать.


S>В отличие от любого мелкого проекта, в мейнстриме работает закон больших чисел вместе с законом Мёрфи. Т.е. вместо "чотам думать, очевидно же" неплохо бы предусмотреть правильный синтаксис, расширяемость и поддержку кучи сценариев использования от оптимизаций для простых случаев и вплоть до локализации строк . Ну, или пару десятков лет поддерживать код напичканный последствиями ваших неправильных решений. Других вариантов (эмиграцию к эльфам и розовым пони не предлагать) увы нет.


S>Ну а как всю эту радость реализовать — это уже дело десятое, если не сотое. Тем более что с точки зрения разработчиков шарпа тут нет никакой разницы есть макросы/нет макросов. Они и так имеют полный доступ ко всем этапам обработки AST.


1) Я не увидел чтобы над той же локализацией кто-то там особо думал. Они о регулярных выражениях с \{} вещами вспомнили на середине. 2) Имея на подходе рослин (вот уже прям скоро), не видел там ни одного предложения подождать его сделать на макросах\AST чего угодно. Очень странно учитывая как они его позиционируют. Имхо они именно не знают про альтернативы, что грустно.
Re[3]: C# 7 - названия и прочее
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.05.15 09:15
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Как я понимаю они ввели ключевое слово record для классов с первичным (primary) конструктором. У таких классов есть одна незаметное, на первый взгляд, особенность. Этот самый первичный конструктор проводит соответствие между параметрами этого самого конструктора и полями/свойствами класса.


В текущем состоянии — не проводит, акцессоры свойств все равно нужно руками расписывать. Потому и убрали из 6 шарпа, вот как раз чтобы сущности не плодить.
А record — это из отдельной, независимой спеки, которую писали другие люди. Там как раз такое соответствие имеется, чтобы автоматично реализовывать оператор is. И именно по результатам изучения спеки ПК запостпонили.
Суть того что нужно сделать — объединить эти две вещи в единой спецификации. Пока такого публично я не видел, так что и говорить о какой либо терминологии и синтаксисе слишком рано.

S>>Причём как я понял из очень обтекаемых комментариев, на CLR team надежды на этот и следующий релизы нет от слова совсем. То ли ресурсов у них нет, то ли совместимость превыше всего.

VD>Эти уроды уже своими отмазками достали. Что они там вообще делают?

Мелочь одну — переписали с нуля JIT.

VD>Ну, и до кучи надо ввести замену этому убогому delegate — функциональный тип.


Это, очевидно, практически невозможно из-за совместимости.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[16]: C# 7 - названия и прочее
От: Sinix  
Дата: 12.05.15 09:21
Оценка: :)
Здравствуйте, agat50, Вы писали:



A>1) Я не увидел чтобы над той же локализацией кто-то там особо думал.

Тем не менее, оно там есть, пусть и в виде набора "сделай сам". Делаешь свой метод вида
FromResource(FormattableString formattable)
{
  ...
}

и наслаждаешься жизнью.


A> 2) Имея на подходе рослин (вот уже прям скоро), не видел там ни одного предложения подождать его сделать на макросах\AST чего угодно. Очень странно учитывая как они его позиционируют. Имхо они именно не знают про альтернативы, что грустно.


Ну блин, это только в сказках можно сказать ХАЧУ и в шарпе тут же появятся макросы. Изначально на этот релиз планы были только перетащить шарп и студию на рослин, без крупных добавлений. Это потом уже сроки поехали и появилось время на всякую мелочёвку.

А до метапрограммирования ещё копать и копать. Для начала неплохо бы определиться, какие именно макросы нужны. Будет ли достаточно простого AOP на атрибутах или клиенты хотят полноценный язык с dsl и гейшами.
Если первое — повезло, если последнее — приплыли, нужен подопытный кролик экспериментальный диалект наподобие Cω.

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

Про интеграцию с другими языками (дотнет шарпом вообще-то не заканчивается), работу с c# script/REPL (его активно пилят, к следующему релизу будет) и традиционно отстающий edit'n'continue я вообще молчу.


Короче, по затратам это штука где-то между await и linq будет. А вот насчёт выхлопа я не уверен. Мы встроили тебе язык в язык, чтобы ты мог программировать пока ты программируешь, ага.
Re[10]: C# 7 - названия и прочее
От: hardcase Пират http://nemerle.org
Дата: 12.05.15 11:08
Оценка: 18 (1)
Здравствуйте, Sinix, Вы писали:

S>Чтоб не спорить впустую — можешь привести реальный полезный пример расширения синтаксиса?


LINQ по сути — расширение синтаксиса. Анонимные типы в Nemerle воспроизведены синтаксическим расширением.
http://nemerle.org/Banners/?t=Developer!&g=dark /* иЗвиНите зА неРовнЫй поЧерК */
Re[11]: C# 7 - названия и прочее
От: Sinix  
Дата: 12.05.15 11:34
Оценка: :)
Здравствуйте, hardcase, Вы писали:

S>>Чтоб не спорить впустую — можешь привести реальный полезный пример расширения синтаксиса?


H>LINQ по сути — расширение синтаксиса.


Если бы Это только вишенка на торте, снизу куча работы, навскидку:
+ expression trees (пилились местами с учётом будущего DLR) + компиляция + допиленный emit.
+ провайдеры ef/linq2sql, добавился вывод параметров для генериков и лямбд
+ кодогенерация для yield
+ linq for objects (тоже не совсем простая штука)
+ поддержка всей этой радости студией (по объёму работы было столько, что "живая" подсветка ошибок в итоге получилась почти нахаляву) и тыды и тп.

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


H>Анонимные типы в Nemerle воспроизведены синтаксическим расширением.


Ну.. это классно конечно, но какой толк от этого в шарпе при наличии готовых анонимных типов?

В том-то и проблема, что для AOP есть безусловно понятные и полезные примеры. Для DSL — тоже. А для макросов всё заканчивается на пользе для авторов языка (тут всё бесспорно как бы) и на "ну... можно накрутить вот так, а ещё вот так". Причём для последнего ещё и выяснится, что сам товарищ предлагающий этот вариант не пробовал, т.е. ему он тоже не особо нужен

Это ни в коем случае не наезд, было бы реально интересно увидеть полезный на практике пример.
Re[12]: C# 7 - названия и прочее
От: agat50  
Дата: 12.05.15 12:02
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>В том-то и проблема, что для AOP есть безусловно понятные и полезные примеры. Для DSL — тоже. А для макросов всё заканчивается на пользе для авторов языка (тут всё бесспорно как бы) и на "ну... можно накрутить вот так, а ещё вот так". Причём для последнего ещё и выяснится, что сам товарищ предлагающий этот вариант не пробовал, т.е. ему он тоже не особо нужен


S>Это ни в коем случае не наезд, было бы реально интересно увидеть полезный на практике пример.


Мне кажется, тут дело не в разделении dsl\макросы\aop. Нужна возможность запускать собственный код в compile time с возможностью доступа к AST и его изменения. Только для шарпа — IL тут не при чем. А уж макросы это будут, postsharp like before\onExit или атрибуты — вопрос второй. Макросы наверное отлаживать легче чем вручную. Они опять-таки не должны быть даже единого формата. Атрибутами указывать что вызвать, чего туда передавать и в каком порядке все это исполнять. Т.е. препроцессор шарпа на .net
Отредактировано 12.05.2015 12:05 agat50 . Предыдущая версия .
Re[13]: C# 7 - названия и прочее
От: Sinix  
Дата: 12.05.15 12:20
Оценка:
Здравствуйте, agat50, Вы писали:

S>>Это ни в коем случае не наезд, было бы реально интересно увидеть полезный на практике пример.


A>Мне кажется, тут дело не в разделении dsl\макросы\aop.

К сожалению, есть. Из реального опыта: пока кодогенерация живёт отдельно (неважно — dsl это, или обработка размеченных атрибутами типов/сборок) — всё отлично. Как только метапрограммирование пытаются прикрутить на уровень отдельных языковых конструкций или распространить за пределы одной сборки — начинается фигня.

Потому что для языковых конструкций нет изоляции как таковой, они или используются повсеместно, или не должны использоваться вообще. Не, изобрести новую общеупотребительную конструкцию шансы конечно есть, примерно как придумать полезный extension-метод для object. Одна проблема: затраты/выигрыщ по сравнению с метапрограммированием на атрибутах выглядят совсем уж непристойно


A>Нужна возможность запускать собственный код в compile time с возможностью доступа к AST и его изменения. Только для шарпа — IL тут не при чем.

Вот тут +100500.
Re[10]: C# 7 - названия и прочее
От: hi_octane Беларусь  
Дата: 12.05.15 12:46
Оценка: 118 (4) +2
VD>>Ну, и твои подозрения, что расширения синтаксиса это что-то сложное, страшное и опасное ничем не отличаются от подозрений оп поводу того, что "var" сделает код программ нечитабельным.
S>Чтоб не спорить впустую — можешь привести реальный полезный пример расширения синтаксиса?
S>Потому что для AOP я с ходу десяток примеров приведу, для расширения синтаксиса — только мелочёвка типа счётчика в foreach или foreach ... else. Ну несерьёзно это

1) readlock(ReaderWriterLock/Slim){} / writelock(ReaderWriterLock/Slim){}, их же для локов на async/await (реврайтер там уровня using)

2) .FirstOrDefault, .Distinct, и прочие — думаю имей C# расширения, появились бы в nuget'е через неделю после выхода linq, включая insert, update, delete

3) Razor — он же по сути своей расширение синтаксиса C# (если на него посмотреть как на C# в котором можно фигачить текст, а не как текст в котором можно фигачить C#), туда же весь .xaml — оформить как расширение синтаксиса в духе Razor, ибо xml не ах

4) interlocked-переменные (ты ей ++, а под капотом вызывается Interlocked.Increment, ты ей += а там .Add, и т.п.)

5) генераторы не как в C#, а как в EcmaScript 6, где можно var a = yield return b; — тогда связанные между собой конечные автоматы становятся проще

6) def или let для иммутабельных переменных, в противовес var который мутабельный

7) var d = new Dictionary<string name, DateTime dateOfBirth>() — и чтоб в этом Dictionary с этого момента никаких TKey и TValue, а мои name и dateOfBirth, и чтоб Intellisense понимал

8) Возможность объявлять произвольные операторы (по идее тут можно и без макросов расширения синтаксиса)

9) Встраивание кода на другом языке, например asm { и погнали на IL }

10) mixin-ы (тут не уверен, может можно выкрутиться на имеющемся синтаксисе)

11) Встроенный парсинг простых регулярок, например regex var {(?<a:int>\d+)\s*-\s*(?<b:decimal, auto>)\s*-\s*(?<c:double,auto>)} = str; — с раскраской и автокомплитом, произвольной закрывающей скобкой (определяется по открывающей, чтоб экранирование не надобилось в 90% случаев), кусочки json'а туда же

12) Макросы для оптимального разворачивания математических операций, сейчас люди мозги вывихивают чтоб две большие матрицы сложить "in place", ибо static operator + полагает что нужен новый объект

13) Свой new (из пула например), delete (в дебаге например ещё и заставляющий проверить GC что ссылок на объект нет и ассертящий если вдруг нашлось)

14) parallel for, parallel foreach и т.п. — там вообще все методы принимают лямбды, а ведь можно чисто и красиво

15) переписать linq to objects на макросах, так чтобы простые локальные случаи работали без потерь перфоманса (типа .Where().Sum(), .Any(), .First() и т.п)

16) Синтаксис для выноса контрактов в объявление метода, включая ссылки на контракты (например группа методов не должна нарушать один и тот же набор инвариантов).

17) Собственные контракты, например часто встречаются методы которые можно вызвать только когда лок уже взят. Хотелось бы повесить на них requires lock SyncRoot, и дальше чтоб компилятор позволял эти методы вызывать только из под lock(SyncRoot) или из методов которые ограничены таким же requires, нарушение ограничения — ошибка компиляции

18) Ключевые слова для функций захватывающих объект "для себя", например часто встречаются конструкторы принимающие массив, и они внутри себя делают Array.Copy потому что не знают, будет этот массив меняться внешним кодом, или нет. Был бы макрос например "Vector(captures double[] row) { this.row = row; }", и компилятор во внешнем коде делал "undefined" входному значению, или бил бы по пальцам за попытку туда писать, или же наоборот, при обнаружении попытки записи варнил а на вход передавал копию — тут уже возможны варианты. А то сейчас есть приложение которое 5% мемори траффика генерирует на такой вот фигне.

Это сходу. А если начать думать...
Re[12]: C# 7 - названия и прочее
От: hardcase Пират http://nemerle.org
Дата: 12.05.15 13:02
Оценка: +1
Здравствуйте, Sinix, Вы писали:

S>Если бы Это только вишенка на торте, снизу куча работы, навскидку:

S>+ expression trees (пилились местами с учётом будущего DLR) + компиляция + допиленный emit.

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

S>+ провайдеры ef/linq2sql, добавился вывод параметров для генериков и лямбд


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

S>+ кодогенерация для yield


Было в C# 2.0

S>+ linq for objects (тоже не совсем простая штука)


Библиотека.

S>Ну.. это классно конечно, но какой толк от этого в шарпе при наличии готовых анонимных типов?


Это тебе в качестве примера того, чем вообще могут быть полезны синтаксические макросы.
http://nemerle.org/Banners/?t=Developer!&g=dark /* иЗвиНите зА неРовнЫй поЧерК */
Re[14]: C# 7 - названия и прочее
От: WolfHound  
Дата: 12.05.15 13:30
Оценка: 36 (1)
Здравствуйте, Sinix, Вы писали:

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

В Nitra есть.
namespace Ns
{
  using TypeAlias;// загрузили синтаксис для type 
  type X = A.B;
}
type X = A.B;//А тут уже нельзя.


A>>Нужна возможность запускать собственный код в compile time с возможностью доступа к AST и его изменения. Только для шарпа — IL тут не при чем.

S>Вот тут +100500.
Без возможности добавлять свой АСТ со своей типизацией получается довольно убого.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: C# 7 - названия и прочее
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.05.15 13:38
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Суть того что нужно сделать — объединить эти две вещи в единой спецификации. Пока такого публично я не видел, так что и говорить о какой либо терминологии и синтаксисе слишком рано.


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

AVK>Мелочь одну — переписали с нуля JIT.


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

А, вообще, ты заводишь старую шарманку. В прошлые разы ты примерно так же объяснял отсутствие того, что к данному моменту уже добавили или уже решили добавить в 7-ке.

Уверен, что лет через дцать ты снова согласишься с МС, когда они все это реализуют.

Ну, и переписать все с нуля для них не такая уж огромная работа. Раз в 15 лет ее можно и проделать. Вон с компилятором шарпа решились ведь. А раньше ты сам мне рассказывал, что использовать единый код для языкового сервиса и компилятора невозможно и приводил кучу доводов по этому поводу. Тут будет так же.

VD>>Ну, и до кучи надо ввести замену этому убогому delegate — функциональный тип.


AVK>Это, очевидно, практически невозможно из-за совместимости.


Это очевидно только для тебя. И обосновать ты это не сможешь хотя бы потому, что данные типы уже существуют в двух дотнетных языках: Nemerle и F#.

Лично мне очевидно, что делегат может (и должен) быть конкретным, именованным воплощением функционального типа. И, что тип этот лучше перенести в рантайм дотнета, чтобы все языки использовали одно единое решение, а не городили бы свои реализации. Под копотом его вполне можно реализовать на основе те же делегатов.

Еще мне очевидно, что замыкания тоже должны поддерживаться рантаймом, а не переписываться в паттерны на основе объектов. Тогда рантайм сможет полноценно оптимизировать функциональный код и донтет станет полноценным мультиязыковым фрейворком, а не рантаймом для C#, как сейчас.

Пройдут годы и все это будет очевидно всем. Только те кто сейчас спорят будут делать вид, что им это было очевидно и раньше. Такова природа человека. Признать неверные решения очень сложно. Даже сложнее чем осознать их неверность.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: C# 7 - названия и прочее
От: Sinix  
Дата: 12.05.15 13:40
Оценка:
Здравствуйте, hi_octane, Вы писали:

_>Это сходу. А если начать думать...

Однако!

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


С другой стороны, предложения типа "Свой new / delete" или "Ключевые слова для функций захватывающих объект "для себя"" в шарп точно не попадут, а в отдельных проектах точно будут полезны.
В общем да, я точно был неправ с "сценариев для расширения синтаксиса нет" — эти штуки практически никак не покрываются через AOP на атрибутах и по сути покрывают отдельный набор сценариев — экспериментальные возможности, которые со временем попадут (или не попадут) в язык. Спасибо!


_>12) Макросы для оптимального разворачивания математических операций, сейчас люди мозги вывихивают чтоб две большие матрицы сложить "in place", ибо static operator + полагает что нужен новый объект

А можно пример, про что речь? Никто ж не запрещает сделать первый операнд каким-нибудь MutableMatrix и изменять его в операторе сложения.
Re[12]: C# 7 - названия и прочее
От: hi_octane Беларусь  
Дата: 12.05.15 14:17
Оценка: 43 (2) +2
S>Я почему-то не рассматривал сценарии из разряда "исправь недоработки шарпа". Подозреваю, потому что при очень большом желании это можно сделать и сейчас — исходники открыты, автоматизировать сборку и подтягивание свежей версии компилятора тоже несложно. Ну и по хорошему, если уж чинить, то в самом репо — пулл-реквесты всё-таки принимают

И получить убер-компилятор полный конфликтов и велосипедов? Держать ветки компилятора рядом с ветками проекта? А потом ещё и мержить их время от времени? Макросы хороши тем что их захотел включил, захотел ручками вызвал по полному имени, захотел — командно-административно использование запретил.

S>С другой стороны, предложения типа "Свой new / delete" или "Ключевые слова для функций захватывающих объект "для себя"" в шарп точно не попадут, а в отдельных проектах точно будут полезны.

S>В общем да, я точно был неправ с "сценариев для расширения синтаксиса нет" — эти штуки практически никак не покрываются через AOP на атрибутах и по сути покрывают отдельный набор сценариев — экспериментальные возможности, которые со временем попадут (или не попадут) в язык. Спасибо!

Дык я сам против того чтобы они все попали в один язык суть в том чтобы под задачу какие-то возможности были а какие-то нет. В C++ мы же не инклудим сразу весь буст включая экспериментальные ветки, и не плачем когда обнаруживаем что (гипотетически) дефайны Server 2012 DDK конфликтуют с дефайнами WinPhone SDK. Вот макросы дают такую фишку как "фичи нужные по месту", и кроме них собственно больше никто не даёт.

_>>12) Макросы для оптимального разворачивания математических операций, сейчас люди мозги вывихивают чтоб две большие матрицы сложить "in place", ибо static operator + полагает что нужен новый объект

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

Ну мы то сделали велосипед, но он внутри устроен сложно и иногда ведёт себя непредсказуемо (для математиков) по скорости. Например чистый MutableMatrix сломается на сценарии var C = A + B; var TA = A.Transpose(); var D = A; — если A изменится в операторе сложения, то результат Transpose будет уже не торт. Поэтому мы делаем операцию как будто она mutable, и в матрице храним её "rvalue" и "lvalue", чтоб в этом сценарии копирований не было, вовремя сбрасываем эти "?value", в зависимости от операций, и огребаем мемори траффик, но более терпимый чем в случае если новый объект создаётся на каждый + (да ещё и пониженный за счёт пула). Но из-за этих хитростей сам код библиотеки раздут и понятен только тем кто знает зачем оно, а нормальным людям кажется что всё переусложнено на ровном месте. На "макрооператорах", это было бы чище, проще и совсем без траффика. Другой вопрос что вроде в самом Nemerle макрооператоров тоже пока нету но можно выкрутиться используя обычные операторы и сделав объявление типа matrix синтаксическим макросом.
Re[15]: C# 7 - названия и прочее
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.05.15 16:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>В Nitra есть.

WH>
WH>namespace Ns
WH>{
WH>  using TypeAlias;// загрузили синтаксис для type 
WH>  type X = A.B;
WH>}
WH>type X = A.B;//А тут уже нельзя.
WH>


В Nemerle тоже самое есть. Найтра, правда, позволит нам сделать такие юсинги в любом месте, а не только в пространствах имен. Но это уже детали.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.