История изменений
Исправление MOPKOBKA, (текущая версия) :
что делать если список начнет изменять функция которая не знает о твоей схеме
Для этого есть ООП. Что будет если в Си по указателю пытаться обращаться за пределы массива? Проблема не уникальная для ЛИСПа.
В С принято передавать размер массива, если не числом, то хотя бы размером других аргументов как в strcpy. А в Lisp я не видел функций, в которые можно передать текущий конец, и получить его после модификации. Для простейших задач, придется откинуть весь код чужой.
И где в твоём коде cons?
Нету, в том и суть.
Почему это?
Потому что cons медленные? Я это уже наглядно продемонстрировал. Что ты там собрался «нормально писать», если почти все требуемые операции требуют прохода по cons?
Ну а вообще в ЛИСПе есть и массивы и хэши. ЯННП, в чём претензия-то?
1) Почему бы не уйти от cons подальше, как сделано в Clojure, 2) Почему они такие неоптимизированные, зачем отдельно массивы когда можно было бы под капотом превращать cons в массивы?
Исходная версия MOPKOBKA, :
что делать если список начнет изменять функция которая не знает о твоей схеме
Для этого есть ООП. Что будет если в Си по указателю пытаться обращаться за пределы массива? Проблема не уникальная для ЛИСПа.
В С принято передавать размер массива, если не числом, то хотя бы размером других аргументов как в strcpy. А в Lisp я не видел функций, в которые можно передать текущий конец, и получить его после модификации. Для простейших задач, придется откинуть весь код чужой.
И где в твоём коде cons?
Нету, в том и суть.
Почему это?
Потому что cons медленные? Я это уже наглядно продемонстрировал. Что ты там собрался «нормально писать», если почти все требуемые операции требуют прохода по cons?
Ну а вообще в ЛИСПе есть и массивы и хэши. ЯННП, в чём претензия-то?
1) Почему бы не уйти от cons подальше, как сделано в Clojure, 2) Почему они такие неоптимизированные.