[Python][Функциональщина] Медленный не пайтон, а функциональщина

> Мейл давай - покажу на примере.

Уважаемый сэр! Вы дискредитируете саму идею флеймов на лоре! Напишите уж сюда, я думаю, это не только мне интересно.

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

Ясно. Ты или невменяем или троль...

Троль (причем тупой) это мы мальчик. Ты сказал на

То ты бы вкурил, что я писал что питон это универсальный язык с некоторыми элементами функционального.

Следующее:

С этим утверждением не спорю, но ты такого не писал.

Я тебе дал ссылку где есть фразы мной написанная:

Еще раз для тупых: Питон не функциональный язык, он язык универсальный )))

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

Как мне тебя назвать после этого? Не лохом? А как?

Троль (причем тупой) это мы

самокритика это хорошо, самокритику мы любим

> Нет, он реализует унификацию.
match-case в cl-unification реализует унификацию? Тогда я не понимаю, что такое pattern matching...

Можно, но тогда отладка будет сложнее. Не будет универсальной

пошаговой отладки для любых макр.

Что такое «универсальной пошаговой отладки для любых макр»? Чем обычная отладка в CL плоха?

Ну и, главное - за каким хреном

это делать? Зачем себе жизнь усложнять?

С чего вдруг жизнь усложнится то? Как раз наоборот...

Мейл давай - покажу на примере.

Ну, моё мыло несложно при желании найти: archimag@lisper.ru

Напишите уж сюда, я думаю, это не только мне интересно.

присоединяюсь к запросу

>> Троль (причем тупой) это мы

самокритика это хорошо, самокритику мы любим

Верно подмечено, отнекиваться не стану.))) Ну обсуждаемый мальчик, особенно тупой из всех нас здесь похоже.)))

особенно тупой из всех нас здесь похоже

на твоём месте следовало бы быть поосторожней с критическими оценками. в принципе

> Ну обсуждаемый мальчик, особенно тупой из всех нас здесь похоже.)))

Написало нечто, неспособное даже по-русски писать хоть сколь-нибудь грамотно... O tempora, o mores!

> на твоём месте следовало бы быть поосторожней с критическими оценками. в принципе

Да ладно, спорим, кидаемся какашками.) Кстати если поднимешься вверх по постам увидешь, что первым кинул какашку не я. Хотя тупо хотя это все, перекидывание какашками. Но хорошие бугагашки на ночь, это к здоровому крепкому сну.)

>> Ну обсуждаемый мальчик, особенно тупой из всех нас здесь похоже.)))

Написало нечто, неспособное даже по-русски писать хоть сколь-нибудь грамотно... O tempora, o mores!

Я давно слежу за вашими глубокомысленными постами, и не нахожу в них даже годных лулзов. Профессионально мы тоже с вами никак не пересекаемся, чак что в игнор пожалуй. Досвидос!

>Да ладно, спорим, кидаемся какашками.) Кстати если поднимешься вверх по постам увидешь, что первым кинул какашку не я. Хотя тупо хотя это все, перекидывание какашками. Но хорошие бугагашки на ночь, это к здоровому крепкому сну.)

Нуну... неправда. Ты ж еще стал спорить с тем, что реализация питона медленнее хаскеля и что из питона хреновый язык ФП.

> чак что в игнор пожалуй. Досвидос!

Чувствую себя Слоником. Только что-то они уж больно быстро лопаться стали... 8))

> Нуну... неправда. Ты ж еще стал спорить с тем, что реализация питона медленнее хаскеля и что из питона хреновый язык ФП.

ОМГ! Где я спорил что питон быстрее, пруфлин плиз. Где я говорил, что питон лучший ФЯ, пруфлин плиз. Я только писал если сравнивать, скомпилированный хаскель с питоном это некорректно. А то тут пишут в разы. ;)

Короче, что тебе не понравилось. 1) Я писал что питон быстрее хаскела? Гони пруф, иначе ты лох. 2) Я писал что питон функциональный язык? Гони пруф, иначе ты лох. Я писал, что с элементами ФЯ. Ты не согласен?

Но хорошие бугагашки на ночь

ЛОР - это вам не место для бугагашечек. ЛОР - это серьёзный ресурс

>> чак что в игнор пожалуй. Досвидос!

Чувствую себя Слоником.

Чувствуйте, это полезно :)

> ЛОР - это вам не место для бугагашечек. ЛОР - это серьёзный ресурс

А кто спорит, очень-очень серьезный...

> присоединяюсь к запросу

+1

>А defmacro это действительно сахар, который новых принципиальных возможностей в язык не добавляет, просто делает процесс написания кода более приятным и удобным.

А что там у нас с вычислением аргументов функций?

>Гони пруф, иначе ты лох.

«лох»... чувак, так только в 7-ом - 8-ом классе говорят. Исправляйся.

> А что там у нас с вычислением аргументов функций?

А что у нас там? Это вы к чему?

>А что у нас там? Это вы к чему?

Это я к тому, что аргументы у функции всегда вычисляются. А аргументы макроса — нет.

Не говоря уже о том, что результат работы макроса — это код, который будет прозрачно скомпилирован. Результат работы eval — это результат работы eval.

>Где-же love5an?

он технически грамотный, в отличии от...

>Результат работы eval — это результат работы eval.

И ведь не поспоришь!

он технически грамотный, в отличии от...

невменяемость невменяемости рознь

> Не говоря уже о том, что результат работы макроса — это код,

который будет прозрачно скомпилирован. Результат работы eval

 — это результат работы eval.

В результате вызова eval код компилируется? Или как-то непрозрачно компилируется? Или вы утверждаете, что с помощью макросов можно добиться чего-то, чего нельзя добиться с помощью eval? В чём мысль то?

>В результате вызова eval код компилируется?

Разве функция из (eval ,(defun ...)) будет скомпилирована при comile-file?

Или вы утверждаете, что с помощью макросов можно добиться чего-то, чего нельзя добиться с помощью eval?

Да. Hint: AND не может быть реализован как функция.

>Или вы утверждаете, что с помощью макросов можно добиться чего-то, чего нельзя добиться с помощью eval

это так и есть. вроде бы лексические биндинги евал не видит, и так на каждом уровне вложенности будет.

> Разве функция из (eval ,(defun ...))

будет скомпилирована при comile-file?

Во-первых, какая разница? А во-вторых см. конструкцию eval-when, которую я использовал в примере выше.

Да. Hint: AND не может быть реализован как функция.

Много чего не может быть реализовано как функция. Но при желании можно добиться такого же эффекта с помощью последовательного вызова eval для каждого элемента списка параметров AND.

> это так и есть. вроде бы лексические биндинги евал не видит,

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

Можно пример кода? а то я плохо понимаю мысль.

(defvar *x* '(+ a 2))

(defun tst ()
  (let ((a 1))
     (eval *x*)))

в теле будут невидны лексические биндинги из внешней формы, отсюда большие сложности с аналогами макросов do и with-* будут.

Пожалуйста, перепишем пример так:

(defvar *x* '(+ a 2)) 
 
(defun tst () 
 (eval `(let ((a 1)) 
           ,*x*)))

Проблема решена.

Я не говорю, что макросы не нужны. Макросы потрясающе удобная вещь, но они не делают ничего магического, всё это можно сделать с помощью eval, муторно и неудобно, но работать будет.

>> Почитай R5RS. Удобная штука.

Scheme не люблю.

Анонимус (и я) обратил внимание на конкретную фичу. Язык в данном случае не играет ни какой роли.

>Проблема решена.

нет. тут уже другая семантика. с do и макросами with-* не прокатит.

но они не делают ничего магического

делают.

всё это можно сделать с помощью eval

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

> нет. тут уже другая семантика. с do и макросами with-* не прокатит.

Что значит другая семантика? Поставив eval на верхнем уровне всегда можно добиться нужного эффекта. А макросы with- обычно достаточно тривиально переписываются как функция с помощью lambda, мало того, зачастую именно так они и реализуются.

делают.

Угу, SBCL не иначе, как с помощью заклинания компилируется. А всем правит верховный маг.

концепция же макросов предполагает большее.

Ну что большее то? Что кроме синтаксического сахара предоставляются макросы?

> Анонимус (и я) обратил внимание на конкретную фичу.

Язык в данном случае не играет ни какой роли.

И? Вы предлагаете мне сейчас идти изучать R5RS?

>Что значит другая семантика

лексический биндинг. в макросе он будет работать, а с евал нет.

Поставив eval на верхнем уровне всегда можно добиться нужного эффекта.

он там и так стоит. хотя, ждем if и do через eval без макросов и соответствующих спец. операторов.

А макросы with- обычно достаточно тривиально переписываются как функция с помощью lambda, мало того, зачастую именно так они и реализуются.

голая лямбда видит лексические переменные из внешних блоков. только без макросов это уже не будет языковой конструкцией. можно сразу к гото переходить тогда. какой-то нелепый аргумент «замена макрам - копипаст».

Что кроме синтаксического сахара предоставляются макросы?

ну, в cl пусть будет сахар, как измениться от этого нижележащая концепция?

Неважно декораторами или нет.

Декоратор точно не может сделать объект неизменяемым. Декоратор это сахар для следующей ситуации:

def func(params):
   pass
func = decorator(func)

это эквивалентно:

@decorator
def func(params):
    pass

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

var = 'value'

писать

super(ImmClass, self).__setattr__('var', 'value)

И нахрена оно такое надо?

> лексический биндинг. в макросе он будет работать, а с евал нет.

Ключевой вопрос: какова природа лексического биндинга. defvar и defparameter порождают динамические переменные, основным инструментом для создания лексических переменных является let. Если eval находится внутри let, то могу быть проблемы. Т.е. всё, что нужно сделать, это поместить let внуть eval.

он там и так стоит. хотя, ждем if и do через eval

без макросов и соответствующих спец. операторов.

Ну, if это вообще специальная форма и реализуется без макросов (как раз недавно выяснял подробности реализации в SBCL), угу. Но разве я говорил, что do можно реализовать без макросов? Добиться точно такого же синтаксиса без макросов нельзя, но вполне можно эмулировать аналогичное поведение с помощью других средств. Это будет не так удобно, но работать будет.

какой-то нелепый аргумент «замена макрам - копипаст»

Не понял мысли, ничего подобного я не говорил.

ну, в cl пусть будет сахар, как измениться от этого

нижележащая концепция?

Концепция макросов никак не изменится, изменится восприятие. Кто-то упорно распускает слухи, что главной фишкой CL являются макросы, что вся суть CL в макросах. Что совершенно не так. Мощь макросов обусловлена мощью всех остальных частей Common Lisp, а макросы всего лишь предоставляют очень удобный интерфейс к и без того существующим возможностям языка.

Это зависит от задачи. Макры нужны для реализации DSL, компилятор которого в Лисп — просто набор макросов. То есть, при необходимости доля макросов может быть и 100%.

Функции не могут дать нужного синтаксического сахара. В том же Хаскеле для списков введен ad hoc специальный синтаксис конструктора и четыре способа работы. В Лиспе это же делается через стандартный механизм.

Хороший DSL проще и понятнее Лиспа. Ну это типа того, что C понятнее того же макроассемблера :-). А если он еще при этом на самом масме писан...

> Добиться точно такого же синтаксиса без макросов нельзя, но вполне можно эмулировать аналогичное поведение с помощью других средств. Это будет не так удобно, но работать будет.

Должно быть, и defmacro, и macrolet сами написаны на более примитивном подмножестве лиспа. Выходит, можно эмулировать. Быть может, даже eval-when и тот построен из примитивов. Хотя в лиспе не силен, чтобы утверждать.

А макросы удивительная вещь! Сочинил тут недавно небольшой файлик на 20 килобайт. Там ни одной функции - одни макросы! Вот так :)

>Как это все делать функциями, и зачем - я не знаю и мне лень думать об этом.

Если бы это было C/C++ то такую задачу тоже можно было бы решить через макросы, а можно и через inline. Разница только в том что на inline я могу получить указатель и использовать в дальнецшем, а на макрос нет.

Как это сделать функциями так, чтобы это было еще и красиво - я не имею понятия.

Ну красота это субъективно, мне вот XML, JavaScript и Haskell нравятся.

И как это сделать функциями так, чтобы это не тормозило(реалтайм-рендеринг - не хухры-мухры) - я вообще совершенно не врубаюсь.

А почему это делать именно на данном языке?(понимаю что это практичней, но всё же)

PS

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

Шаблоны в C++ выделяются хоть угловыми скобками, в этом их преймущество перед максосами, но не смотря на это они тоже говно.

> неотличимость в синтаксисе вызаовов функций от подстановок макросов, собственно как и в C/C++

еще один повод пользоваться нормальными IDE с нормальной подсветкой

>Eval выполняется в рантайме. Макросы раскрываются во время компиляции. Всё ещё не видишь разницы?

Когда я замечаю что в моём коде появляются однотипные повторяющиеся фрагменты, начинаю думать как эето дело упростить. Иногда хочется взять и сгенерировать это дело как строку, а потом скормить eval. Но это может означать только что чтото делается не так. После частичной смены архитектуры приложения ВНЕЗАПНО выясняется что такие замены делать не обязательно, но речь не об этом. Речь о том что eval и макросы это средсва создания костылей и они вполне взаимозаменяемы.

>> неотличимость в синтаксисе вызаовов функций от подстановок макросов, собственно как и в C/C++

еще один повод пользоваться нормальными IDE с нормальной подсветкой

А можно список таких IDE?

> Если бы это было C/C++ то такую задачу тоже можно было бы решить через макросы, а можно и через inline. Разница только в том что на inline я могу получить указатель и использовать в дальнецшем, а на макрос нет.

а еще разница в том, что аргументы инлайн-функции вычисляются перед ее вызовом, да. так что нифига не равнозначные вещи

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

наоборот это и хорошо в лиспах — любая придуманная языковая конструкция органично вписывается в язык и сочетается с остальными

Шаблоны в C++ выделяются хоть угловыми скобками, в этом их преймущество перед максосами

фееричный бред

> Должно быть, и defmacro, и macrolet сами написаны на более

примитивном подмножестве лиспа

Не понятно, как трактовать данное утверждение. В реализации SBCL все возможности языка используются по полной, ведь для его компиляции уже нужно иметь полноценный Common Lisp.

Visual + Assist, NetBeans, Eclipse, XCode

> Если бы это было C/C++ то такую задачу тоже можно было бы решить

через макросы, а можно и через inline

Ну, как говорится «через надуманную аналогию можно доказать всё что угодно» (с)

Разница только в том что на inline я могу получить указатель и

использовать в дальнецшем, а на макрос нет.

Конечно, ты не можешь получить указатель на макрос, в CL вообще нет указателей. Что ты хотел этим сказать? Если ты так о шаблонах в C++, то можно пример inline решения для std:vector? В С++ шаблоны являются совершенно отдельным языком и их нельзя, в отличие от CL, никак эмулировать с помощью других средств языка.

Мне в лиспах не нравится только неотличимость в синтаксисе вызовов

функций от подстановок макросов, собственно как и в C/C++.

Ну, твоя «уникальность» бросается в глаза ;)