История изменений
Исправление den73, (текущая версия) :
Хаха, оказывается есть ещё одна проблема, уже не связанная с IDE. Я борюсь за то, чтобы можно было решать конфликты имён. Допустим, есть пакет П и в нём символ З, именующий запись с полем Ж. И есть функция с именем Ж. И вот я хочу создать литерал (константу) этой записи, у которой поле Ж равно символу Ж.
Определение записи порождает своё простр-во имён, в котором живут имена полей, а именно Ч.З. Имя поле будет Ч.З:Ж Имя функции - Ч:Ж. Т.е. это два разных символа.
Внутри литерала пр-ва имён будут временно сливаться с автоматическим устранением конфликтующих символов, как в конструкции select ... в SQL. Т.е., внутри определения записи мы не увидим ни одной Ж.
Ясно, что до этого места уже никто не дочитал, разве кроме Монка, но и ладно.
Итого получаем следующий код:
в-пакете :П
опр.функ Ж ()
кнф
переменная ю
= З П.З:Ж П:Ж кнЗ
глобальная да
кнп
В чём здесь проблема с порядком определений? Что если мы переставим местами определения функции и переменной, то у нас при первом чтении не будет символа П:Ж, а значит, не будет и конфликта. В итоге мы можем написать вот так:
в-пакете :П
переменная ю
= З Ж Ж кнЗ
глобальная да
кнп
опр.функ Ж ()
кнф
И не получим никакого предупреждения от лексера при первом чтении. При втором чтении Ж исчезнут и мы получим ошибку чтения. Очень нехорошо.
Эта проблема скорее касается символов, а не функций и скорее относится к лиспообразным языкам с горячей заменой кода.
И тут я вспоминаю ещё про одну, более страшную проблему. В лиспе мы можем сослаться на функцию или на макрос, определённый в следующем файле. В динамической разработке это прокатывает, но при полной пересборке получается криво - макрос не расширяется, или мы можем вызвать функцию до того, как она будет определена.
В общем, пока мы потребуем деклараций вперёд, а там может быть и отменим.
Исходная версия den73, :
Хаха, оказывается есть ещё одна проблема, уже не связанная с IDE. Я борюсь за то, чтобы можно было решать конфликты имён. Допустим, есть пакет П и в нём символ З, именующий запись с полем Ж. И есть функция с именем Ж. И вот я хочу создать литерал (константу) этой записи, у которой поле Ж равно символу Ж.
Определение записи порождает своё простр-во имён, в котором живут имена полей, а именно Ч.З. Имя поле будет Ч.З:Ж Имя функции - Ч:Ж. Т.е. это два разных символа.
Внутри литерала пр-ва имён будут временно сливаться с автоматическим устранением конфликтующих символов, как в конструкции select ... в SQL. Т.е., внутри определения записи мы не увидим ни одной Ж.
Ясно, что до этого места уже никто не дочитал, разве кроме Монка, но и ладно.
Итого получаем следующий код:
в-пакете :П
опр.функ Ж ()
кнф
переменная ю
= З П.З:Ж П:Ж кнЗ
глобальная да
кнп
В чём здесь проблема с порядком определений? Что если мы переставим местами определения функции и переменной, то у нас при первом чтении не будет символа П:Ж, а значит, не будет и конфликта. В итоге мы можем написать вот так:
в-пакете :П
переменная ю
= З Ж Ж кнЗ
глобальная да
кнп
опр.функ Ж ()
кнф
И не получим никакого предупреждения от лексера при первом чтении. При втором чтении Ж исчезнут и мы получим ошибку чтения. Очень нехорошо.
Эта проблема скорее касается символов, а не функций и скорее относится к лиспообразным языкам с горячей заменой кода.
И тут я вспоминаю ещё про одну, более страшную проблему. В лиспе мы можем сослаться на функцию или на макрос, определённый в следующем файле. В динамической разработке это прокатывает, но при сборке получается криво - макрос не расширяется. Может получиться, что мы успеем вызвать функцию до того, как она будет определена.
В общем, пока мы потребуем деклараций вперёд, а там может быть и отменим.