Сбж. Постепенно уйдет, или все-же станет более распространенным? Пугает http://www.tiobe.com/tpci.htm (выберите LISP и увидете спад). Хотя почему? Язык функциональный, динамически типизованный, сейчас такие вещи в моде...
> if это не функция, а специальная форма, т.е. то же ветвление.
Вместо (if (> b 0) + -) могло быть что-нибудь другое. Например, результат вычислений. Да и сам if - это функция. Честно говоря, когда писал пример, я подзабыл про тернарный оператор, что в Си он фактически тоже функция.
> перед вызовом таковых поюзать boundp и functionp?
Не надо перед вызовом. Легко можно макру написать, которая будет сначала экспандить своё содержимое (чтоб любые другие макры раскрыть), а потом проверять все символы на наличие в таблице. Единственная засада такого подхода - не отловить внешний lexical scope, соответственно макра должна быть определена только для top level expressions.
Мне часто приходится писать макры, которые обрабатывают уже готовый лисповый код перед компиляцией, это не так сложно, как может показаться. Даже специальный DSL для этого написал, чтоб каждый раз обработку let, lambda, quote и прочих специальных форм не писать.
> Разве есть что-то лучше и универсальнее, как с++ - от написания дров до бизнес приложений и веб сервисов?
Конечно, есть! Кто ищет, тот найдёт. Ада... Ада 2005!
> >>В с++ есть классы, которые могут вводить
> >А в Scheme можно ввести сами классы. Легко. Без всяких лишних сущностей в "ядре" языка. Иди читай SICP.
> Правильно! Дадим каждому прогеру возможность создать собственный ООП-язык на базе схемы! Свободу попугаям!
Спорный вопрос. В C++ проггерам была дана возможность ввести свою многозадачность. Четверть проекта на boost threads, ещё четверть на ZThreads, ещё -- на pthreads, и остаток на каких-нибудь Solaris Threads или Win32 Threads. Страуструп считал свободу попугаям полюсом.
> Не надо перед вызовом. Легко можно макру написать, которая будет сначала экспандить своё содержимое (чтоб любые другие макры раскрыть), а потом проверять все символы на наличие в таблице.
Вариант, конечно, но ИМХО при достаточно многочисленных входных данных будет затык в ресурсах компа. Потоково обрабатывать мож и помедленнее в некоторых случаях, зато надёжней.
> В C++ проггерам была дана возможность ввести свою многозадачность. Четверть проекта на boost threads, ещё четверть на ZThreads, ещё -- на pthreads, и остаток на каких-нибудь Solaris Threads или Win32 Threads.
Не надо мешать в кучу реализацию нитей уровня ОС (Win32 threads, pthreads, Solaris threads) и библиотечные интерфейсы к системной реализации нитей (Буст). И тем более не надо приписывать отсуствие возможностей параллельного программирования в Си++ это Страуструпу - скорее уж Ричи.
Чисто для справки - Concurrent C++ был придуман 20+ лет назад :)
Scieneer Pty Ltd was formed in March 2000 to develop and support a professional Common Lisp implementation for Symmetrical Multi-Processor (SMP) systems which is a key requirement for many high performance computing and enterprise applications.
> И тем более не надо приписывать отсутствие возможностей параллельного программирования в Си++ это Страуструпу
а я не про отсутствие, я про само мнение Страуструпа по этому поводу
> и библиотечные интерфейсы к системной реализации нитей
Так дело-то приходится иметь с интерфейсами. Если в двух чужих библиотеках разные мутексы, то с каждым нужно работать своим интерфейсом. Хотя где-то там внутри всё одинаково.
m57> интереснее узнать, почему таки был подъём :D tche> Если забыть про макры, ничего особо интересного в Лиспе нет.
Лисп не мертвее, чем обычно. Лисп никогда не умрет, потому что он приспосабливается и существует в разных формах. Например сегодня мы видим, что не малую популярность приобрел XML. Лисп - это по сути программируемый XML. Даже если убрать все Common Lispы, Схемы, промежуточные списочные представления внутри компиляторов, то все равно идея будет продолжаться в разных видах, в том числе в виде XML.
Нет ничего такого, включая системы автоматического вывода типов или низкоуровневое системное программирование, чего нельзя было бы реализовать в Лиспе/на Лиспе/в виде Лиспа. Поэтому странно слышать, что в Лиспе нет ничего интересного. Например в Лиспе есть Пролог ;-)
anonymous> >В с++ есть классы, которые могут вводить любое понятие, а не только >списки и деревья
Вводить то может быть и могут. Можно еще и темплэйты по случаю припомнить. Только регулярное выражение на их основе во время компиляции не скопилируешь, строку не разберешь, семантику языка шибко не изменишь.
>Как сделать, чтобы в лиспе (Common Lisp и/или Scheme) интерпретатор >не ругался на неизвестные (необъявленные функции), а молча их >игнорировал или вызывал какую-нибудь дефолтную функцию, не прекращая >работы программы?
Эффективный путь - не использовать интерпретатор для разбора текста (или иного представления), а предварительно преобразовать его к исполняемому виду, т.е. выкинуть необъявленные функции перед выполнением. Тем более, что очищенное представление можно будет легко скомпилировать в нэйтив.
Не эффективный, но более простой путь, перехватывать conditions, связанные с необъявленными функциями, заменять на ходу слот функции у символа на заглушку и рестартовать с этого же места.