Tcl 8.6 VS Tcl 9.0 VS Rebol3 VS Lisp

Разве? Скажи еще что список - это объект

Удивительное всегда с нами. Он не только объект, но и экземпляр класса cons.

Ты еще скажи, что все операторы -тоже объекты

А loop, devfar, defmacro?

Это все макросы. Все макросы

> (class-of #'loop)
#<BUILT-IN-CLASS FUNCTION>

Вобще в стандарте CL так и написано, что все есть объект. Как это не удивительно.

Популярные, грамотно спроектированные языки и без моего скромного мнения останутся

Если Java хотя бы проектировали специально для надрессированных обезьянок, то C++ и PHP сляпали из спичек и желудей, вообще не включая мозг.

defmacro?

+9000

defmacro?

> (class-of #'defvar)
#<BUILT-IN-CLASS FUNCTION>
WEB-P> (class-of #'defmacro)
#<BUILT-IN-CLASS FUNCTION>

Вобще любой макрос/функция экземпляр класса function т.е функция

юзание жабовских библиотек на кложуре

Если у либы есть обертка - прекрасно, если самому писать без обертки - все уродливее и уродливее (разные прослойки, фу, мерзость).

из этого ничего не перспективно, не мейнстрим же

для себя что угодно, но я бы рекомендовал из этого плотнее с CL и TCL 8.6 познакомиться

Посмотрел на ребол - какой-то изувеченный лисп. Зачем он может быть нужен-то вообще?

Он очень маленький. Исторически его хотели впихать мобилки.

Зачем плодить прослойки, если можно ипользовать классы ява напрямую? Так и в Programming Clojure написано: лучше использовать напрямую.

Однако, C++ и PHP будут жить и процветать еще много десятилетий после того, как твою никому не нужную дохлую тушку зароют на помойке.

Пусть процветают, кто-то же должен всю эту срань поддерживать. Обезьянки-то никуда не денутся.

а в от Fixnum, например, в common lisp можно определить класс-потомок?

Так а зачем ходить далеко? Ну ладно - не все есть объект в CL. Опять же - полная реализация ООП возможна только когда все есть объект

В CLOS всё - объект. Базовые общелисповские типы, определённые вне CLOS, были в CLOS доопределены.

НедоООП - это как в C++.

толстяк месяца! Приз этому Михаилу!

а в от Fixnum, например, в common lisp можно определить класс-потомок?

Нет, в плане базовых типов CLOS плохо в систему интегрирована. Фактически, CLOS - это библиотека. Почему сделали так? Потому что CL - хороший инженерный язык, коммити не стало жертвовать эффективностью базового языка в угоду ООП.

И тащить за собой убогую JVM? А зачем?

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

Встает вопрос - что перспективнее из представленного? Что стоит учить «для себя» и для использования в домашних проектах? Что может стать мейнстримом индустрии и может ли вообще?

Для себя - CL и racket, мейнстримом становится clojure.

При поддержке Google - не удивительно

Google не развил ни одного проекта, кроме изначально убогого поиска. Остальное купил и изуродовал, в основном. Язык ему не пропихнуть. Корпорации не умеют делать ничего душевного :)

а что интересного обещают в Tcl 9.0 ?

Ну я думаю главную линию - замедление выполнения, развивать будут. Это однозначно. А что еще - тоже интересно.

Вобще любой макрос/функция экземпляр класса function т.е функция

Ну, это же неправда - макрос нельзя использовать везде, где применима функция.

По сабжу - я выбрал Tcl. Очень приятный и легкий синтаксис. Только не забывай комментировать что набыдлокдил - через неделю не разберешься уже что к чему.

Не дай бог, если Common Lisp (CL) когда-нибудь станет мейнстримом. Нафиг такое счастье. Мейнстрим не значит «хорошо». Сложные и функционально богатые языки, вообще, никогда не станут мейнстримом на мой взгляд. Это и к Haskell относится. И я поэтому рад за оба языка.

легкий синтаксис

через неделю не разберешься уже что к чему.

LOL

Диалектика, однако...

Легкий чтобы писать, а не читать. Что вообще подходит, ведь на ЯП пишут, а не читают. ;)

ЯП пишут, а не читают. ;)

;) А как же принцип code reuse?

Не дай бог, если Common Lisp (CL) когда-нибудь станет мейнстримом.

(incf *)

Не дай бог, если Common Lisp (CL) когда-нибудь станет мейнстримом.

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

Можно. Макрос это и есть функция, по факту.

Макрос это макрос. С ним *связана* lisp ф-ция, которая вызывается когда надо его раскрыть.

? (macro-function 'defvar) #<Compiled-function DEFVAR Macroexpander #x1008B167F>

Clozure CL: ? (class-of #'defvar)

Error: Undefined function: DEFVAR

? (class-of #'defmacro)

Error: Undefined function: DEFMACRO

Lispworks:

(class-of #'defvar)

Error: DEFVAR names a macro — bad arg for FUNCTION.

Вообще замечаю, что ребятишки из sbcl лабают некий свой lisp ;)

Макрос это макрос.

Х - это Х, очевидно.

С ним *связана* lisp ф-ция

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

Ну, это же неправда - макрос нельзя использовать везде, где применима функция.

Я говоили поро объекты и классы, а не про их исползование. Увидь разницу.

Удачи в использовании макросов-обычных-функций-по-факту

Да все так делают, и никаких проблем не возникает.

для использования - Tcl/Tk
остальное - just for fun

(class-of #'defmacro)

Портабельно будет (class-of (macro-function 'defmacro)). #' это сахар для специальной операции function:

It is an error to use function on a function name that does not denote a function in the lexical environment in which the function form appears. Specifically, it is an error to use function on a symbol that denotes a macro or special form. An implementation may choose not to signal this error for performance reasons, but implementations are forbidden from defining the failure to signal an error as a useful behavior.

Так что тут нужна функция (и аксессор) macro-function.

А всего там только три смысла — http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/glo_m.html#..., то есть форма, имя или функция (от двух аргументов) выполняющая раскрытие.