Мысль высказанная там тривиальна как все гениальное. Я почему-то не смог мыслить так же широко .
Тут нам постоянно указывают, что для продвижения немерла нужны какие-то там килер-фичи и килер-приложения. При этом те кто это что-то хочет даже не задумываются над тем, что же есть на сегодя и что можно.
Мне кажется было бы очень здорово если бы кто-нибудь создал бы визуальный демонстратор возможностей Nemerle, на подобии 101 примера к Асинку.
Идея очень простая. Надо создать визуальное приложение (на WPF или на WinForms) у которого сбоку расположено дерево в котором сгруппированы примеры по разным возможностям немерла. При выборе одного из пунктов на экране появляется краткое описание возможности, код ее демонстрирующий и кнопки запуска/отмены. При нажатии на кнопку запуска выполняется аналогичный код скомпилирвоанный ранее (а может быть и динамически). Результат выводится тут же в свободной части окна.
Уверен, что такая программа могла бы упростить изучение немерла и популяризировала бы его.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Идея очень простая. Надо создать визуальное приложение (на WPF или на WinForms) у которого сбоку расположено дерево в котором сгруппированы примеры по разным возможностям немерла.
Здравствуйте, Denom, Вы писали:
D>Как по мне так лучше WPF/Silverlight а сами примеры — консольные. D>Нелохо-бы сначала составить список возможностей языка, для которых нужны примеры.
1) Стандартные макросы-плюшки: Accessor, Record
2) Фичи которые чуть-чуть круче чем в C#: foreach-otherwise, using-finally, when c ad-hoc ПМ, анонимные классы
3) Фичи которых нет в C#, но тем не менее полезны: ?., surrowndwith, regexp match
4) Гайд по XML литералам
5) Гайд по Continuation Expressions
6) Гайд по PEG
7) Гайд по Актив паттернам (но их нужно еще дописать)
8) Пример компиляции C# исходников
...
Здравствуйте, Denom, Вы писали:
D>Как по мне так лучше WPF/Silverlight а сами примеры — консольные.
Чем WPF/Silverlight лучше? скорее всего gui будет красивее, но будет работать только под windows.
Что значит примеры консольные? Смысл в том, чтобы сделать как 101 C# Async Samples: слева дерево примеров, справа две облости, при выборе примера в одной показывается исходный код (+ табы для других языков для сравнения), при запуске в другой области показывается output. Пример запускается не как отдельный процесс, а отдельным потоком в самом приложении.
В 101 C# Async Samples весь исходный код находиться в одном файле и при выборе показывается только его часть, в случае Nemerle это не очень хорошо, так как если человек захочит скопировать код, он не будет знать, какие нужно использовать using. Поэтому, в качестве исходного кода лучше показывать пример, который можно скопировать и скомпилировать в виде консольного приложения. Запускать пример стоит через макрос late, так это позволит не вводить лишние зависимости на код примера.
Сами исходники для показа, наверное, стоит встранивать как ресурсы в сборку.
H>Здравствуйте, Denom, Вы писали:
H>7) Гайд по Актив паттернам (но их нужно еще дописать)
Я как раз завтра собрался дописать их, что нужно в них изменить? Я думаю отказаться от макроса Pattern и определять активные паттерны по сигнатуре ( ... -> Some(...)), это позволит определять паттерны в других сборках.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Denom, Вы писали:
D>>Как по мне так лучше WPF/Silverlight а сами примеры — консольные. D>>Нелохо-бы сначала составить список возможностей языка, для которых нужны примеры.
H>1) Стандартные макросы-плюшки: Accessor, Record H>2) Фичи которые чуть-чуть круче чем в C#: foreach-otherwise, using-finally, when c ad-hoc ПМ, анонимные классы H>3) Фичи которых нет в C#, но тем не менее полезны: ?., surrowndwith, regexp match
ИМХО обязательно паттерн матчинг во всем его многообразии. Конструкторы списка.
H>4) Гайд по XML литералам H>5) Гайд по Continuation Expressions
Computation Expressions?
H>6) Гайд по PEG H>7) Гайд по Актив паттернам (но их нужно еще дописать) H>8) Пример компиляции C# исходников H>...
РД>В 101 C# Async Samples весь исходный код находиться в одном файле и при выборе показывается только его часть, в случае Nemerle это не очень хорошо, так как если человек захочит скопировать код, он не будет знать, какие нужно использовать using. Поэтому, в качестве исходного кода лучше показывать пример, который можно скопировать и скомпилировать в виде консольного приложения. Запускать пример стоит через макрос late, так это позволит не вводить лишние зависимости на код примера.
Фишка в компактности. Ничего лишнего — только код по конкретной фиче. Чем меньше кода, тем лучше — проще понять. Тут нужно искать компромисс.
Здравствуйте, Рысцов Денис, Вы писали:
РД>Чем WPF/Silverlight лучше? скорее всего gui будет красивее, но будет работать только под windows.
РД>Что значит примеры консольные?
Ну прогнал я. Пусть будет как в linq samples.
Консольные примерамы — значит что можно взять готовый exe и запустить его самомтоятельно.
Как в примерах nvidia (directx/opengl/cuda) — в составе sdk собранные приложения.
Здравствуйте, hardcase, Вы писали:
H>5) Гайд по Continuation Expressions
Что имеется ввиду
— computation expressions?
— правила построения своих computation expressions или
использование конкретніх реализаций — async/cont etc
Здравствуйте, VladD2, Вы писали:
VD>Мысль высказанная там тривиальна как все гениальное. Я почему-то не смог мыслить так же широко .
Предлагаю ход конем.
Когда-то я начинал изучать Linq с LinqPad'а. Слева там есть дерево всех примеров, по которому было очень удобно пройтись, посмотреть каждый пример, запустить его, поправить код и посмотреть, как изменились результаты. Сейчас в LinaPad'е есть уже и поддержка F#..
Почему бы вам не предложить авторам LiqnPad'a поддержку Nemerle? Уверен, что лучшей рекламы для Nemerle придумать сложно, т.к. LinqPad'ом наверняка уже пользуется куча народу и, увидев в очередном апдейте LinqPad'a поддержку Nemerle, люди наверняка заинтересуются.
Здравствуйте, Denom, Вы писали:
D>Здравствуйте, hardcase, Вы писали:
H>>5) Гайд по Continuation Expressions D>Что имеется ввиду D> — computation expressions?
Конечно Computation Expressions. Что в голове — то и на пальцах (я тогда кое какую доку по CPS-трансформации читал).
D> — правила построения своих computation expressions или D> использование конкретніх реализаций — async/cont etc
Глвавное, конечно, использование того, что предоставляет библиотека.
Здравствуйте, Димчанский, Вы писали:
Д>Предлагаю ход конем. Д>Когда-то я начинал изучать Linq с LinqPad'а. Слева там есть дерево всех примеров, по которому было очень удобно пройтись, посмотреть каждый пример, запустить его, поправить код и посмотреть, как изменились результаты. Сейчас в LinaPad'е есть уже и поддержка F#.. Д>Почему бы вам не предложить авторам LiqnPad'a поддержку Nemerle? Уверен, что лучшей рекламы для Nemerle придумать сложно, т.к. LinqPad'ом наверняка уже пользуется куча народу и, увидев в очередном апдейте LinqPad'a поддержку Nemerle, люди наверняка заинтересуются.
Это было бы очень круто. Как инструмент по изучению языка и порождаемого IL.
Не уверен только, что они захотят тратить деньги на разработку и поддержку расширения для малоизвестного языка. Хотя вся инфраструктура для этого у них есть, я глянул мельком рефлектором, там надо всего пару-тройку классов добавить для поддержки нового языка. Лексер, компилер и возможно дампер. У них еще многое через CodeDom сделано, а с ним емнип у немерла не все гладко.
Самостоятельная же реализация nemerlepad'а без такой крутой поддержки linq довольно проста, сложность только в редакторе с подсветкой синтаксиса да ошибок рантайма и компиляции, разве что взять что-то готовое.
Проблема еще в том, что у немерла своя специфика, это макросы, которые должны помещаться в отдельную сборку, что противоречит простеньким однофайловым семплам.
Здравствуйте, Рысцов Денис, Вы писали:
РД>В 101 C# Async Samples весь исходный код находиться в одном файле и при выборе показывается только его часть, в случае Nemerle это не очень хорошо, так как если человек захочит скопировать код, он не будет знать, какие нужно использовать using. Поэтому, в качестве исходного кода лучше показывать пример, который можно скопировать и скомпилировать в виде консольного приложения. Запускать пример стоит через макрос late, так это позволит не вводить лишние зависимости на код примера.
Лучше прост компилировать на лету (сборки кэшировать, чтобы пользователь не ждал каждый раз).
РД>Сами исходники для показа, наверное, стоит встранивать как ресурсы в сборку.
Лучше просто в каталоге держать. По каталогам и дерево можно делать.
Тогда примеры будет очень просто расширять. Создал катало, положил туда один или более исходников и готово.
Ссылки на сборки можно описывать как в тестах компилятора — в виде комментариев.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ka3a4oK, Вы писали:
РД>>В 101 C# Async Samples весь исходный код находиться в одном файле и при выборе показывается только его часть, в случае Nemerle это не очень хорошо, так как если человек захочит скопировать код, он не будет знать, какие нужно использовать using. Поэтому, в качестве исходного кода лучше показывать пример, который можно скопировать и скомпилировать в виде консольного приложения. Запускать пример стоит через макрос late, так это позволит не вводить лишние зависимости на код примера.
KK>Фишка в компактности. Ничего лишнего — только код по конкретной фиче. Чем меньше кода, тем лучше — проще понять. Тут нужно искать компромисс.
Это решаемый вопрос. У нас есть сокращенный синтаксис. А все что нужно можно заложить в базовую сборку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Самостоятельная же реализация nemerlepad'а без такой крутой поддержки linq довольно проста, сложность только в редакторе с подсветкой синтаксиса да ошибок рантайма и компиляции, разве что взять что-то готовое.
С редактором, думаю, проблем не будет. Я много лет назад написал один такой. Если постараться, то можно будет даже интеллисенст и хинты туда прикрутить.
Z>Проблема еще в том, что у немерла своя специфика, это макросы, которые должны помещаться в отдельную сборку, что противоречит простеньким однофайловым семплам.
Да не особо оно противоречит. В тестах полно таких примеров. Сами тесты являются однофайловыми, но если нужна сборка, то один файл может сослаться на другой как на сборку. Вот пример теста состоящего из двух файлов: CompilerEventsMacroLib.n — макро-библиотека (она, кстати, импортирует Nemerle.Compiler.dll). CompilerEventsTest.n — а это тест использующий сборку создаваемую предыдущим файлом. Обрати внимание на комментарий в в начале этого файла. Он приказывает импортировать сборку получаемую из предыдущего файла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>Проблема еще в том, что у немерла своя специфика, это макросы, которые должны помещаться в отдельную сборку, что противоречит простеньким однофайловым семплам.
VD>Да не особо оно противоречит. В тестах полно таких примеров. Сами тесты являются однофайловыми, но если нужна сборка, то один файл может сослаться на другой как на сборку. Вот пример теста состоящего из двух файлов: VD>CompilerEventsMacroLib.n — макро-библиотека (она, кстати, импортирует Nemerle.Compiler.dll). VD>CompilerEventsTest.n — а это тест использующий сборку создаваемую предыдущим файлом. Обрати внимание на комментарий в в начале этого файла. Он приказывает импортировать сборку получаемую из предыдущего файла.
Да я в курсе, тут непонятно, кто и когда должен собрать эту сборку. Имхо, пример должен быть самодостаточным и помещаться на экране. Может как-то так:
А немерлпад разобьет на два файла, скомпилит оба и запустит. При этом директивы импорта тоже стоит оставить. Не вызовет ли это ошибок для начинающих при переходе с пада на компилятор? Может вообще научить компилятор выдергивать макры до компиляции,
Еще одна проблема которую я не пойму как элегантно решить — использование либ немерла из установленной версии немерла, а при отсутствии оного идущих с падом. Хватит ли тут обработчика AssemblyResolove?
Здравствуйте, Ziaw, Вы писали:
Z>Да я в курсе, тут непонятно, кто и когда должен собрать эту сборку.
Дык само демонстрационное приложение и соберет.
Z>Имхо, пример должен быть самодостаточным и помещаться на экране.
Можно сделать закладки. На каждой по файлу.
Z>...А немерлпад разобьет на два файла, скомпилит оба и запустит.
Это уже какая-то не очевидная химия. Да и объем кода увеличивается что противоречит требованию "помещаться на экран...".
Z>При этом директивы импорта тоже стоит оставить. Не вызовет ли это ошибок для начинающих при переходе с пада на компилятор?
Не знаю. Я как-то проблем не испытывал когда первый раз увидел приложение тестирующее компилятор.
Z>Может вообще научить компилятор выдергивать макры до компиляции,
Дык это еще больше может запутать. Вот как люди пытаются скомпилировать макры в основном проекте я наблюдал не однократно.
Z>Еще одна проблема которую я не пойму как элегантно решить — использование либ немерла из установленной версии немерла, а при отсутствии оного идущих с падом. Хватит ли тут обработчика AssemblyResolove?
Я думаю, что такое приложение нужно поставлять в составе инталлятора компилятора/интеграции. Тогда и проблем со сборками не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это уже какая-то не очевидная химия. Да и объем кода увеличивается что противоречит требованию "помещаться на экран...".
Один пример — один файл, разбитие на вкладки повлечет создание аналога nproj и урезанного мсбилда. Примером не обменяешься уже.
Z>>При этом директивы импорта тоже стоит оставить. Не вызовет ли это ошибок для начинающих при переходе с пада на компилятор?
VD>Не знаю. Я как-то проблем не испытывал когда первый раз увидел приложение тестирующее компилятор.
Тогда и директива MACRO не вызовет непонимания, надо лишь где-то явно это описать.
VD>Дык это еще больше может запутать. Вот как люди пытаются скомпилировать макры в основном проекте я наблюдал не однократно.
Но вкладки еще большее зло. Тогда уж обрезать шарпдевелоп по самое не могу и давать ему солюшен с кучей проектов. Будет идеальная среда для запуска, дебага, с подсветкой и комплишеном.
VD>Я думаю, что такое приложение нужно поставлять в составе инталлятора компилятора/интеграции. Тогда и проблем со сборками не будет.
А его можно под другой лицензией в составе пустить? Я тут смотрю редакторы, некоторые под GPL.
Здравствуйте, Ziaw, Вы писали:
Z>Один пример — один файл, разбитие на вкладки повлечет создание аналога nproj и урезанного мсбилда. Примером не обменяешься уже.
Да ничего оно не повлечет. Тесты компиляторные же работают?!
Z>Тогда и директива MACRO не вызовет непонимания, надо лишь где-то явно это описать.
А вот это как раз не очевидно. В прочем, я повторяюсь. И вообще, если что-то надо описывать, то это явно не интуитивно.
А так люди будут прекрасно понимать, что каждый файл описывает сборку.
Z>Но вкладки еще большее зло.
Это почему же?
Z>Тогда уж обрезать шарпдевелоп по самое не могу и давать ему солюшен с кучей проектов. Будет идеальная среда для запуска, дебага, с подсветкой и комплишеном.
Обрезать чужие проекты нельзя. Потом ты про цель не забыл? Никому не нужна IDE. Они уже есть и прекрасно работают в необрезанном виде. Всем нужен демонстратор аля "101 пример". Если в на экране в некотрых примерах (требующих доп.сборку) будет две закладки это ничего не изменит.
VD>>Я думаю, что такое приложение нужно поставлять в составе инталлятора компилятора/интеграции. Тогда и проблем со сборками не будет.
Z>А его можно под другой лицензией в составе пустить?
Можно но не нужно.
Z>Я тут смотрю редакторы, некоторые под GPL.
А зачем? Я тебе уже давал ссылку. Редактор есть. Там особых наворотов не нужно. Была бы подсветка синтаксиса и ладно. А в перспективе можно хоть всю интеграцию прилепить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
