?

Log in

No account? Create an account

Excelsior

Feb. 19th, 2013

02:07 pm - Презентация по макросам для BASE (Сан-Франциско, 13 июня 2013)

http://www.meetup.com/Bay-Area-Scala-Enthusiasts/events/105314372/

Пока еще не придумал, о чем именно буду рассказывать. Может, о чем-нибудь философском, может о том, что наколбасим в ближайшее время. Я потом еще планировал на день-два остаться в Bay Area - буду рад развиртуализироваться с уважаемыми френдами!

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

Feb. 18th, 2013

09:55 am - friend page => google reader?

Народ, есть ли способ в гуглоридере читать френдленту вместе с friends-only постами? Просто ссылку на rss фленты я нашел, но для протектед постов ей нужен или куки или ?auth=digest, ни один из которых не поддерживается гуглоридером. Если есть для этого дела какой-то платный сервис, это тоже подойдет.

Feb. 15th, 2013

03:32 pm - так ли нужна для счастья мощь макросов?

Обязательна ли для счастья вся мощь манипуляции абстрактными синтаксическими деревьями или же достаточно менее мощного, но более формализованного решения? Эту тему мы на прошлой неделе обсуждали в гостях в udpn: http://udpn.livejournal.com/94146.html и фрагмент этого обсуждения я бы хотел вынести в этот пост.

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

Как народ юзает макросы? По этому поводу я пару месяцев назад писал саммари: http://scalamacros.org/news/2012/11/05/status-update.html. С того времени добавилось еще вот что интересное: 1) тайп провайдеры (http://docs.scala-lang.org/overviews/macros/typemacros.html), 2) программируемый вывод типов (http://docs.scala-lang.org/overviews/macros/inference.html).

Какие варианты пробовали, почему не понравились? По-хорошему, здесь надо написать паперу, а не пост. Сейчас я попробую очень вкратце выразить свои мысли. Я заранее извиняюсь, что кратко, но буду рад ответить на любые каменты в пределах своих знаний.

Классический способ метапрограммирования в Скале - вычисления на типах и имплисит параметрах. Я здесь совсем не специалист, но люди достигают потрясающих результатов. Управляют тайп инференсом, разбирают типы на запчасти, запрещают или разрешают вызовы методов, и т.д. Тут может больше рассказать уважаемый juan_gandhi. К сожалению, временами получается довольно тяжеловесная жесть: https://github.com/scalaz/scalaz/blob/59cfba6e8e293ec24c8b610ced057e0376c13a3f/core/src/main/scala/scalaz/Unapply.scala.

То, что мы пробовали вначале как основу для макросов, очень похоже на MacroML. Строго типизированные квазицитаты по имени reify (т.е. никаких тебе игр с биндингами), нет поддержки деструктурирования. В теории это, может, и выглядит хорошо (по разговору с Тахой - Walid Taha - я так понял, что он макросы в неконтролируемом смысле вообще не уважает), но на практике пока что народ не нашел способов юзать reify хоть отдаленно эффективно, т.к. почти всегда (см. use cases выше) нужны нетипизируемые квазицитаты (которые по отдельности смысла не имеют, а, будучи слепленными вместе, дают вменяемый результат).

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

03:19 pm - макросы для внутреннего использования

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

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

***

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

Генерация реифицированных типов работает следующим образом. Если кому-то нужно для тайп-параметра T заполучить реифицированный тип (т.е. чтобы каждый полиморфный вызов сохранял тайп-аргумент T), то он пишет: def foo[T](параметры блаблабла)(implicit t: TypeTag[T]) = [тело функции бла бла]. У этой записи есть синтаксический сахар, т.е. она обычно очень компактная, но сейчас не об этом. В итоге, если программист вызывает foo[Int](...), то компилятор сгенерирует TypeTag[Int]. Если вызывается foo[List[T] forSome { type T <: C }](...) или еще какая-нибудь жесть, компилятор все равно сгенерирует точное представление тайп-аргумента. Наконец, если функция foo расположена внутри метода bar[T] с тайптегом для T и вызывается как foo[T](...), то тайптег из bar протечет в вызов foo. Могу потом подробнее рассказать.

Раньше в Implicits.scala, слое компилятора, который отвечает за имплисит серч, был хардкод типа "if (tp.typeSymbol == definitions.TypeTagClass) synthesizeTypeTag". А теперь там вообще нифига нет. Просто в стандартном prelude у нас есть макрос "implicit def materializeTypeTag[T]: TypeTag[T]" (на самом деле, немного не так, но это технические детали). В итоге: убрали хардкод из тайпчекера (т.е. упростили и сделали красивее) + мне (не как аппликейшен девелоперу, а как мейнтейнеру компилятора) стало гораздо легче менять реализацию materialize, т.к. она теперь связана с API компилятора через интерфейс macro API, а не в стиле "можем использовать все, до чего импорты дотянутся".

Еще одна вещь, которую мы планируем - использование макросов для программируемого инлайнинга. К сожалению, на текущий момент наш инлайнер не очень умный и часто не инлайнит то, что надо, пользуясь своими неочевидными для гуманоидов эвристиками. Если сделать важные методы (например, методы коллекций) макросами, то можно либо 100% гарантировать инлайнинг, либо иметь возможность писать доменно-специфические эвристики.

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

О. Еще. При помощи макросов можно одновременно и упростить, и обобщить deriving (для тебя это, вероятно, не новость, но для полноты можно упомянуть). Кое-что на эту тему было видно вот тут: http://docs.scala-lang.org/overviews/macros/inference.html, но есть и другой аспект - при помощи макросов можно генерить бойлерплейт-методы в классах. Даже при текущих убогих технологиях народ уже что-то фигачит: https://github.com/dicarlo2/ScalaEquals, а дальше можно будет просто поставить аннотацию на класс, и она сама все сделает.

Dec. 20th, 2012

08:48 am - Scala 2.10.0 staged!

Adriaan Moors writes:

Good news everybody!

I've just uploaded Scala 2.10.0 to sonatype.org.

Yes indeed, that would be the final! The bytecode is the same as RC5. The
only change is the metadata.

As the holidays are extremely nigh, we have decided to wait a little bit
longer than usual to announce the release: we'll make it official by the
end of the first week of the new year.

http://groups.google.com/group/scala-internals/browse_thread/thread/dd1ef14c985c3742

Tags:

Dec. 19th, 2012

08:54 am - Тайп макросы и квазицитаты

Сегодня у меня две хорошие новости. Во-первых, уже совсем скоро финальный релиз 2.10.0 (если никто не найдет критических багов, сабж случится 26 декабря). А во-вторых, мы как раз на днях запилили тайп макросы и квазицитаты. На эту тему можно почитать слайды http://scalamacros.org/talks/2012-12-18-MacroParadise.pdf, а также посмотреть скринкаст и поучаствовать в обсуждении в почтовой рассылке (ссылки см. на первых страницах слайдов).

Tags:

Dec. 11th, 2012

11:23 am - сублайм => емакс

После недавнего дискашена у metaclass и tonsky (клик клик) решил снова попробовать емакс. Особенно с учетом того, что сублайм closed source и развитие его, еще три-четыре месяца назад весьма бодрое, полностью остановилось.

Подумал и с удивлением заметил, что в сублайме для меня киллер фич не так уж и много. Первое это очень быстрый поиск по файлам в проекте (find + grep гораздо медленнее, к сожалению). Второе это возможность сохранять стейт проекта (открытые файлы, позиции в них) между запусками. Третье и четвертое это сниппеты и дефинишены синтаксиса (использующиеся для подсветки, комментирования и выщемливания определений - классов, методов, и т.п.). Вроде бы, все. Какой в этом плане state of the art в емаксе?

Еще доставляет go to symbol, который показывает список всех определений в файле и предоставляет для них fuzzy matching. Особенно удобно то, что по мере набора имени определения положение вьюпорта меняется, прокручивая файл к текущему в данный момент айтему. Вдвойне удобно, что по нажатию Escape вьюпорт откатывается обратно на позицию до начала поиска. Интересно, есть ли что-то такое уже существующее для емакса?

Screen Shot 2012-12-11 at 11.03.38

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

Tags:

Nov. 10th, 2012

10:56 am - макось: впечатления свитчера

Долго пытался сформулировать тему, о которой хочу написать. Попробую неформально. Если взять весь экспириенс с макбуком, вычесть отличное железо, вычесть "консоль" (т.е. доступ к юниксовым радостям жизни, которые на винде или недоступны (например, нормальный терминал) или достигаются с трудом) - то получится как раз оно. Скажем, пост будет об "операционке".

Сразу хочу сказать, что я не претендую на экспертность. Наоборот, прошу моих более опытных коллег, например, уважаемых sorhed и lionet комментировать и поправлять меня там, где я чего-то не догоняю. Узнавать что-то новое мне всегда в радость!

Read more...Collapse )

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

Nov. 6th, 2012

09:33 am - Насчет сложности Скалы и причем здесь макросы

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

Я не буду здесь подробно останавливаться на SIP-18 (Скала 2.10), который прячет за прагмами некоторые из фич Скалы 2.9, включая имплисит конверсии. Также только мельком упомяну про DOT, который заменяет экзистенциальные типы и типы высших порядков на симпатичную и гораздо более простую концепцию. Ну и раз шел разговор о xml-литералах, надо сказать, что многие у нас в команде уже настроены их выкинуть. Как можно видеть, уже прямо сейчас идет неиллюзорная работа по упрощению языка.

***

Но это ладно. Что меня действительно удивляет это отношение к макросам как к игрушке для психов. Мне прямо стыдно это упоминать в надцатый раз, но макросы в Скале и макросы в плюсах это совершенно разные вещи. На эту тему предлагаю пролистать наш туториал: http://scalamacros.org/documentation/gettingstarted.html.

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

Что я имею ввиду. Берется ядро Скалы ака DOT (вот ссылка сейчас будет реально для психов: https://github.com/namin/dot). В ядре находятся только трейты, абстрактные типы и path-dependent типы - по сути, все то, что нужно для кейк-паттерна. Остальная пачка фич реализуется на макросах при помощи дешугаринга в DOT (само собой, это идиллия, реальность будет сложнее, но здесь мы просто обсуждаем идею).

В итоге при желании можно писать на минималистичном языке, который сохраняет сущность Скалы (а сущность эта заключается в скрещивании ФП с ООП). При сильном желании можно написать что-то вроде import language.lazyVals или import language.caseClasses и радоваться жизни.

Tags:

Nov. 5th, 2012

05:28 pm - Темы для курсовых и дипломов на основе макросов в Скале

Мы уже совсем близко к финальному релизу Скалы 2.10, который вместе с другими интересными фичами будет включать в себя и макросы: http://scalamacros.org.

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

***

Подробно предлагаемые темы описаны на сайте проекта: http://scalamacros.org/news/2012/11/05/research-projects.html, а в этом посте я вкратце прорезюмирую некоторые из них. Итак вот список:
* Optimizing collections with macros
* Using reified types for specialization
* Macro-based class system
* Macro-based continuations
* Multi-stage programming with macros
* Interpreter for abstract syntax trees

Первая тема отлично подойдет для тех, кто хочет познакомиться с идеей макросов и заодно оставить видимый след в стандартной библиотеке Скалы. Высокоуровневые методы коллекций вроде map или filter очень удобны, но компилируются в не самый быстрый код. Последние несколько лет мы с переменным успехом пытались решить эту проблему, но с помощью макросов этот вопрос можно закрыть раз и навсгеда.

Далее у нас есть несколько проектов, которые реализуют языковые фичи в виде макросов. Замечательным свойством макросов является то, что они упрощают язык программирования, предоставляя возможность вынести фичи языка из ядра в стандартную библиотеку. Предлагается на своем опыте опробовать эту идеологию, а заодно и потенциально поучаствовать в дизайне нового ядра Скалы.

Следующий проект (multi-stage programming with macros) использует возможности макросов для создания доменно-специфических языков. У нас в лаборатории есть интересное направление, связанное с созданием параллельных и не очень DSL с помощью LMS. Я восхищен этой технологией: контролем, который она предоставляет разработчику языков, и прозрачностью для пользователей. Но у текущей реализации есть один недостаток - количество языковой магии под капотом зашкаливает, на что часто жалуются разработчики. С помощью макросов этот недостаток можно полностью устранить.

Завершает парад интерпретатор нового поколения для Скалы. Это хороший пример маленького изолированного проекта, который может интересно выстрелить. Наш текущий интерпретатор просто-напросто запускает компилятор в памяти, что делает его весьма тяжеловесным и не всегда применимым. Заманчивой альтернативой является легкий модуль, который будет производить интерпретацию на лету. Непосредственное применение такого модуля - исполнение макросов внутри компилятора.

***

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

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

Наконец хочу пожелать не пугаться слов "разработка новых фич для Скалы" и "сотрудничество с EPFL". С нами весело и интересно :)

Tags: ,

Navigate: (Previous 10 Entries | Next 10 Entries)