Рубрика «абстрактное синтаксическое дерево»
Тёмная сторона использования полифиллов CSS
2017-04-10 в 10:45, admin, рубрики: css, dom, Houdini, абстрактное синтаксическое дерево, браузеры, полифиллы, Разработка веб-сайтовВ прошлом году я написал статью для Smashing Magazine о Houdini и назвал его «самым потрясающим проектом CSS, о котором вы никогда не слышали». В этой статье я объясню, что набор Houdini API позволит (среди прочего) расширить функции CSS через полифиллы таким способом, какой просто невозможен сегодня.
Хотя та статья была в целом хорошо принята, один и тот же вопрос постоянно задавали мне в письмах и твиттере. Основная суть вопроса:
Что такого сложного в полифиллах CSS? Я использую много полифиллов CSS, и они у меня нормально работают.
И я понял — конечно же, у людей возникают такие вопросы. Если вы никогда не пробовали сами написать полифилл CSS, то, вероятно, никогда не испытывали эту боль.
Читать полностью »
Как устроен парсер Python, и как втрое уменьшить потребление им памяти
2016-11-06 в 20:59, admin, рубрики: C, open source, python, абстрактное синтаксическое дерево, Компиляторы, оптимизация кода, потребление памяти, синтаксический анализЛюбой, кто изучал устройство языков программирования, примерно представляет, как они работают: парсер в соответствии с формальной грамматикой ЯП превращает входной текст в некоторое древовидное представление, с которой работают последующие этапы (семантический анализ, различные трансформации, и генерация кода).
В Python всё немного сложнее: парсеров два. Первый парсер руководствуется грамматикой, заданной в файле Grammar/Grammar в виде регулярных выражений (с не совсем обычным синтаксисом). По этой грамматике при помощи Parser/pgen во время компиляции python генерируется целый набор конечных автоматов, распознающих заданные регулярные выражения — по одному КА для каждого нетерминала. Формат получающегося набора КА описан в Include/grammar.h, а сами КА задаются в Python/graminit.c, в виде глобальной структуры _PyParser_Grammar. Терминальные символы определены в Include/token.h, и им соответствуют номера 0..56; номера нетерминалов начинаются с 256.
Проиллюстрировать работу первого парсера проще всего на примере.
Пусть у нас есть программа if 42: print("Hello world")Читать полностью »
Принципы быстрого Хаскеля под GHC
2013-03-05 в 8:21, admin, рубрики: ghc, haskell, LLVM, yarr, абстрактное синтаксическое дерево, высокая производительность, каррирование, Компиляторы, ленивые вычисления, метки: ghc, LLVM, yarr, абстрактное синтаксическое дерево, каррирование, ленивые вычисленияGHC (Glasgow Haskell Compiler) — стандартный компилятор Хаскеля. GHC — один из самых крутых компиляторов в мире, но к сожалению без дополнительных телодвижений скомпилированные им программы по скорости больше напоминают интерпретируемые, т. е. работают очень медленно. Однако если раскрыть весь потенциал компилятора, Хаскель приближается по производительности к аналогичному коду на C.
В этой статье я обобщаю опыт выжимания максимума из GHC при создании dataflow-фреймворка Yarr.
Читать полностью »
Yarr — dataflow-фреймворк (обработки изображений) на Хаскеле
2013-03-05 в 8:21, admin, рубрики: ghc, haskell, LLVM, repa, yarr, абстрактное синтаксическое дерево, конвейер, обобщённое программирование, обработка изображений, параллельное программирование, процессор, Эквализация, метки: ghc, LLVM, repa, yarr, абстрактное синтаксическое дерево, конвейер, обобщённое программирование, процессор, Эквализация -na-haskele.png "Yarr — dataflow фреймворк (обработки изображений) на Хаскеле")
Зондирование обстановки на Реддите показало, что едва ли хоть кто-то всерьез занимается обработкой изображений на Хаскеле, несмотря на то, что достаточно популярная библиотека Repa предполагает работу с изображениями как одно из основных приложений. Надеюсь, ситуацию сможет изменить библиотека Yarr (документация, гитхаб).
Я называю библиотеку dataflow-фреймворком, потому что она обобщена для обработки массивов (от одномерных до трехмерных) элементов любых типов, в том числе векторов чисел, например координат, комплексных чисел. Но основное предполагаемое применение — обработка двумерных массивов из векторов цветовых компонент, т. е. изображений. Фреймворк непосредственно не содержит алгоритмов обработки изображений, а предоставляет мощную инфраструктуру для их написания.
Читать полностью »