Pull to refresh
48
0
Дмитрий Игнатьев @love5an

User

Чукча, всмысле автор, конечно не читатель, но я б все равно рекомендовал, прежде чем писать новый модный язык, ознакомиться с языками последних лет 40. Т.е это от лиспов, хаскелей и эрлангов до форта. И с концепциями, в них представленными. Потом много много подумать. И только потом что то писать, если это делать не расхочется.
… Кембриджским батоном лямбдоты.
Я функтором аппликативным
Eval, eval, eval, eval
«Золотые, бессмертные строки Виталия Светославовича Луговского как нельзя лучше подходят к моменту»
Таки с чего вы решили, что LL(k) сводимо к LL(1)?

Да практически из определения. Сводится оно с помощью левой факторизации.
www.egtry.com/compiler/ll/left_factoring

cuiwww.unige.ch/isi/bnf/LISP/BNFlisp.html Бнф-грамматика для Lisp.

Нет, это оооочень упрощенная грамматика простейших S-выражений, а не какого-либо из лиспов :)

Грамматика для того же питона так же в открытом доступе и, как я понимаю, используется при компиляции языка.

trevorjim.com/python-is-not-context-free
Вкратце, у Питона лексер на себя слишком много берет. В целом, у него КЗ-грамматика.

Да и вообще, почти все ЯП неплохо укладываются в БНФ (иначе были бы проблемы с парсингом и компиляцией)

Дык и есть проблемы :) И их руками и решают.

Вроде бы есть (планирую попробовать чуть позже) разные «оптимизированные» парсеры общего назначения.

Если знать матчасть, то написать руками простейший парсер куда проще, чем бодаться с генераторами вроде 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.

Семантика лиспа, связанная с генерацией кода на лету, называется не интерпретация, а «метациклический вычислитель».

Я понимаю желание оправдаться, но не надо запутывать читателей.

Вышесказанное относится и к стилю кода.
Писать на лиспе, расставляя скобки как на Си — нельзя. Это очень плохой стиль. Это надо понять, и не надо вести себя как первокурсник, который противится форматированию кода лесенкой и пишет без отступов.

Язык может много что позволять, но это не значит, что это надо делать(Си, например, позволяет разыменовывать невалидные указатели и не освобождать динамическую память)
Увидел две страшных неправды в тексте, которые отбили всё желание читать:

  1. «SBCL — интерпретатор»
  2. Форматирование!!!111


Правда заключается в следющем:

  1. SBCL — компилятор! Ком-пи-ля-тор. В машинные коды!
  2. Лисп так форматировать нельзя!!!11 Нель-зя!!1 Закрывающие скобки нужно оставлять на той же строчке!!11


Можно было хотя бы основы то выучить, прежде чем писать статью на популярный ресурс?

Дальше не читал, и другим не советую. По крайней мере до тех пор, пока автор не подтянет знания.

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity