Чукча, всмысле автор, конечно не читатель, но я б все равно рекомендовал, прежде чем писать новый модный язык, ознакомиться с языками последних лет 40. Т.е это от лиспов, хаскелей и эрлангов до форта. И с концепциями, в них представленными. Потом много много подумать. И только потом что то писать, если это делать не расхочется.
Да и вообще, почти все ЯП неплохо укладываются в БНФ (иначе были бы проблемы с парсингом и компиляцией)
Дык и есть проблемы :) И их руками и решают.
Вроде бы есть (планирую попробовать чуть позже) разные «оптимизированные» парсеры общего назначения.
Если знать матчасть, то написать руками простейший парсер куда проще, чем бодаться с генераторами вроде ANTLR/etc, что вы вобщем-то, неплохо показали в своей статье :)
LL(k), которые всегда в принципе можно свести к LL(1), на самом деле всегда лучше писать руками или парсер-комбинаторами(ну тот же калькулятор, описанный). Да, надо знать матчасть. Но, при использовании описанных инструментов, даже PEG, на самом деле нужно знать еще больше матчасти :)
Также, имхо, нужно было бы упомянуть, что до стадии парсера, желательно иметь стадию лексера (которую можно и на регулярках заимплементить) — оно такое дело значительно всё упрощает. Кроме PEG, возможно, в случае реализации в виде packrat-парсера.
Ну и кстати, в случае реальных языков программирования, один хрен придется почти всё руками делать — почти у всех языков грамматики контекстно-зависимые. (даже у какого-нибудь лиспа — backquote синтаксис, например)
А так, хорошая статья, жду продолжения. Интересно было бы про GLR подробно почитать — информации про них вообще очень мало в интернете, а на русском вообще ноль.
Собственно, похмелье — отравление ацетальдегидом, продуктом переработки спирта в печени. Проявляется слабостью, тошнотой и другими вегетативными, в основном, симптомами.
И абстиненция — гораздо более неприятная вещь, являющаяся следствием физической зависимости от этанола. Проявляется в основном психологическими эффектами — нервозность, раздражительность, бессонница, в отдельных случаях — галлюцинации; сильные проявления абстиненции в народе еще зовутся белочкой.
От чего конкретно помогает чудо-средство, там не написано?
Я так понимаю, это некоторые криворукие индивидуумы для логов используют. Вопрос правда возникает — а что мешает логировать на уровне приложение? И тут снова возвращаемся к вопросу о кривых руках.
Юзкейс распишите-ка. А то «автономные транзакции» сами по себе попахивают, мягко говоря, кривыми руками и говнокодом. В PostgreSQL и например в MSSQL, с которыми я больше всего работал, их сделать в принципе можно, через dblink(и аналог в mssql), но как-то ни разу не слышал чтобы приходилось. Может в консерватории что-то подправить? Вы в принципе, кстати, вообще, понимаете, зачем нужны транзакции то, если возникает желание их обходить?
Angular, при всех его проблемах — просто-напросто более-менее юзабелен, и позволяет быстро писать красивый UI, в отличие от тонн jQuery-ада или вороха несовместимых между собой наколеночных фреймворков.
Некоторые виды использования метаобъектного протокола могут вносить достаточно значительные издержки, но при этом же его можно использовать и для повышения производительности стандартной CLOS(один из вариантов того, что можно сделать с его помощью — собственно структуры (structure-object) стандартного CL, которые сильно лучше по производительности чем standard-object).
При этом, если сравнивать со скриптовыми языками вроде Python, или же, скажем, с языками с несовершенными на данный момент компиляторами(вроде Go), то производительность CLOS и MOP в топовых реализациях CL(том же SBCL), дает им огромную фору.
Хороший цикл статей. Единственное замечание — не надо валидировать email регексом. Никогда. Приведенный, в частности, не пропустит доменное имя без точек.
Это проблемы C++ — нет ABI, нет стандартизированного name mangling, и т.п.
Т.к. мы, простые смертные, не влияем на принятие стандарта C++, то мы используем к примеру COM. Моя позиция по этому вопросу такая — COM конечно не самое удобное в мире изобретение, особенно если смотреть из C++, но оно, в отличие от стандартного C++ — изобретение работающее, а это решающий фактор, уж извините.
Манифесты на самом деле досточно удобны. Мне кажется, лучше пусть будет куча разных dll в специальном кеше и одна псевдо-dll в условном system32 или %programfiles%/%App%, чем та же куча в разных местах и с разными именами.
Кроме версий dll, они могут версионировать COM-компоненты.
Могут указывать где искать компоненты/dll, и т.п.
Ну и вообще, формат расширяемый, т.к. xml, и поэтому через них можно много чем управлять. Например, уровнями integrity(aka MAC, aka UAC).
Не отрицаю, что с первого взгляда они кажутся избыточными и переусложненными. Но, манифесты действительно решают проблемы, которые на других системах не решены никак.
Вы даже выделить объект в одной библиотеке, а потом удалить в другой не можете, какие уж тут шаблоны.
Выделять память нужно стандартным HeapAlloc(а потом делать placement new), и/или же предоставлять функции для удаления объекта из библиотеки. Т.е. эта проблема надуманная, т.к. создавать в одной библиотеке объект а потом удалять его как попало — это дурной тон и ССЗБ.
Во-вторых, специально для C++, который может быть сам с собой не совместим даже в случае разных минорных версий компилятора — в MS придумали COM, в котором и ABI, и менеджмент памяти стандартизированный, и т.д.
Насколько я знаю, в Windows проблема разных библиотек но одного символа — вообще не стоит.
Дело в том, что dll не позволяет undefined символы, как линуксе. Т.е. линковка идет при компиляции, и зависимости намертво пришиваются.
Далее, при загрузке dll, в зависимых от нее приложениях и модулях патчатся стабы в таблице импорта(для функций например — добавляется инструкция прыжка на адрес в области памяти занимаемой образом конкретной заданной dll).
Т.е. символ импортированный из конкретного модуля всегда будет указывать на символ в этом конкретном модуле.
Далее, чтобы избежать версионирования имен dll — как раз таки можно использовать SxS, он для этого и предназначен.
Для этого пишется manifest, который либо складывается в секцию .rsrc у dll/exe, либо же кладется рядом с приложением/dll в виде файла ${имя модуля включая суффикс exe/dll}.manifest
В этом манифесте прописываются зависимости.
Т.е. все намного проще и удобнее, чем в других ОС, на самом деле.
Нет, SBCL НЕ интерпретатор. Еще раз. Это компилятор. (хотя в этой реализации CL и есть интерпретатор, он отключен по дефолту).
Функция интерпретатора в том чтобы выполнять программу по ходу разбора текста. А SBCL, даже в eval, сначала всё компилирует. Это компилятор и точка. Выполняются — машкоды, и процессором, а не самим SBCL.
Семантика лиспа, связанная с генерацией кода на лету, называется не интерпретация, а «метациклический вычислитель».
Я понимаю желание оправдаться, но не надо запутывать читателей.
Вышесказанное относится и к стилю кода.
Писать на лиспе, расставляя скобки как на Си — нельзя. Это очень плохой стиль. Это надо понять, и не надо вести себя как первокурсник, который противится форматированию кода лесенкой и пишет без отступов.
Язык может много что позволять, но это не значит, что это надо делать(Си, например, позволяет разыменовывать невалидные указатели и не освобождать динамическую память)
Я функтором аппликативным
Eval, eval, eval, eval
Да практически из определения. Сводится оно с помощью левой факторизации.
www.egtry.com/compiler/ll/left_factoring
Нет, это оооочень упрощенная грамматика простейших S-выражений, а не какого-либо из лиспов :)
trevorjim.com/python-is-not-context-free
Вкратце, у Питона лексер на себя слишком много берет. В целом, у него КЗ-грамматика.
Дык и есть проблемы :) И их руками и решают.
Если знать матчасть, то написать руками простейший парсер куда проще, чем бодаться с генераторами вроде ANTLR/etc, что вы вобщем-то, неплохо показали в своей статье :)
Также, имхо, нужно было бы упомянуть, что до стадии парсера, желательно иметь стадию лексера (которую можно и на регулярках заимплементить) — оно такое дело значительно всё упрощает. Кроме PEG, возможно, в случае реализации в виде packrat-парсера.
Ну и кстати, в случае реальных языков программирования, один хрен придется почти всё руками делать — почти у всех языков грамматики контекстно-зависимые. (даже у какого-нибудь лиспа — backquote синтаксис, например)
А так, хорошая статья, жду продолжения. Интересно было бы про GLR подробно почитать — информации про них вообще очень мало в интернете, а на русском вообще ноль.
Собственно, похмелье — отравление ацетальдегидом, продуктом переработки спирта в печени. Проявляется слабостью, тошнотой и другими вегетативными, в основном, симптомами.
И абстиненция — гораздо более неприятная вещь, являющаяся следствием физической зависимости от этанола. Проявляется в основном психологическими эффектами — нервозность, раздражительность, бессонница, в отдельных случаях — галлюцинации; сильные проявления абстиненции в народе еще зовутся белочкой.
От чего конкретно помогает чудо-средство, там не написано?
При этом, если сравнивать со скриптовыми языками вроде Python, или же, скажем, с языками с несовершенными на данный момент компиляторами(вроде Go), то производительность CLOS и MOP в топовых реализациях CL(том же SBCL), дает им огромную фору.
Т.к. мы, простые смертные, не влияем на принятие стандарта C++, то мы используем к примеру COM. Моя позиция по этому вопросу такая — COM конечно не самое удобное в мире изобретение, особенно если смотреть из C++, но оно, в отличие от стандартного C++ — изобретение работающее, а это решающий фактор, уж извините.
Кроме версий dll, они могут версионировать COM-компоненты.
Могут указывать где искать компоненты/dll, и т.п.
Ну и вообще, формат расширяемый, т.к. xml, и поэтому через них можно много чем управлять. Например, уровнями integrity(aka MAC, aka UAC).
Не отрицаю, что с первого взгляда они кажутся избыточными и переусложненными. Но, манифесты действительно решают проблемы, которые на других системах не решены никак.
Выделять память нужно стандартным HeapAlloc(а потом делать placement new), и/или же предоставлять функции для удаления объекта из библиотеки. Т.е. эта проблема надуманная, т.к. создавать в одной библиотеке объект а потом удалять его как попало — это дурной тон и ССЗБ.
Во-вторых, специально для C++, который может быть сам с собой не совместим даже в случае разных минорных версий компилятора — в MS придумали COM, в котором и ABI, и менеджмент памяти стандартизированный, и т.д.
Дело в том, что dll не позволяет undefined символы, как линуксе. Т.е. линковка идет при компиляции, и зависимости намертво пришиваются.
Далее, при загрузке dll, в зависимых от нее приложениях и модулях патчатся стабы в таблице импорта(для функций например — добавляется инструкция прыжка на адрес в области памяти занимаемой образом конкретной заданной dll).
Т.е. символ импортированный из конкретного модуля всегда будет указывать на символ в этом конкретном модуле.
Далее, чтобы избежать версионирования имен dll — как раз таки можно использовать SxS, он для этого и предназначен.
Для этого пишется manifest, который либо складывается в секцию .rsrc у dll/exe, либо же кладется рядом с приложением/dll в виде файла ${имя модуля включая суффикс exe/dll}.manifest
В этом манифесте прописываются зависимости.
Т.е. все намного проще и удобнее, чем в других ОС, на самом деле.
Функция интерпретатора в том чтобы выполнять программу по ходу разбора текста. А SBCL, даже в eval, сначала всё компилирует. Это компилятор и точка. Выполняются — машкоды, и процессором, а не самим SBCL.
Семантика лиспа, связанная с генерацией кода на лету, называется не интерпретация, а «метациклический вычислитель».
Я понимаю желание оправдаться, но не надо запутывать читателей.
Вышесказанное относится и к стилю кода.
Писать на лиспе, расставляя скобки как на Си — нельзя. Это очень плохой стиль. Это надо понять, и не надо вести себя как первокурсник, который противится форматированию кода лесенкой и пишет без отступов.
Язык может много что позволять, но это не значит, что это надо делать(Си, например, позволяет разыменовывать невалидные указатели и не освобождать динамическую память)
Правда заключается в следющем:
Можно было хотя бы основы то выучить, прежде чем писать статью на популярный ресурс?
Дальше не читал, и другим не советую. По крайней мере до тех пор, пока автор не подтянет знания.