LINUX.ORG.RU
ФорумTalks

LISP RIP?


0

0

Сбж. Постепенно уйдет, или все-же станет более распространенным? Пугает http://www.tiobe.com/tpci.htm (выберите LISP и увидете спад). Хотя почему? Язык функциональный, динамически типизованный, сейчас такие вещи в моде...

★★
Ответ на: комментарий от Legioner

> if это не функция, а специальная форма, т.е. то же ветвление.

Вместо (if (> b 0) + -) могло быть что-нибудь другое. Например, результат вычислений. Да и сам if - это функция. Честно говоря, когда писал пример, я подзабыл про тернарный оператор, что в Си он фактически тоже функция.

anonymous_incognito ★★★★★
()
Ответ на: комментарий от anonymous_incognito

>Да и сам if - это функция.

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

tche
()
Ответ на: комментарий от tche

предлагаю обозвать if ленивой функцией.

ugoday ★★★★★
()
Ответ на: комментарий от tche

> Нет, не функция. Это специальная форма.

Блин, сам же ранее оговорился, что не функция :)

anonymous_incognito ★★★★★
()
Ответ на: комментарий от anonymous_incognito

> Так я же зараннее не знаю известна функция или нет?

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

bugmaker ★★★★☆
()
Ответ на: комментарий от bugmaker

> Вот и проверь так, связан этот символ с функцией, или не.

Попробую.

anonymous_incognito ★★★★★
()
Ответ на: комментарий от bugmaker

> перед вызовом таковых поюзать boundp и functionp?

Не надо перед вызовом. Легко можно макру написать, которая будет сначала экспандить своё содержимое (чтоб любые другие макры раскрыть), а потом проверять все символы на наличие в таблице. Единственная засада такого подхода - не отловить внешний lexical scope, соответственно макра должна быть определена только для top level expressions.

Мне часто приходится писать макры, которые обрабатывают уже готовый лисповый код перед компиляцией, это не так сложно, как может показаться. Даже специальный DSL для этого написал, чтоб каждый раз обработку let, lambda, quote и прочих специальных форм не писать.

Типа:

(visit-scheme-tree ((symbol?) (if (function? (eval this-node)) this-node `(substitute-it-with-any-symbol-or-macro-you-want))

anonymous
()
Ответ на: комментарий от anonymous

> Разве есть что-то лучше и универсальнее, как с++ - от написания дров до бизнес приложений и веб сервисов?

Конечно, есть! Кто ищет, тот найдёт. Ада... Ада 2005!

> >>В с++ есть классы, которые могут вводить

> >А в Scheme можно ввести сами классы. Легко. Без всяких лишних сущностей в "ядре" языка. Иди читай SICP.

> Правильно! Дадим каждому прогеру возможность создать собственный ООП-язык на базе схемы! Свободу попугаям!

Спорный вопрос. В C++ проггерам была дана возможность ввести свою многозадачность. Четверть проекта на boost threads, ещё четверть на ZThreads, ещё -- на pthreads, и остаток на каких-нибудь Solaris Threads или Win32 Threads. Страуструп считал свободу попугаям полюсом.

Nihilist
()
Ответ на: комментарий от anonymous_incognito

а если вместо if возвращать указатель

void *vari(int a, int b);
/* эта функция возвращает указатель на функции plus или minus*/

(*vari(a,b))(a,b);

anonymous
()
Ответ на: комментарий от parser

LISP в MIT действительно RIP.

>>Чуваки, которые изучали lisp в MIT начинают помирать от старости? Эра динозавров проходит

>Саныч, чуваки которые сейчас учатся в MIT изучают Scheme.

Базовый курс программирования, который долгое время читался с примерами на Scheme, переведён на Python.

Camel ★★★★★
()
Ответ на: комментарий от anonymous

> Не надо перед вызовом. Легко можно макру написать, которая будет сначала экспандить своё содержимое (чтоб любые другие макры раскрыть), а потом проверять все символы на наличие в таблице.

Вариант, конечно, но ИМХО при достаточно многочисленных входных данных будет затык в ресурсах компа. Потоково обрабатывать мож и помедленнее в некоторых случаях, зато надёжней.

bugmaker ★★★★☆
()
Ответ на: комментарий от m57

> Все адепты лиспа такие неадекватные клоуны? :)

Боян. Научись наконец гуглем пользоваться.

bugmaker ★★★★☆
()
Ответ на: комментарий от Nihilist

> В C++ проггерам была дана возможность ввести свою многозадачность. Четверть проекта на boost threads, ещё четверть на ZThreads, ещё -- на pthreads, и остаток на каких-нибудь Solaris Threads или Win32 Threads.

Не надо мешать в кучу реализацию нитей уровня ОС (Win32 threads, pthreads, Solaris threads) и библиотечные интерфейсы к системной реализации нитей (Буст). И тем более не надо приписывать отсуствие возможностей параллельного программирования в Си++ это Страуструпу - скорее уж Ричи.

Чисто для справки - Concurrent C++ был придуман 20+ лет назад :)

tailgunner ★★★★★
()
Ответ на: комментарий от KF

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.

http://www.scieneer.com

Sun-ch
()
Ответ на: комментарий от tailgunner

> Чисто для справки - Concurrent C++ был придуман 20+ лет назад :)

Если ещё одна пятая часть на Concurrent C++, вообще весело.

Nihilist
()
Ответ на: комментарий от tailgunner

> И тем более не надо приписывать отсутствие возможностей параллельного программирования в Си++ это Страуструпу

а я не про отсутствие, я про само мнение Страуструпа по этому поводу

> и библиотечные интерфейсы к системной реализации нитей

Так дело-то приходится иметь с интерфейсами. Если в двух чужих библиотеках разные мутексы, то с каждым нужно работать своим интерфейсом. Хотя где-то там внутри всё одинаково.

Nihilist
()
Ответ на: комментарий от m57

m57> интереснее узнать, почему таки был подъём :D tche> Если забыть про макры, ничего особо интересного в Лиспе нет.

Лисп не мертвее, чем обычно. Лисп никогда не умрет, потому что он приспосабливается и существует в разных формах. Например сегодня мы видим, что не малую популярность приобрел XML. Лисп - это по сути программируемый XML. Даже если убрать все Common Lispы, Схемы, промежуточные списочные представления внутри компиляторов, то все равно идея будет продолжаться в разных видах, в том числе в виде XML.

Нет ничего такого, включая системы автоматического вывода типов или низкоуровневое системное программирование, чего нельзя было бы реализовать в Лиспе/на Лиспе/в виде Лиспа. Поэтому странно слышать, что в Лиспе нет ничего интересного. Например в Лиспе есть Пролог ;-)

anonymous> >В с++ есть классы, которые могут вводить любое понятие, а не только >списки и деревья

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

Lisper

anonymous
()
Ответ на: комментарий от anonymous_incognito

>Как сделать, чтобы в лиспе (Common Lisp и/или Scheme) интерпретатор >не ругался на неизвестные (необъявленные функции), а молча их >игнорировал или вызывал какую-нибудь дефолтную функцию, не прекращая >работы программы?

Эффективный путь - не использовать интерпретатор для разбора текста (или иного представления), а предварительно преобразовать его к исполняемому виду, т.е. выкинуть необъявленные функции перед выполнением. Тем более, что очищенное представление можно будет легко скомпилировать в нэйтив.

Не эффективный, но более простой путь, перехватывать conditions, связанные с необъявленными функциями, заменять на ходу слот функции у символа на заглушку и рестартовать с этого же места.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.