Возврат значения из замыкания

почему этот код тупо виснет нах?

#include <stdio.h>
#include <stdlib.h>

struct list { int x; struct list *xs; };

void print(struct list *z)
{
    for (; z; z = z->xs)
        printf("%d ", z->x);
    puts("");
}

int main()
{
    struct list z0 = { 20, NULL }, z = { 10, &z0 };
    print(&z);
    z.xs = &z;
    print(&z);
}

Я полагаю, если формализовать это утверждение, то его можно будет доказать как теорему, да.

В реальности же они упираются в ограничения человеческого мозга.

а синтаксис лиспа не упирается. какие проблемы?

...первые месяц-два.

Этого должно хватить любому вменяемому человеку, чтобы все окончательно понять про лисп и больше к нему не притрагиваться.

Если же учесть, что синтаксис прост и хорошо определен,

А у brainfuck и unlambda он еще проще и еще лучше определен. И что?

я не считаю его техническим недостатком.

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

Кроме того, этот синтасис создает множество производных технических трудностей. Например, невозможность использования хоть немного умной IDE. Для понимания семантики кода IDE должна его целиком скомпилировать, и только тогда будет приличная подсветка синтаксиса, отступы, автокомплит, подсказки и тому подобное. Что, при наличии отсутствия вменяемой раздельной компиляции и вообще понятия «проекта» в говнолиспах оказывается задачей принципиально нерешаемой (да, и про slime я знаю, не надо мне лапшу на уши вешать).

то есть у нормальных людей и print не виснет

* (setf *print-circle*  t)
T
* (setq x (cons 1 2))
(1 . 2)
* x
(1 . 2)
* (setf (car x) x)
#1=(#1# . 2)

*print-circle* - стандартная вещь, если что.

Этого должно хватить любому вменяемому человеку, чтобы все окончательно понять про лисп и больше к нему не притрагиваться.

Вменяемому по твоему личному мнению, на которое ты имеешь полное право.

А у brainfuck и unlambda он еще проще и еще лучше определен. И что?

См. выше.

Кроме того, этот синтасис создает множество производных технических трудностей. Например, невозможность использования хоть немного умной IDE. Для понимания семантики кода IDE должна его целиком скомпилировать

Ха-ха. Это не проблема синтаксиса, а проблема динамической типизации.

Синтаксис, сделанный ради простоты компилятора, а не для удобства человека

Нет, он как раз сделан для удобства человека. Компилятору поебать, какой там будет синтаксис, а вот человеку на порядок проще писать макросы, если синтаксис у языка простой.

sb:loop - спецформа, то есть не рассахаривается ни во что.

Нет такой специальной формы, сырые циклы это tagbody/go, все остальные do/loop как раз сахар:

(sb-cltl2:macroexpand-all '(loop for i from 1 to 10 do (print i)))

(BLOCK NIL
  (LET ((I 1))
    (DECLARE (TYPE (AND REAL NUMBER) I))
    (TAGBODY
     SB-LOOP::NEXT-LOOP
      (IF (> I '10)
          (PROGN (GO SB-LOOP::END-LOOP))
          NIL)
      (PRINT I)
      (SETQ I (1+ I))
      (GO SB-LOOP::NEXT-LOOP)
     SB-LOOP::END-LOOP)))

в одном из лучших ОО-языков, в Обероне

лицоладонь.gif

Компилятору поебать, какой там будет синтаксис, а вот человеку на порядок проще писать макросы, если синтаксис у языка простой.

Человеку проще не писать макросы вообще. Поверь.

А вот ленивым и тупым разработчикам компилятора конечно же проще не реализовывать никакой сложной и полезной функциональности, а дать юзеру макросы и предложить допилить отсутствующее самостоятельно. Бред же!

Человеку проще не писать макросы вообще. Поверь.

Такое впечатление, что ты лиспер-ренегат. Что автоматически делает тебя невменяемым по твоему же критерию.

Вменяемому по твоему личному мнению, на которое ты имеешь полное право.

Запросто поменяю свое личное мнение, как только увижу хотя бы одного адекватного и грамотного фанбоя лиспа. Пока что все были полными отморозками.

Ха-ха. Это не проблема синтаксиса, а проблема динамической типизации.

С динамической типизацией еще как-то жить можно (для того же Javascript уже приличные IDE появляются). А вот с макросами (теми самыми, которые заменяют отсутствующий синтаксис) жить нельзя. IDE не может раскрывать макросы, не зная их определения. Да и дорого это слишком.

Что проще для IDE? Распарсить for ( ... ; ... ; ...) ... - или пытаться понять, что за херотень такая этот (LOOP ...), и не переопределил ли его придурок-юзер где-то в другом модуле?

Такое впечатление, что ты лиспер-ренегат.

Весь когда либо написанный мною на лиспе код присутствует в этом треде. Даже не поленился для этого в спек посмотреть, да.

А вот ленивым и тупым разработчикам компилятора конечно же проще не предоставить возможность реализовывать сложную и полезную функциональность самостоятельно, а дать юзеру лишь ту функциональность, которая понравилась самим разработчикам и заставить его ждать N лет выхода следующей версии компилятора/стандарта языка. Бред же!

FIXED.

С динамической типизацией еще как-то жить можно (для того же Javascript уже приличные IDE появляются)

Потому что деньги вливают.

Что проще для IDE? Распарсить for ( ... ; ... ; ...) ... - или пытаться понять, что за херотень такая этот (LOOP ...), и не переопределил ли его придурок-юзер где-то в другом модуле

Зависит. Если у среды есть халявный парсер, то проще распарсить LOOP.

IDE не может раскрывать макросы, не зная их определения

Почему она не знает их определения?

Оп, ага. Забыл, что в CL macroexpand не раскрывает форму полностью. Сам еще удивился, что не увидел goto, но подумал что просто в SBCL сделали специальный костыль.

...первые месяц-два. Если же учесть, что синтаксис прост и хорошо определен, я не считаю его техническим недостатком.

Более того, многие лисперы любят скобчатый синтаксис. Как пример, есть два похожих макроcа: старый loop и новый iter. В целом, у них идеи общие. Помимо расширяемости, макрос iter обладает огромным преимуществом: в нем больше скобок, и он не так выделяется на фоне остального лисповского кода. Многие предпочитают iter, хотя его нужно устанавливать отдельно, тогда как loop является частью стандарта - бери да пользуйся, ан нет.

Вообще, если лисперы не любили бы свои скобки, то давно бы использовали M-exps, которые появились довольно давно, но сейчас очень сложно их увидеть в современной литературе по лиспу.

Почему она не знает их определения?

А откуда она их узнает? Будет на каждый чих в правильном порядке парсить все исходные файлы проекта? Правильно понимая каждый (load ...)? Ну-ну.

Потому что деньги вливают.

И еще потому, что это технически реализуемо. В отличии от.

Зависит. Если у среды есть халявный парсер, то проще распарсить LOOP.

Ну и откуда оно узнает верное в текущем контексте определение LOOP?

Он просто не в курсе, как она может знать. Можно посоветовать посмотреть на тот же Typed Racket с online check - типизация происходит во время раскрытия макросов, но ошибки типизации выдаются на ходу, во время написания, как в любой иде (макросы на лету раскрываются «виртуально»).

К слову, при помощи этого можно даже управлять поведением ИДЕ (потенциально) - например вставлять «пустые» макросы (ни во что не раскрывающиеся) с конкретным нужным сайд-эффектом.

если лисперы не любили бы свои скобки, то давно бы использовали M-exps

Видел я эти M-exps. По читабельности лучше, но не намного.

А тебе действительно нужна какая-то функциональность, отличная от того, что есть в, например, Java 6? Честно-честно? И на фига тебе это надо?

Ну и откуда оно узнает верное в текущем контексте определение LOOP?

Оттуда же, откуда его узнает настоящий компилятор.

Еще б Wolfram Mathematica вспомнили (и лиспом обозвали бы).

А откуда она их узнает? Будет на каждый чих в правильном порядке парсить все исходные файлы проекта? Правильно понимая каждый (load ...)? Ну-ну.

Зачем все? Программа и так загружается вся полностью в рабочий образ, а измененные функции и макросы можно по-отдельности вкомпиливать по мере изменения.

А вот ленивым и тупым разработчикам компилятора конечно же проще не реализовывать никакой сложной и полезной функциональности, а дать юзеру макросы и предложить допилить отсутствующее самостоятельно. Бред же!

Разработчикам удобнее предусмотреть инструмент, который потом позволит легко и просто _им самим_ (а никаким не юзерам) допиливать различные фичи в виде библиотек, не делая обновлений рантайма и не ломая совместимость. Например, по этому же пути решли пойти и разработчики скалы.

То есть, на каждое изменение перекомпилируем весь проект? А фуфырка не лопнет?

А это и есть диалект лиспа, на все 100%.

Например, по этому же пути решли пойти и разработчики скалы.

Замечательный пример. Монстровый кривой говноязык, ненужный чуть более чем целиком.

То есть, на каждое изменение перекомпилируем весь проект?

Нет.

А фуфырка не лопнет?

Нет.

То есть, на каждое изменение перекомпилируем весь проект? А фуфырка не лопнет?

Зачем весь проект? Только то, что изменилось.

А тебе действительно нужна какая-то функциональность, отличная от того, что есть в, например, Java 6?

Да, нужна. Мне бы не помешал аналог with* из CL или Python или using из C# вместо try ... finally. Мне бы не помешали анонимные функции/блоки вместо анонимных классов. И много еще чего, позволяющего скрыть тонны ненужного кода за простыми макросами.

Зачем весь проект? Только то, что изменилось.

Как ты это определишь в языке с инкрементальной компиляцией? Все, что следует за изменившейся строкой, потенциально может потребовать перекомпиляции. А теперь, представь, что ты редактируешь самую первую строку в проекте на десять миллионов строк кода.

Ясно. Ты просто ленивый и не умеешь программировать. Нормальному кодеру функциональности java 6 более чем достаточно для эффективного и понятного решения абсолютно любых задач.

Видел я эти M-exps. По читабельности лучше, но не намного.

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

Ты не находишь, что читабельность - понятие исключительно субъективное

Нахожу. Более того, способность читать скобчатую нотацию вполне натаскивается.

большинство флеймов происходит от того, что субъективное у разных субъектов не совпадает, а это случается повсеместно :)

А еще я нахожу, что первое субъективное чувство от Лисп-кода у большинства людей - «епт, что за овсянка с обрезками ногтей» %)

А еще я нахожу, что первое субъективное чувство от Лисп-кода у большинства людей - «епт, да это же овсянка с обрезками ногтей» %)

Приходится согласиться. Но глупо выглядят те, кто раздувает эту тему.

Многие лисперы любят лисп таким, какой он есть. Они говорят: «Да, мы знаем, что лисп несовершенен. Поэтому отстаньте от нас, надоедливые и глупые тролли!»

Многие лисперы любят лисп таким, какой он есть.

Извращенцы. Как можно любить или ненавидеть инструмент?!?

Ясно. Ты просто ленивый и не умеешь программировать. Нормальному кодеру функциональности java 6 более чем достаточно для эффективного и понятного решения абсолютно любых задач.

Да. Конечно. Ему помогают вумные IDE, содержащие сотни шаблонов кода, вставляющих их за «Нормального Кодера», чтобы у него руки меньше уставали. И «Нормальный Кодер» должен не лениться забивать сотни строк кода там, где в других языках требуется десяток. Именно это отличает кодера от программиста — усердное долбление по клавишам.

Извращенцы. Как можно любить или ненавидеть инструмент?!?

Действительно. Как можно любить или не любить разную еду? Как можно любить или не любить заниматься спортом? Как можно любить или не любить каких-то людей? Как вообще можно что-то любить или ненавидеть?

Проблема втом, что ты подменяешь понятия. Другой проблемы тут нет.

Я их не подменяю. Скобочный синтаксис => контроль над AST позволяют более полно имплементнуть code-as-data и работать с ним с меньшим трудом.

Как ты это определишь в языке с инкрементальной компиляцией?

В лиспе символы, там оно по такому принципу работает:

int f() { return 1; }
int(*f_sym)() = f;

int g() { return f_sym(); }
int(*g_sym)() = g;

    printf("%d\n", g_sym()); // => 1
    f_sym = []() { return 2; };
    printf("%d\n", g_sym()); // => 2

так что можно создать новый код, связать с каким-то символом, весь остальной код автоматически будет понимать уже новый код, так как завязан не на конкретные адреса, а на символы.

Как ты это определишь в языке с инкрементальной компиляцией? Все, что следует за изменившейся строкой, потенциально может потребовать перекомпиляции.

При инкрементальной компиляции перекомпилировать нужно только изменившуюся строку (функцию с изменившейся строкой, если быть точным). И все, ни того что до нее ни того что после перекомпилировать не надо.

А еще я нахожу, что первое субъективное чувство от Лисп-кода у большинства людей - «епт, что за овсянка с обрезками ногтей» %)

Эффект утенка. Если бы первым языком учили лисп, то всех тянуло бы блевать от алголов.

Если бы первым языком учили лисп, то всех тянуло бы блевать от алголов.

Алгол, в отличие от Лиспа, разрабатывался так, чтобы напоминать естественный язык.

Ололо.

Изменившаяся строка: (defmacro LOOP ...)

Везде в последующем коде LOOP используется. Смысл всего кода (включая определение макросов) поменялся. Что делать будем?

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

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

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

Доо. Ты и правда не знаешь, что JavaScript - это Схема с синтаксисом Си?