Common lisp и императивщина

>> Что, действительно все так печально?

А что тебя печалит, конкретно?

>> зы: только начинаю смотреть на лисп и остро стоит вопрос scheme vs CL

Ессно scheme и ессссно читать SICP.

Ась. Циклы в Scheme. Только рекурсивно. Её ж специально создавали вправлять мозги юным подованам. (Если что, то for какой нить на scheme определяется достаточно просто). В Common Lisp'e, т.к. tail recursion в стандарте не прописана, то есть всякие полезные макросы, вроде do и loop.

В схеме тоже есть do. И цикл пишется достаточно императивно.

>>А что тебя печалит, конкретно? Конкретно, напрягает вот это: "The style preferred by many Common Lisp programmers may seem more familiar to programmers used to structured languages such as C"

>>Ессно scheme и ессссно читать SICP. Почему ессно? CLOS не нужен? Макры у схемы есть?

Неужели функциональная парадигма - достойная альтернатива ООП? В голове не укладывается. Как, к примеру в функциональном стиле будут выглядеть объекты в игровом мире, которые с кучей свойств и методов?

Тут, имхо, ключевые слова "style preferred by many Common Lisp programmers" - стиль, предпочитаемый многими программерами. Но это же не значит, что все должны писать именно так. И на схеме, и на коммон лиспе можно при желании писать в императивном стиле, можно в функциональном. Хотя действительно, схема, имхо, больше располагает к функциональщине, чем CL.

> Макры у схемы есть?

Есть.

Эти стили нужно совмещать а не противопоставлять. А выглядеть может так:

(define (game-object-new prop1 prop2) ..)
(define (game-object-get-prop obj) ..)
(define (game-object-set-prop! obj) ..)
(define (game-object-move obj dx dy) ..)

А вот это уже интерестно

Лучше через замыкание сделать:
(define (new-object prop1)
(define (set-prop1! val)
(set! prop1 val))
(define (get-prop1)
prop1)
(define (dispatch m)
(cond ((eq? m 'get-prop1) get-prop1)
((eq? m 'set-prop1!) set-prop1!)
(else 'error)))
dispatch)

Немного громоздко, но таки объекты с внутренним состоянием.

С форматированием красивше:
(define (new-object prop1)
  (define (set-prop1! val)
    (set! prop1 val))
  (define (get-prop1)
    prop1)
  (define (dispatch m)
    (cond ((eq? m 'get-prop1) get-prop1)
          ((eq? m 'set-prop1!) set-prop1!)
          (else 'error)))
  dispatch)

Да, а можно использовать Common Lisp и CLOS, и все будет выглядеть еще лучше :)

http://en.wikipedia.org/wiki/CLOS

> Неужели функциональная парадигма - достойная альтернатива ООП?

Что значит "альтернатива"? У них разные, слабо пересекающиеся области применимости. ООП весьма ограниченная модель, применимая в редких случаях. Функциональная декомпозиция более общая и мощная, но тоже не панацея.

> Как, к примеру в функциональном стиле будут выглядеть объекты в игровом мире, которые с кучей свойств и методов?

Ты уже заговорил о каких-то там "объектах", тем самым неизбежно приходя к ООП. Забудь об объектах, можно мир описывать и в совсем других терминах.

>Забудь об объектах, можно мир описывать и в совсем других терминах.

накидай ссылок на либы, анлоги qt хотя бы, мне просто интересно, как можно по другому сделать

Ну, если совсем по другому, то посмотри на Fudgets и почитай про functional reactive animation.

На счет функциональной не знаю. А вот в логическом программировании вполне можно описывать мир так как ты говоришь. Например

domains
date = date( integer, symbol, integer )
first_name, last_name = symbol
date_of_birth = date
person = person( first_name, last_name, date_of_birth )

predicates
set_first_name( person, first_name )
set_last_name( person, last_name )
set_date_of_birth( person, date_of_birth )

Наверно, можно как то еще. Я не очень хорошо разбираюсь.

Можно посмотреть на Visual Prolog, который начиная с 6 версии использует ООП модель.

забавно, мне эказмен по прологу в среду сдавать ))

Для схемы есть TinyCLOS

>Да, а можно использовать Common Lisp и CLOS, и все будет выглядеть еще лучше :)

Удачи тебе. =)

Вообще на Прологе "правильно" программировать сложно. Советую почитать Братко "Программирование на Prolog для систем искуственного интеллекта".

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

Так же советую почитать книгу А. К. Гуц "Математическая логика и теория алгоритмов". Читать про логику высказываний и предикатов.

Если сам книги не найдешь, могу выложить.

Отдельные реализации схемы уже сильно разрослись и задирают КЛ.

inb4 The cancer that is killing /S/cheme.

>накидай ссылок на либы, анлоги qt хотя бы, мне просто интересно, как можно по другому сделать

что именно сделать по-другому? вот тебе Frag, например: 3D-шутер на haskell (AFRP, Yampa) - никакого тебе традиционного ООП, а всех исходников на 69Kb (причём большая часть - BSP)

посмотри Type Classes, Type Families, посмотри что такое ADT (и GADT). и как с их помощью писать то, что ты привык писать на ООП-языках. всё, как бы, познаётся в сравнении

> посмотри Type Classes, Type Families, посмотри что такое ADT (и GADT).

Ты хочешь сказать, что это не ООП?

> Ты хочешь сказать, что это не ООП?

Там subtyping нет, и потому всё намного проще и гибче, чем в классическом ООП.

>Ты хочешь сказать, что это не ООП?

да

>Ты хочешь сказать, что это не ООП?

http://haskell.org/haskellwiki/OOP_vs_type_classes

>всё, как бы, познаётся в сравнении

Ъ, поэтому и интересно

>Ъ, поэтому и интересно

вообще самый ад - это всё-таки фунциональные структуры данных Окасаки; а так мемоизированные санки, например, я и в C++ изобретал в своё время (SICP'а я тогда ещё не читал)

я сейчас занимаюсь reactive Элиотта, если есть желание попробовать фисто функциональное event-driven программирование - welcome ;) в качестве обучающего примера есть тетрис на GLUT'е

а вот если именно с LISP'ом, то это не ко мне. там скобок много :(

Кстати, безотносительно ООП, в Хаскеле нормальная раздельная компиляция есть?

>Кстати, безотносительно ООП, в Хаскеле нормальная раздельная компиляция есть?

это есть что?

>> Кстати, безотносительно ООП, в Хаскеле нормальная раздельная компиляция есть?

> это есть что?

Это скомпилировать Хаскел-модуль в объектный файл (не обязательно ELF с машкодом), и потом импортировать его в другой модуль, не имея исходников первого?

>Это скомпилировать Хаскел-модуль в объектный файл (не обязательно ELF с машкодом), и потом импортировать его в другой модуль, не имея исходников первого?

не пробовал, думаю что без проблем. рекомендую спросить в haskell-cafe (или подождать Мигеля)

> Неужели функциональная парадигма - достойная альтернатива ООП?

В качестве proof of concept - Олег Киселёв в своё время сделал библиотеку, которая давала нехилые ООП-возможности в почти обычном Хаскеле (там использовалась парочка давно знакомых и всем привычных расширений). Так что - более чем достойная.

> Как, к примеру в функциональном стиле будут выглядеть объекты в игровом мире, которые с кучей свойств и методов?

Как записи, скорее всего.

> Это скомпилировать Хаскел-модуль в объектный файл (не обязательно ELF с машкодом), и потом импортировать его в другой модуль, не имея исходников первого?

Ты знаешь, у меня вот на машине нет исходников хаскелевых стандартных библиотек, типа Control.Monad или что-то в этом роде. Но всё работает.

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

MigMit:Test MigMit$ cat > Library.hs << EOF
> module Library where
> class GetInt a where getInt :: a -> Int
> instance GetInt Int where getInt x = x
> u = "Hi, people!"
> v :: Num a => a
> v = 1000000000000
> EOF
MigMit:Test MigMit$ ghc -c Library.hs 
MigMit:Test MigMit$ rm Library.hs
MigMit:Test MigMit$ cat > Main.hs << EOF
> module Main where
> import Library
> main =
>     do print $ getInt $ length "qwerty"
>        putStrLn u
>        print (v :: Integer)
>        print (v :: Int)
> EOF
MigMit:Test MigMit$ ghc -o program Main.hs Library.o
MigMit:Test MigMit$ ./program
6
Hi, people!
1000000000000
-727379968

Спсибо, я уже нашел ответ в вики.

> мне просто интересно, как можно по другому сделать

http://www.gtk-server.org/apps.html

http://www.gtk-server.org/tictactoe.clisp http://www.gtk-server.org/tictactoe.txt http://www.gtk-server.org/smart-calc.clisp

хотя примеры "дубовые": много boilerplate кода. По идее, это должен быть удобный DSL на макрах или просто функциях, чтобы отделить модель и представление.

> вот тебе Frag, например: 3D-шутер на haskell (AFRP, Yampa) - никакого тебе традиционного ООП, а всех исходников на 69Kb (причём большая часть - BSP)

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