Насколько мне известно SBCL вот таскает за собой себя же целиком. При компиляции в исполняемый файл, последний даже для «helloworld» получается размером около 50 Мбайт, без компромиссов.
Часть исходников может загржуться из зашифрованных файлов и сразу компилироваться, не болтаясь в памяти в виде текстов/списков. Потом обфускация и все такое. JS на сайтах тоже фактически OpenSource, как не крути.
Да, конечно, совокупность факторов в нашем безумном денежном мире результирует в то, что эта технология не распостранена, но рано или поздно, ей суждено будет явиться, когда программы будут анализировать сами себя и корректировать свою работу без участия человека.
Интерпретатор компилирующего типа тогда. В данном случае SBCL используется как интерпретатор. И называю я его так не по глубинному смыслу, а чисто по внешней функции.
Форматирование я намеренно оставил свое.
(я
(знаю
(что
(принято
(так)))))
Но мне такой стиль не очень нравится. Раз язык позволяет (не Python же), то зачем вгонять себя в жесткие рамки, определенные кем-то другим. В моей системе форматирования есть свои правила и логика, это не хаос.
P.S. Я знаю, что вы спец в Лиспе, и рассчитывал от вас на более конструктивную критику.
Хотя нет, при вызове ничего не экономится, компилятор же эту строчку все равно выбросит как заведомо невыполнимую.
Все равно, ему как минимум придется рассмотреть многократно эту ситуацию во время выполнения программы, даже если фактически он не будет выполнять эту операцию. Ведь Лиспу совершенно неизвестно, что скормят ему в eval. Поправьте меня, если не так.
Возвращает-то она, по сути, не лямбда-функцию, а s-выражение, являющееся лисп-кодом.
Да. Quote там нужен, чтобы выводился именно код, а не что-то вроде #<FUNCTION (LAMBDA (X)) {100A741ECB}>.
Соответственно, вы можете start-program вполне определить через defconstant или простым setf.
Изначально подразумевались еще некоторые параметры для выбора варианта начального кода, поэтому осталось defun…
Слабо знаком с tcl, честно говоря, поэтому ваш пример для меня тяжело воспринимается. Постараюсь разобраться на досуге.
Почему Lisp? Тут у нас возникает задача, когда нужно собрать рекурсивно код для исполнения из мельчайших элементов, взятых из БД по определенным критериям. Тут очень спасает простота синтаксиса Лиспа: фактически одни скобки. Рассматривал вариант на Lua и на JS, мне они показались значительно менее пригодными.
Часть исходников может загржуться из зашифрованных файлов и сразу компилироваться, не болтаясь в памяти в виде текстов/списков. Потом обфускация и все такое. JS на сайтах тоже фактически OpenSource, как не крути.
Да, конечно, совокупность факторов в нашем безумном денежном мире результирует в то, что эта технология не распостранена, но рано или поздно, ей суждено будет явиться, когда программы будут анализировать сами себя и корректировать свою работу без участия человека.
Форматирование я намеренно оставил свое.
Но мне такой стиль не очень нравится. Раз язык позволяет (не Python же), то зачем вгонять себя в жесткие рамки, определенные кем-то другим. В моей системе форматирования есть свои правила и логика, это не хаос.
P.S. Я знаю, что вы спец в Лиспе, и рассчитывал от вас на более конструктивную критику.
Все равно, ему как минимум придется рассмотреть многократно эту ситуацию во время выполнения программы, даже если фактически он не будет выполнять эту операцию. Ведь Лиспу совершенно неизвестно, что скормят ему в eval. Поправьте меня, если не так.
Да. Quote там нужен, чтобы выводился именно код, а не что-то вроде #<FUNCTION (LAMBDA (X)) {100A741ECB}>.
Изначально подразумевались еще некоторые параметры для выбора варианта начального кода, поэтому осталось defun…
Почему Lisp? Тут у нас возникает задача, когда нужно собрать рекурсивно код для исполнения из мельчайших элементов, взятых из БД по определенным критериям. Тут очень спасает простота синтаксиса Лиспа: фактически одни скобки. Рассматривал вариант на Lua и на JS, мне они показались значительно менее пригодными.