Вложенные handler-bind/handler-case :)
Несколько блоков обработчиков, даже в обычных try-catch, это просто синтаксический сахар.
В принципе, несложно и в данную реализацию его добавить.
Но вообще, само описание системы условий/ситуаций CL, пожалуй, стоит отдельной статьи. Тут я про реализацию, в основном, которой, кстати, сам пользуюсь постоянно, в отсутствии возможности писать на CL.
COM это в первую очередь бинарный стандарт для межплатформенного(или если выражаться прямее — межъязыкового, в плане языков программирования), межпроцессного и даже сетевого(DCOM) взаимодействия.
В JS и VB нет «хеадеров», в C# их тоже нет, и уж точно их нет в каком-нибудь Common Lisp. Модульность во всех трех реализована совершенно по-разному. Зато и там и там и в третьем, и даже в четвертом, есть более-менее похожее ООП.
Кроме того, COM это некоторая такая попытка пофиксить недостатки C++ — а именно: отсутствие ABI, управление памятью, модель ООП и отсутствие reflection.
Грамматики бывают разные, но если говорить про контекстно-свободные, то LL(k) грамматики это такие, для которых можно построить LL(k) анализатор, то есть парсер, разбирающий токены слева направо(первая L) сверху вних и строящий левый вывод(вторая L), заглядывающий вперед на k токенов, и, соответственно, работающий за линейное время и не требующий бэктрекинга. LL(1) парсер это, например, рекурсивно нисходящий предиктивный парсер, или аналогичный автомат со стеком.
LL(1) это очень узкий класс грамматик, но некоторые языки разрабатывались специально чтобы их можно было разобрать LL(1), например паскаль.
LL(1) грамматика не допускает левой рекурсии, так как это означает бесконечный цикл в анализаторе, и, кроме того, к правильной LL(1) грамматике должен быть применен left-factoring.
>Это, наверное, самый сложный компонент нашего компилятора
В Real-World компиляторах, кстати, как правило — самый простой(не парсер конкретно, а вообще, часть, отвечающая за разбор).
Про грамматику надо было сказать. Грамматика, вроде бы, сводится к LL(1), значит надо было этот момент объяснить, переписать её соответствующим образом, и в коде сделать нормальный предикативный анализатор, а не какое-то его ad-hoc подобие, как сейчас.
Кстати, настоящие компиляторы выстраиванием AST занимаются довольно редко, и обычно генерируют код прямо в процессе разбора.
Обобщенные функции плюс комбинаторы методов.
И выглядело приятнее.
Несколько блоков обработчиков, даже в обычных try-catch, это просто синтаксический сахар.
В принципе, несложно и в данную реализацию его добавить.
в .NET 4 как раз ввели замечательный класс ThreadLocal<T>
Хорошее описание есть по ссылке на PCL ( lisper.ru/pcl/beyond-exception-handling-conditions-and-restarts ).
Надо было ее, наверное, повыше положить.
Но вообще, само описание системы условий/ситуаций CL, пожалуй, стоит отдельной статьи. Тут я про реализацию, в основном, которой, кстати, сам пользуюсь постоянно, в отсутствии возможности писать на CL.
В JS и VB нет «хеадеров», в C# их тоже нет, и уж точно их нет в каком-нибудь Common Lisp. Модульность во всех трех реализована совершенно по-разному. Зато и там и там и в третьем, и даже в четвертом, есть более-менее похожее ООП.
Кроме того, COM это некоторая такая попытка пофиксить недостатки C++ — а именно: отсутствие ABI, управление памятью, модель ООП и отсутствие reflection.
Грамматики бывают разные, но если говорить про контекстно-свободные, то LL(k) грамматики это такие, для которых можно построить LL(k) анализатор, то есть парсер, разбирающий токены слева направо(первая L) сверху вних и строящий левый вывод(вторая L), заглядывающий вперед на k токенов, и, соответственно, работающий за линейное время и не требующий бэктрекинга. LL(1) парсер это, например, рекурсивно нисходящий предиктивный парсер, или аналогичный автомат со стеком.
LL(1) это очень узкий класс грамматик, но некоторые языки разрабатывались специально чтобы их можно было разобрать LL(1), например паскаль.
LL(1) грамматика не допускает левой рекурсии, так как это означает бесконечный цикл в анализаторе, и, кроме того, к правильной LL(1) грамматике должен быть применен left-factoring.
Пример, LL(1) для классических S-выражений:
expression -> STRING | SYMBOL | NUMBER | QUOTE expression | LEFT_PAREN parenExpression parenExpression -> RIGHT_PAREN | expression restParenExpression restParenExpression -> RIGHT_PAREN | DOT expression RIGHT_PAREN | expression restParenExpression«предиктивный», всмысле
в 3 ночи голова не работает :)
Вобщем, нужно обязательно установить переменную среды HOME в %users%/%username%
www.gnu.org/s/libtool/manual/emacs/Windows-HOME.html
В Real-World компиляторах, кстати, как правило — самый простой(не парсер конкретно, а вообще, часть, отвечающая за разбор).
Про грамматику надо было сказать. Грамматика, вроде бы, сводится к LL(1), значит надо было этот момент объяснить, переписать её соответствующим образом, и в коде сделать нормальный предикативный анализатор, а не какое-то его ad-hoc подобие, как сейчас.
Кстати, настоящие компиляторы выстраиванием AST занимаются довольно редко, и обычно генерируют код прямо в процессе разбора.
По мне так не нужны нафиг.
Просто ты мне это уже раза два писал в juick, и даже вроде в жж.
Выпей транквилизаторов каких чтои, не знаю.