История изменений

по-моему, у вас с Робертом подход разный

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

Поэтому у него просто неправильный подход, во всяком случае, по тем словам, которые я вижу.

special-purpose implementation of the Common Lisp read

There can be three different update operations: • Modify. The line has been modified. • Insert. A new line has been inserted. • Delete. An existing line has been deleted.

Достаточно октрыть хотя бы этот форум, в нём форум комментария и убедиться, что всё по-другому. Учитывается не только состояние буфера, а и история его изменения. И это не сводится к кешированию. Пока я печатал слово «кешировани», оно было некорректным, но браузер подчеркнул мне его только тогда, когда я поставил пробел после этого слова и стало ясно, что больше букв в это слово не поступит. Если я зашёл в это слово снова и хожу по нему стрелками, оно остаётся подчёркнутым. Но как только я нажал на del или на какую-то букву, браузер понял, что я начал менять слово, и стёр красное подчёркивание. Т.е. браузер следит за моим поведением и помнит, что я делал только что.

Функция read принципиально на это неспособна, поскольку она не знает, нажал ли я только что букву, backspace или стрелку. В ней нет соответствующего контекста - он есть только в редакторе, но не в состоянии буфера.

С этой проблемой мы тоже столкнулись, когда делали IDE, и в каком-то виде её решили. С этой же проблемой связана возможность автодополнения.

Допустим, я напиал:

(defu

В Hemlock есть как минимум три механизма (и три эрзац-ридера лиспа). Первый отвечает за раскраску ключевых слов. Он похож на то, что пишет Роберт - инкрементный (упрощённый) ридер лиспа на базе КА, единицей операции является строка - кешируется состояние чтения в начале каждой строки. Этот ридер неадекватно прост, годится только для лексического анализа.

Другой - для подсветки парных скобок. Не помню, как работает. Третий - для автодополнения и определения текущего символа под курсором. Он анализирует окрестность точки ввода и пытается выкусить из неё символ. Нужно заметить, что синтаксис Лиспа не позволяет решить даже эту задачу! И ещё одна вещь - оказывается, не всегда нужно решать эту задачу. Например, может хотеться, чтобы автодополнение и особенно переход к определению работали бы внутри комментариев, чтобы можно было написать в докстроке «см. также ДРУГОЙ-СИМВОЛ» и можно было бы на него скакнуть. Если определять символы ридером лиспа, то это работать не будет. А hemlock-овский кривой механизм работает. Зато он не сработает, если символ квоченный (не сможет понять, где у него края). На этот случай мы сделали отдельный механизм - в нашей среде можно выделить любой кусок текста и сказать - это символ, перейди к его определению.

Вот сколько подводных камней и тонкостей в задаче создания IDE. Она не может быть решена какой-то одной красивой идеей.

Сначала мы сгоряча взялись делать из трёх ридеров один. В итоге выяснилось, что это и нельзя, и не нужно. Застряли посередине, я даже не помню, чем дело кончилось.

Во всяком случае, в синтаксисе Яра было предусмотрено несколько фишек, чтобы обойти разные грабли, которые есть в синтаксисе лиспа и неустранимы. Это, наверное, наболее ценный результат нашей работы. Но он никому не нужен :) А если кому-то нужен, то хрен я его даром отдам, Монк пусть сам думает :)

по-моему, у вас с Робертом подход разный

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

Поэтому у него просто неправильный подход, во всяком случае, по тем словам, которые я вижу.

special-purpose implementation of the Common Lisp read

There can be three different update operations: • Modify. The line has been modified. • Insert. A new line has been inserted. • Delete. An existing line has been deleted.

Достаточно октрыть хотя бы этот форум, в нём форум комментария и убедиться, что всё по-другому. Учитывается не только состояние буфера, а и история его изменения. И это не сводится к кешированию. Пока я печатал слово «кешировани», оно было некорректным, но браузер подчеркнул мне его только тогда, когда я поставил пробел после этого слова и стало ясно, что больше букв в это слово не поступит. Если я зашёл в это слово снова и хожу по нему стрелками, оно остаётся подчёркнутым. Но как только я нажал на del или на какую-то букву, браузер понял, что я начал менять слово, и стёр красное подчёркивание. Т.е. браузер следит за моим поведением и помнит, что я делал только что.

Функция read принципиально на это неспособна, поскольку она не знает, нажал ли я только что букву, backspace или стрелку. В ней нет соответствующего контекста - он есть только в редакторе, но не в состоянии буфера.

С этой проблемой мы тоже столкнулись, когда делали IDE, и в каком-то виде её решили. С этой же проблемой связана возможность автодополнения.

Допустим, я напиал:

(defu

В Hemlock есть как минимум три механизма (и три эрзац-ридера лиспа). Первый отвечает за раскраску ключевых слов. Он похож на то, что пишет Роберт - инкрементный (упрощённый) ридер лиспа на базе КА, единицей операции является строка - кешируется состояние чтения в начале каждой строки. Этот ридер неадекватно прост, годится только для лексического анализа.

Другой - для подсветки парных скобок. Не помню, как работает. Третий - для автодополнения и определения текущего символа под курсором. Он анализирует окрестность точки ввода и пытается выкусить из неё символ. Нужно заметить, что синтаксис Лиспа не позволяет решить даже эту задачу! И ещё одна вещь - оказывается, не всегда нужно решать эту задачу. Например, может хотеться, чтобы автодополнение и особенно переход к определению работали бы внутри комментариев, чтобы можно было написать в докстроке «см. также ДРУГОЙ-СИМВОЛ» и можно было бы на него скакнуть. Если определять символы ридером лиспа, то это работать не будет. А hemlock-овский кривой механизм работает. Зато он не сработает, если символ квоченный (не сможет понять, где у него края). На этот случай мы сделали отдельный механизм - в нашей среде можно выделить любой кусок текста и сказать - это символ, перейди к его определению.

Вот сколько подводных камней и тонкостей в задаче создания IDE. Она не может быть решена какой-то одной красивой идеей.

Сначала мы сгоряча взялись делать из трёх ридеров один. В итоге выяснилось, что это и нельзя, и не нужно. Застряли посередине, я даже не помню, чем дело кончилось.

Во всяком случае, в синтаксисе Яра было предусмотрено несколько фишек, чтобы обойти разные грабли, которые есть в синтаксисе лиспа и неустранимы. Это, наверное, наболее ценный результат нашей работы. Но он никому не нужен :) А если кому-то нужен, то хрен я его даром отдам, Монк пусть сам думает :)