LINUX.ORG.RU

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

> Интересная вещь - кучу инструментов, написанных на Лиспе, его любители засчитывают как возможности _самого языка_. При этом аналогичные инструменты, написанные на других языках - "кастыли".

Ну ты ниже уже понял - потому что всё, что написано на лиспе, можно использовать "внутри" самого лиспа, у которого "снаружи" просто нет :) Посему нет и костылей.

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

> Для тех, кто в танке - насколько можно расширить синтаксис Лиспа, не прибегая к написанию специальных парсеров? Не переопределяя read, read-table, или еще что-нибудь такое.

Блин, ты ещё попроси отказаться от скобок не переопределяя readtable...

Посмотри HyperSpec - там все формы описаны без скобок, типа:

Syntax:

subsetp list-1 list-2 &key key test test-not => generalized-boolean

Как можно расширить синтаксис вот таких простых фраз? Куда его расшираять? Тебе ближе A=B? Ну посмотри же loop!

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

> А то, что в Лиспе парсер входного языка интегрирован в runtime и может быть заменен - интересная фишка, которая ни на что особо не влияет.

О, ты уже кое-что начал понимать... Осталось понять, почему это не просто интересная фишка, а имеющая очень большое значение, наряду с макрами, которые можно применять и использовать в любой период "жизни" программы: load eval compile. И почему эту фишку так легко реализовать и использовать в лиспе, а для других это просто непосильная задача... :)

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

> Может быть, проблема маргинальности лиспа именно в этом? В том, что каждый лиспер -- сам себе мудрец в башне из слоновой кости? Впрочем, по стилю yyk в это легко поверить ;-).

А куда уж проще? Мне делать больше нечего, кроме как уговаривать тебя "ну посмотри поближе на лисп... не понял - посмотри ещё раз", а в ответ "папа - что это было?" :) Какая к хреням маргинальность, если в ответ я только и слышу - "это на любом языке сделать можно". Так делайте на том, на чём хотите! Вы хотите _меня_ убедить, что лисп вам не нужен? Не надо - я уже верю :)

По поводу "мудреца в башне из слоновой кости" - "я не волшебник, я только учусь" :)

По поводу стиля - опять вы к скобочкам придираетесь... ;)

Алё, люди, я не собираюсь никому ничего навязывать или доказывать - докажите себе сами. Правда сначала вам придётся разобраться в том, что собираетесь доказывать/опровергать :)

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

> Мне делать больше нечего, кроме как уговаривать тебя "ну посмотри поближе на лисп... не понял - посмотри ещё раз"

Ну понятно, на ругань у нас время находится, а на уговаривание -- уже не хватает.

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

> То есть, я понимаю, что у меня gtk нет, не тупой. Но что делать? Где взять и куда положить, чтоб поехало? Вообще, есть какая-то step-by-step howto? Или, как всегда у лисперов -- сплошной дзен?

Не смотрел. А в самом пакете неужели никакой доки нет? А на сайте?

Дзен - не дзен, но скорее всего пакет требует asdf и cffi (или что-то вроде того), и автор соответственно предполагает, что ты всем этим уже умеешь пользоваться... :)

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

> Аха. Самодостаточная система. Как Лего. "Собери сам себе велсипед" называется ;-).

Ёлки зелёные, тут некоторые орут, что стандарт CL и так не в одни ворота не влазит, а ты хочешь, чтобы туда ещё и соломки после каждой ступеньки настелили? На что это станет похоже? Следующее издание БСЭ?

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

> А в самом пакете неужели никакой доки нет? А на сайте?

Беда в том, что я вообще не понял, что это за пакет :-(. На сайте их штук пять, пробовать их все по очереди?

> Дзен - не дзен, но скорее всего пакет требует asdf и cffi (или что-то вроде того), и автор соответственно предполагает, что ты всем этим уже умеешь пользоваться... :)

А хрен его знает. Только что нашел в ебилдах cl-lambda-gtk. Оно как, нормальное? Или лучше что-нибудь другое выбрать? Замаскировано как нестабильное, а после установки опять нихрена не понятно. Пытаюсь действовать по инструкции, получаю исключение.

Видимо, придется ждать следующего приступа фанатизма. Ну что же, не в первый раз...

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

> Ну понятно, на ругань у нас время находится, а на уговаривание -- уже не хватает.

(стал нервно оглядываться, уж не стоит ли кто за спиной и не ругется ли... нет никого :)

Где, где я ругался? Это мои то слова - ругань? На ЛОРе? LOL!!!

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

> А хрен его знает. Только что нашел в ебилдах cl-lambda-gtk. Оно как, нормальное? Или лучше что-нибудь другое выбрать? Замаскировано как нестабильное, а после установки опять нихрена не понятно. Пытаюсь действовать по инструкции, получаю исключение.

> Видимо, придется ждать следующего приступа фанатизма. Ну что же, не в первый раз...

Ну, да, как и везде - есть проекты, в которых авторы не утруждают себя подробной документацией. Скорее всего - тебя ждут :)

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

> Хз. Может быть, на Питон? А вообще-то я хотел всего лишь awk...

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

Можешь посмотреть clocc - там много есть интересного.

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

Исхожу из того, что ASDF установлен вместе с SBCL. Если у тебя Gentoo 
или Debian, то просто установи common-lisp-controller. ASDF вместе 
с ним поставится.

$ mkdir sbcl

Распаковываешь в ~/sbcl
http://common-lisp.net/project/cffi/releases/cffi_0.9.2.tar.gz

Распаковываешь в ~/sbcl
ftp://common-lisp.net/pub/project/lambda-gtk/lambda-gtk-0.1.tar.gz

$ cd ~
$ mkdir .sbcl
$ mkdir .sbcl/systems
$ cd .sbcl/systems
$ ln -s /home/.../sbcl/cffi_0.9.2/cffi.asd cffi.asd
$ ln -s /home/.../sbcl/lambda-gtk-0.1/lambda-gtk.asd lambda-gtk.asd
$ ln -s /home/.../sbcl/lambda-gtk-0.1/lambda-gtk-examples.asd lambda-gkt-examples.asd

Запускаешь SBCL.

REPL> (asdf:operate 'asdf:load-op 'lambda-gtk-examples)

Завари кофе. И смотри. Сначала по цепочке скомпилируется cffi, потом 
lambda-gtk, потом lambda-gtk-examples. После всего запускаем 
примерчики:

REPL> (scribble-simple)
REPL> (hello-world)
REPL> (radio-buttons)
REPL> (sliders)

Надеюсь,ч то ничего не забыл и не пропустил. По ходу поймем.

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

Можно и просто набрать:

REPL> (require 'lambda-gtk-examples)

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

Я юзаю http://www.cliki.net/clg . По ссыле оттуда идём на страницу проекта, загружаем самый свежий из http://sourceforge.net/project/showfiles.php?group_id=9574 , разворачиваем и читаем README. Поступаем как там написато. Если чёто непонятно/неполучяецо вежливо задаём конкретный вопрос на ЛОР в раздел Development или создаём топик "ну гадось ваша заливная рыбо нифига ничё не работаит" на ЛОР в раздел Talks. Соответственно вас либо поправляют, что нужно сделать или во всех подробностях объясняют чё у их всё работает, кто вы такой и почему от своих родителей произошли. Казалось бы, что может быть проще?

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

Я объяснял почему у меня код длиннее. Вот пожалуйста, 
прямой аналог лиспового кода, хотя таки пришлось оставить фишку,
которой нет в примере у лисперов, переопределённый __str__()

Итого: Питон --- 37 строк, Лисп --- 33 строки

И никакие макросы не нужны.

Давай сойдёмся на том, что Лисп на 10% выразительнее чем Питон? :-)

class SystemObject:
    def __init__(self, name):
        self.name = name
    def __str__(self):
        return self.name + ' ' + str(self.__dict__)

class LineReader:
    def __init__(self, pattern, name, fields):
        self.pattern = pattern
        self.fields = fields
        self.name = name
    def parseString(self, s):
        obj = SystemObject(self.name)
        for field in self.fields:
            setattr(obj, field[2], s[field[0]:field[1] + 1])
        return obj
    
data = """SVCLFOWLER         10101MS0120050313......................... 
SVCLHOHPE          10201DX0320050315........................ 
SVCLTWO           x10301MRP220050329.............................. 
USGE10301TWO          x50214..7050329..........................""".splitlines()

readers = {'SVCL': LineReader('SVCL', 'ServiceCall', [
    (4, 18, 'customer_name'),
    (19, 23, 'customer_id'),
    (24, 27, 'call_type_code'),
    (28, 35, 'date_of_call_string')]),
    'USGE': LineReader('USGE', 'Usage', [
    (4, 8, 'customer_id'),
    (9, 22, 'customer_name'),
    (30, 33, 'cycle'),
    (31, 36, 'read_date')])}
    
for line in data:
    reader = readers.get(line[:4], None)
    if reader is not None:
        print reader.parseString(line)

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

> Давай сойдёмся на том, что Лисп на 10% выразительнее чем Питон? :-)

"Ачуметь!.." Т.е. при том, что питон не имеет стандартных макр и средств переопределения синтаксиса, он ещё и на 10% менее выразителен? Cool!.. :))))

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

> Итого: Питон --- 37 строк, Лисп --- 33 строки Извинясь, нагнал. В лиспе я считал только непустые строки, а в питоне все. Плюс у меня одна строка лишняя (self.pattern = pattern), получается:

Итого: Питон --- 32 строки, Лисп --- 33 строки

> Давай сойдёмся на том, что Лисп на 10% выразительнее чем Питон? :-)

Упс, надо было соглашаться. Теперь я предлагаю сойтись на том что Питон на 3% выразительнее чем Лисп :-)

А также теперь моя очередь задавать вопросы о лишних сущностях, возьмём напрмер...ммм...макросы!

Макросы это намного более сложная концепция чем классы/объекты и зачем привносить сложную сущность, если можно обойтись простой?

А если серьёзно, то для этой задачи Лисп рулит из-за того и только из-за того что в нём можно определить list literal из гетерогенных объектов и динамически добавлять к объектам атрибуты, Питон для этой задачи рулит точно по этой же причине, только в Лиспе используются макросы, а в Питоне классы.

Точно так же можно было использовать вместо класса LineReader замыкание, наверное даже получилось бы короче, т.к. не надо было бы запоминать self.fields = fields, self.name = name --- они бы "запомнились" бы интерпритатором.

Эту задачу можно легко и изящно (ну, разумеется похуже чем на Питоне ;) решить на любом языке где можно записать list literal из гетерогенных объектов и можно задавать атрибуты у объектов динамически (или в языке есть словари/хеши), т.е. это наверняка Perl, Ruby, наверное PHP.

И решение будет СУТЬ ТОЖЕ САМОЕ что и на лиспе.

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

> Макросы это намного более сложная концепция чем классы/объекты и зачем привносить сложную сущность, если можно обойтись простой?

Классы/обекты более сложная ссущнось чем биты. Зачем привносить сложную, если то же самое можно на асме слабать?

>в Лиспе используются макросы, а в Питоне классы.

в лиспе есь _и_ макросы _и_ классы. Хотя ооп в лиспе реализовано намного грамотнее чем в с++ например, классы используются намного реже. Угадай с трёх раз почему?

> Эту задачу можно легко и изящно

легко и изящно можно решить любую задачу на чём угодно, как тут уже демонстрировался пример с перестановками на паскале.

> на любом языке где можно записать

станет ли асм языком всоково уровня если в нём есь возможность вызывать из внешних библиотек те же самые хеши и списки?

> И решение будет СУТЬ ТОЖЕ САМОЕ что и на лиспе.

Не будет. При использовании низкоуровневого языка никуда не деться от низкоуровневых понятий.

И строки считать тут ни к чему. Если пример укладывается в 30 строк, съёживать его просто некуда. А на более крупных легко можно добиться разницы в обёме кода до 10 (!) раз, причём одновременно с улучшением читабельности а не в ущерб ей.

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

> в лиспе есь _и_ макросы _и_ классы. Хотя ооп в лиспе реализовано намного грамотнее чем в с++ например, классы используются намного реже. Угадай с трёх раз почему?

У меня есть три предположения:

1. Потому что макросы это тру, а классы это быдло-мейнстрим

2. Чтобы отличаться

3. Потому что макросы это тру, а классы это быдло-мейнстрим

Я не буду спорить про лисп вообще, давай поговорим об этом конкретном примере. Ты считаешь что решение на Питоне более низкоуровневое чем приведённый пример на Лиспе? Почему?

Кстати о высокоуровневых и низкоуровневых конструкциях. Если классы в Лиспе написаны на макросах, то это означает что классы это более высокоуровненвые конструкции?

ИМЗО так оно и есть. Макросы это конечно мощная вещь (как асм, на асме можно сделать всё) но более низкоуровневая чем классы. Это просто возможность заменить кусок исходника результатом работы функции.

Так что ты определись что ты любишь больше, мощные конструкции или высокоуровневые?

>> И решение будет СУТЬ ТОЖЕ САМОЕ что и на лиспе.

> Не будет. При использовании низкоуровневого языка никуда не деться от низкоуровневых понятий.

А какие понятия являются низкоуровневыми?

Класс это высокоуровневое понятие? Словарь это высокоуровневое понятие? Макросы это высокоуровневое понятие? И какой у них уровень высокоуровневости?

А то без общих терминов и определений мы ни до чего не договоримся...

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

> Классы/обекты более сложная ссущнось чем биты. Зачем привносить сложную, если то же самое можно на асме слабать?

Не, не так. Нах ваще кампутиры!

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

> 1. Потому что макросы это тру, а классы это быдло-мейнстрим

> 2. Чтобы отличаться

> 3. Потому что макросы это тру, а классы это быдло-мейнстрим

Какой-то ты чёрно-белый... :) Ну и "пальцем в небо".

> Кстати о высокоуровневых и низкоуровневых конструкциях. Если классы в Лиспе написаны на макросах, то это означает что классы это более высокоуровненвые конструкции?

Не _на_ макросах, а с их использованием. Точно так-же макры могут использовать классы. Они там не "одно над/под другим", а "рядом, взаимодополняя друг друга". Так что сравнение их "уровней" - бред. И не надо совать классы везде, в том числе и там, где они нафиг не нужны (подозреваю, что переписав лисповый код на классы мы получили бы гораздо больше кода ;)

И если на питоне по-другому никак (не уверен в этом), то делать точно-также на лиспе - "моветон" :)

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

> У меня есть три предположения:

неугодал. У тя есь щё три попытки

> Ты считаешь что решение на Питоне более низкоуровневое 
чем приведённый пример на Лиспе? Почему?

повторение мать заикания мля :D давай начнём с более простого примера
тогда уж. Вот такое заимплементь на любом низкоуровневом и сравним 
чё получилось: 
http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1592749 
раз уж более сложный пример ниасиливаем.

> Если классы в Лиспе написаны на макросах, то это означает что
 классы это более высокоуровненвые конструкции?

если класс Б в оопе унаследован от класса А, значит по твоей логике
класс Б более абстрактен, так? Можеш рассматривать классы в лиспе
как унаследованное от макров. Только вот макры полезные, 
они код генерят. А объекты только мешаюцо.

> классы это более высокоуровненвые конструкции?

классы это никаковоуровневые неконструкции, это стройматериалы для
 консрукций. Классы предполагают ограничения: что часть модели может
 быть обособлена как класс, что у этой части модели есть независимые
 параметры и возможно описать операторы трансыормации, применимые к,
 итд. Для эффективного использования ооп у части единиц модели должны
 иметься общие свойства/операторы итп. Короче это длинная и печальная
 история. Так вот, все эти многочисленные ограничения на большей
 чясти практических задач мешаюцо очень сильно, особенно когда нету
 множественного наследования. У макров таких ограничений нету, посему
 с их помощю при желании можно народить более абстрактные => более
 высокоуровневые конструкции.

 и ещё, это существенно разные вещи - макры и обекты.
 Первое - средство создания кода, второе - представление
 модели задачи. Противопоставлять их друг другу безсмысленно,
 ибо одно не исключяет другого. На практике же, если 
 юзать макросы неоправдано - не юзаеш.
 Если неоправдано юзать обекты - в многих наречиях
 всё равно приходицо.

> Так что ты определись что ты любишь больше, мощные конструкции 
 или высокоуровневые?

А мощность никак с высокоуровневостью в общем случае
 никак не связана. :P

> А какие понятия являются низкоуровневыми?

любая конкретика, не относящяяся напрямую к сути вопроса. В задачае
 про перестановки это привлечения понятия нумерованности, и, как
 следствие, использование индексов.

> Словарь это высокоуровневое понятие? Макросы это высокоуровневое
 понятие? И какой у них уровень высокоуровневости?

Это всё средства. Ими же можно нагенерить и низкоуровневый код на
 лиспе, если умеючи. Пример низкоуровневого кода на лиспе,
 почти буквальная, с минимумом отступлений от, трансляция
 питоньей проги из 
 http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1591778

(defun perm (e)        
    (if (>= 1 (length e))
        (list e)
        (let (
            (f (subseq e 0 1))
            (r (subseq e 1))
            (q nil))
            (dolist (p (perm r))
                (dotimes (i (length e))
                    (setq q (cons (append (subseq p 0 i) f (subseq p i)) q))))
            q)))    

ужоснахъ, да? Это потому что лисп не очень подходит для
 низкоуровневого кода напрямую, вот пипл, привыкший к наречиям
 наподобие васика, уайтспейса, или их помеси питона, нефтыкает.
 Потому что уровни абстракций совершенно разные, а если
 использовать одинаковые принципы построения кода и в лиспе 
 и в васике, лисп конечто будет конкретно отсасывать, ибо нефих.
 

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

>> Классы/обекты более сложная ссущнось чем биты. Зачем привносить сложную, если то же самое можно на асме слабать?

> Не, не так. Нах ваще кампутиры!

Тычё патрикохульствуеш, а Слакварь на где пущять?

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

> а если использовать одинаковые принципы построения кода и в лиспе и в васике, лисп конечто будет конкретно отсасывать

Ну надо же, на пятом году непрерывного срача у лиспоидов таки просыпаются остатки разума...

Бейсик это суть описание алгоритма. Как блок-схема, только текстовая и более приближенная к человеческому языку. А свою очередь алгоритмы эти взяты тоже не с потолка - это "человеческая" логика с поправкой на математику и применённая к компу. Это очень просто и естественно практически для кого угодно, т.е. трудности с реализацией решения той или иной задачи будут исключительно технические. В то время как лисп и ему подобные языки требуют от программиста вывернуть наизнанку и извратить до неузнаваемости логику _у себя в голове_. Что довольно тяжело и далеко не всем доступно. Так вот мне интересно - ради чего надо затрачивать эти самые усилия по изменению логики в голове? Какие преимущества программист получит при решении тех или иных задач? Как тут уже упоминали, и не один раз, покажите где какая-нибудь супер-нужная и полезная программа на лиспе/хаскеле и т.д.?

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

>Как тут уже упоминали, и не один раз, покажите где какая-нибудь супер-нужная и полезная программа на лиспе/хаскеле и т.д.?

http://www.washington.edu/medicine/depts/radonc/research/computing/prism.html

http://www.washington.edu/medicine/depts/radonc/research/computing/screenshot...

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

> у лиспоидов таки просыпаются остатки разума...

Не отчяивайся, Патрик милостив. Возможно когда-нибудь и у вендузятнегоф начнут. Хотя конечно вряд ли у них есь чему, но всё же будем надеяцо...

> текстовая и более приближенная к человеческому языку

более приближенная чем асм?

> "человеческая" логика с

Сыщи выше по тексту проги на лиспе и питоне. Составь текстовое описание того чё оне делают. И потом сравним, какое из их ближе к человечьей логике.

> супер-нужная и полезная программа на лиспе/хаскеле и т.д.?

возми да напишы, кто мешает то?

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

> Бейсик это суть описание алгоритма. Как блок-схема, только текстовая и более приближенная к человеческому языку. А свою очередь алгоритмы эти взяты тоже не с потолка - это "человеческая" логика с поправкой на математику и применённая к компу. Это очень просто и естественно практически для кого угодно, т.е. трудности с реализацией решения той или иной задачи будут исключительно технические. В то время как лисп и ему подобные языки требуют от программиста вывернуть наизнанку и извратить до неузнаваемости логику _у себя в голове_.

...для тех, кто начинал учиться с бейсика/паскаля. Тем - да, надо слегка ставить мозги на место. Другие начинали с sicp - у тех всё в порядке :)

> Так вот мне интересно - ради чего надо затрачивать эти самые усилия по изменению логики в голове?

Не видишь? Я тоже уже не раз говорил - значит тебе и не надо. Ну нафига человеку усилитель+колонки с верхней частотой >20кГц, если он их всё-равно не может услышать?

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

> для тех, кто начинал учиться с бейсика/паскаля

Так вот в том-то и оно, там ЧЕЛОВЕЧЕСКАЯ логика. Нет, понятно что можно привыкнуть к чему угодно, вопрос только в том - зачем?

> Ну нафига человеку усилитель+колонки с верхней частотой >20кГц, если он их всё-равно не может услышать?

1. Оно само такое получается, специально убирать частоты выше 22 КГц наверное дороже/сложнее выйдет.

2. действительно, зачем?

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

> более приближенная чем асм?

Конечно. Какие будут контраргументы?

> Сыщи выше по тексту проги на лиспе и питоне.

Сцылку plz. Там уже чего только не выкладывали...

> возми да напишы, кто мешает то?

Тогда зачем лисп? :)

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

>> более приближенная чем асм?

> Конечно. Какие будут контраргументы?

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

>> Сыщи выше по тексту проги на лиспе и питоне.

> Сцылку plz. Там уже чего только не выкладывали...

сам отлистай

>> возми да напишы, кто мешает то?

> Тогда зачем лисп? :)

лисп чтобы напесать. А вот зачем ананимус?

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

> Вот такое заимплементь на любом низкоуровневом и сравним 
> чё получилось: 
>
> http://www.linux.org.ru/jump-message.jsp?msgid=1587106#1592749 
> раз уж более сложный пример ниасиливаем.

Пожалуйста:

for customer in Cutomer.select(Customer.c.age > 100):
    send_email(cutomer.email,
        subject='Congratulations!',
        body='Dear %s, you won a prize! Call %s.' % 
            (customer.name, company_phone))


Для работы с БД используется sqlalchemy 0.17, в ветке 0.2x это будет
немного по другому

Достаточно высокоуровнево?

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

>> У меня есть три предположения:

> неугодал. У тя есь щё три попытки

И какой правильный ответ?

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

>> 3. Потому что макросы это тру, а классы это быдло-мейнстрим

> Какой-то ты чёрно-белый... :) Ну и "пальцем в небо".

Не, ну ты всё таки покапайся у себя в душе...

И как там в этой причине действительно нет НИ КАПЛИ того, что макросы это труъ, а классы это быдломейнстрим? :-)

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

for ... in ... совершенно необходимо для выполнения задачи? Переменная customer? почему .c. в (Customer.c.age > 100)? Как изменится код если вдрух понадобицо ну left join например?

> Для работы с БД используется sqlalchemy 0.17, в ветке 0.2x это будет немного по другому

Ну, что сам питон ещё не готов для продакшна, мы уже обсуждали. На многих языках промышленного уровня ещё пара лишних действий появицо.

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

> Так вот в том-то и оно, там ЧЕЛОВЕЧЕСКАЯ логика. Нет, понятно что можно привыкнуть к чему угодно, вопрос только в том - зачем?

Ну тогда либо я и ещё многие другие - не люди, либо ты - производитель газировки. Не понятно? Это она для _тебя_ "человеческая". За всех не говори, да? :)

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

> И как там в этой причине действительно нет НИ КАПЛИ того, что макросы это труъ, а классы это быдломейнстрим? :-)

Абсолютно.

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

> for ... in ... совершенно необходимо для выполнения задачи?

Да. В переводе на руский язык это означает вытащить из базы всех клиентов, у которых возраст > 100 и для каждого вытащенног выполнить заданное действие. Не вижу принципиальной разницы от do-select

> Переменная customer? Переменные CustomerName CustomerAddr?

> почему .c. ? Вот тут ты прав, .с. действительно лишнее, Customer.c.age это на самом деле колнка таблицы customers в которой хранятся объекты класса Customer, для которой определены операторы типа >, которые и генерят правильный SQL. Если бы в Питоне были макросы, я бы наверное мог бы написать что-то типа select('age' > 100), но сейчас я этого сделать не могу, т.к. для переменных класса str и int сравнение не определено, а если бы и было определено, оно явно не имело бы никакого отношения к SQL

Лишняя одна буква .c. не катастофа.

> Как изменится код если вдрух понадобицо ну left join например? Не сильно. Типа customer.addr.street

>> Для работы с БД используется sqlalchemy 0.17, в ветке 0.2x это будет немного по другому

> Ну, что сам питон ещё не готов для продакшна, мы уже обсуждали. На многих языках промышленного уровня ещё пара лишних действий появицо.

Вот тут не понял. sqlalchemy это либа написанная на Питоне и для Питона, как раз её существование это очко в пользу того что Питон готов для продакшна.

Ты же в своём примере использовал какую-то либу для работы с БД, для отправки email. Эта же функциональность явно не в ядре Лиспа.

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

>> И как там в этой причине действительно нет НИ КАПЛИ того, что макросы это труъ, а классы это быдломейнстрим? :-)

> Абсолютно.

И что это за причина?

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

> И что это за причина?

В данном конкретном случае (и во многих других, где в лиспе используются макры) - для упрощения как самого кода, так и процесса его создания, отладки и сопровождения.

Только если ты скажешь, что для тебя макры сложнее и, как следствие, это для тебя не причина - я позову инну... ;)

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

> Лично я не вижу необходимости в "междусобойчиках". Лисп настолько
простая штука, как полено, что обсуждать безсмысленно а все проблемы 
решены годы и десятилетия назад. Впрочем иногда не прочь поболтать на 
канале #lisp в irc.freenode.net.

(defmacro test () `(list ,*test*))
(defvar *test* 2)
(test) ; = 2
(defun test2 () (setq *test* 3) (test))
(test2) ; в CMU CL = 2
        ; в CLisp = 3

Кто прав? И почему?

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

А как это у тебя при такой последовательности в CLISP (3) получилось? Получается (2). И в SBCL тоже (2). Поэтому непонятно, что объяснять. И почему. :)

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

У тебя в CLISP получилось (3) потому что ты по случайности передифайнил (defun test2 () (setq *test* 3) (test)) второй раз. А когда она прошла эвалуацию второй раз, то макрос (test) развернулся в (3).

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

Могу тебе только объяснить результат. Ты создал макрос со свободной переменной (небиндиной никаким значением). потом конкретизировал переменную *test*. Теперь ты должен понять, что все, что ты делаешь уже начинает выполнятся, как программа. Ты проэвалюировал марку (test) в первый раз и она у тебя развернулась в код (2), так как на момент эвалюации *test* была 2. Теперь ты дефайнишь test2. На момент вычисления макрос test у тебя уже *конкретизирован*, поэтому (test2) снова будет выдавать (2). Считай, что макрос высекает свой код в камне в соответсвии с окружением на момент вычисления. Но теперь ты присвоил значение переменной (setq *test* 3). Но хочешь ты того или нет, но пока макрос в памяти существует в виде (defmacro test (2)), пока его не перевычислишь. И функция в памяти лежит, как (defun test2 (setq *test* 3) (2)). Теперь опять делаешь (test). Макрос у тебя перевычисляется и получишь (3). Но функция уже высечена в камне, поэтому (test2) выдасть (2). А вот если ты возмешь и опять сделаешь повторно (defun test2 () (setq *test* 3) (test)), то функция высечется уже с новым макросом. И в память разложится, как (defun test2 (setq *test* 3) (3)).

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

Вот тебе наглядно, что происходит с моим комментарием:

Определяем макру, но переменная "висит" в воздухе. Макра будет зависеть от окружающей среды значит :)
[1]> (defmacro test () `(list ,*test*))
TEST

Среда *test* принимает значение 2
[2]> (defvar *test* 2)
*TEST*

Вычисляем макру. Теперь она в памяти превратилась в макру, которая
генерирует код (2), пока не будет перевычислена с новой средой
[3]> (test)
(2)

Определяем новую функцию, в которой часть кода разворачивается макрой.
Макра не перевычисляется. Берется ее текущий код. И все это дело
в памяти висит как (defun test2 () (setq *test* 3) (2))
[4]> (defun test2 () (setq *test* 3) (test))
TEST2
[5]> (test2)
(2)

Но теперь после работы (test2) у тебя новая среда *test* = 3. Определю
новую функцию test3. На момент вычисления она поэтому превращается в 
(defun test3 () (setq *test* 4) (3))
[6]> (defun test3 () (setq *test* 4) (test))
TEST3

Смотрим результаты. 
[7]> (test3)
(3)

[8]> (test2)
(2)

[9]> (test)
(4)

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

Поправлюсь, что везде не (defun test3 () (setq *test* 4) (3)), (defun test3 () (setq *test* 4) (list 3)). Спать хочу потому что. :)

На очевидный твой вопрос, а почему же тогда переменной (setq *test* 3) ты значение присваиваешь, а значение макры следом идущей (test) не изменяется. А я тебе отвечу, что на то она и макра, а не функция. Сначала Lisp формирует код функции, а потом выполняет, а не формирует по мере выполнения. То есть (list 2) подставляется вместо (test) до того, как функция вычисляется.

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

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

(defmacro test (b) `(list ,b))

А функцию определять так:

(defun test2 (a) (setq c (- a 10)) (test (* c c)))

тогда у тебя будет ожидаемое условное ракрытие макроса.

(test2 20)
(100)

(test2 30)
(400)

Спать пошел.

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