LINUX.ORG.RU

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

Исправление MOPKOBKA, (текущая версия) :

что делать если список начнет изменять функция которая не знает о твоей схеме

Для этого есть ООП. Что будет если в Си по указателю пытаться обращаться за пределы массива? Проблема не уникальная для ЛИСПа.

В С принято передавать размер массива, если не числом, то хотя бы размером других аргументов как в strcpy. А в Lisp я не видел функций, в которые можно передать текущий конец, и получить его после модификации. Для простейших задач, придется откинуть весь код чужой.

И где в твоём коде cons?

Нету, в том и суть.

Почему это?

Потому что cons медленные? Я это уже наглядно продемонстрировал. Что ты там собрался «нормально писать», если почти все требуемые операции требуют прохода по cons?

Ну а вообще в ЛИСПе есть и массивы и хэши. ЯННП, в чём претензия-то?

1) Почему бы не уйти от cons подальше, как сделано в Clojure, 2) Почему они такие неоптимизированные, зачем отдельно массивы когда можно было бы под капотом превращать cons в массивы?

Исходная версия MOPKOBKA, :

что делать если список начнет изменять функция которая не знает о твоей схеме

Для этого есть ООП. Что будет если в Си по указателю пытаться обращаться за пределы массива? Проблема не уникальная для ЛИСПа.

В С принято передавать размер массива, если не числом, то хотя бы размером других аргументов как в strcpy. А в Lisp я не видел функций, в которые можно передать текущий конец, и получить его после модификации. Для простейших задач, придется откинуть весь код чужой.

И где в твоём коде cons?

Нету, в том и суть.

Почему это?

Потому что cons медленные? Я это уже наглядно продемонстрировал. Что ты там собрался «нормально писать», если почти все требуемые операции требуют прохода по cons?

Ну а вообще в ЛИСПе есть и массивы и хэши. ЯННП, в чём претензия-то?

1) Почему бы не уйти от cons подальше, как сделано в Clojure, 2) Почему они такие неоптимизированные.