Далее, зачем они определяют процедуру invert-input прямо внутри вызова inverter? Ведь она же будет заново создаваться при каждом вызове!

Ну она как бы на input замыкается, так что смысла выносить её за пределы функции нет. Можно было бы заменить её на обычную лямбду, но тут уже дело вкуса.

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

Зачем? Элементы не имеют какого-то (наблюдаемого) состояния. Их как раз можно рассматривать как функцию с аргументами (входные провода) и возвращаемым значением (комбинация выходных проводов). В отличие от проводов, по которым в любой момент времени а) течёт ток; б) не течёт ток.

Сейчас на курсере, кстати, идёт курс nand2tetris, там вкратце рассматривается принцип работ логических элементов, если он тебе непонятен.

Следующий такой топик в Development я просто снесу.

А тут-то он нафига? Вполне по тематике девелопмента.

Вполне по тематике анонiмуса.

Интересно, у него хоть скор есть на толксы?

Хотя нет, не интересно.

Хоспаде, убейте его уже.

Зачем? Он же опять зарегистрируется.

function inverter(input, output)
    local function invert_input()
        local new_value = not get_signal(input)
        after_delay(inverter_delay, function ()
            set_signal(output, new_value)
        end)
    end
    add_action(input, invert_input)
    return "ok"
end

function inverter(input, output)
    add_action(input, function ()
        local new_value = not get_signal(input)
        after_delay(inverter_delay, function ()
            set_signal(output, new_value)
        end)
    end)
    return "ok"
end

function inverter(input, output)
    input:add_action(function ()
        local new_value = not input:get_signal()
        after_delay(inverter_delay, function ()
            output:set_signal(new_value)
        end)
    end)
    return "ok"
end

Вроде все то же самое, а как читается по-разному, имо. Со второй лямбдой в лиспе был бы совсем кошмар.

ps. и самопальный синтаксис:

function inverter(input, output)
    input:add_action(\{
        local new_value = not input:get_signal()
        after_delay(inverter_delay, \{ output:set_signal(new_value) })
    })
    return "ok"
end

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

(define power-iter (lambda (a n acc) (if (= n 0) acc (* a (power-iter a (- n 1) acc)))))
(define power (lambda (a n) (power-iter a n 1)))

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

Нет, не добрался.

Почему нет?

Потому что в power-iter рекурсивный вызов не хвостовой.

Мне казалось, что хвостовой… А тут обычная рекурсия:

(define (power a n) (if (= n 0) 1 (* a (power a (- n 1)))))

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

Ну она как бы на input замыкается, так что смысла выносить её за пределы функции нет.

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

Зачем?

Просто так легче думать, чтобы не путать отображение с состоянием. К тому же, если бы мы переносили это например, на гуй, мы могли бы взять все компоненты as is и перенести на монитор, а так — придется извращаться. Короче, не слишком красиво это, ИМХО. Компонент должен быть компонентом, глаза режет от этого несоответствия. Потом могут возникнуть проблемы масштабирования.

После возврата из рекурсивного вызова power-iter выполняется ещё и умножение результата на a → значит вызов не хвостовой (необходимое условие для хвостовой рекурсии — чтобы рекурсивный вызов был последней операцией, которая выполняется в функции).

(define power-iter (lambda (a n acc) (if (= n 0) acc (power-iter a (- n 1) (* a acc)))))

Сделай трассировку ((trace power-iter)) и сравни результаты для обоих вариантов.

ИМХО OPINIONATED ИМХО ИМХО…

Ладно.

Нет, я уважаю Ваше мнение, знаю, что Вы действительно разбираетесь в программировании, просто вот я так думаю:). Из-за такого подхода, мне кажется, код полон тавтологий. Например, провод у нас имеет состояние, если бы инвертор был связан с конкретными проводами, нам не понадобилось бы эти обвязки, можно было бы писать просто что то типа insertor.invert. Я когда разберусь полностью с этой главой, постараюсь реализовать это по-другому, в pure-OOP стиле, поглядим что получится:)

https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Tracing.html https://www.gnu.org/software/guile/manual/html_node/Using-Guile-Modules.html

ps. и самопальный синтаксис:

Я бы, наверное, это вообще сделал объектом, жестко связанным, он так и просится тут. Например, на Io что-нибудь такое:

Invertor := Object clone do(
  run := method(output signal = input signal not)
)

invertor := Invertor clone do(input := wire1; output: wire2)

А я думал, что главное, чтобы промежуточные power-iter не накапливались в памяти…

У тебя там получается, что твой процесс итеративен, но не хвосто-рекурсивен. Это оптимизация вручную. А хвостовую рекурсию разворачивает сам компилятор.

Компилятор? Я это сам написал…

Ведь она же будет заново создаваться при каждом вызове!

ты в профилировщике это уже проверил?

а че там проверять? это и так видно. Возможно конечно, что компилятор это оптимизирует, но задача учебника показывать основы, а не финты ушами со стороны компилятора.

заметь что на половину его вопросов у уважаемых программистов из /development обычно нету ответа. Когда начинается обсуждение, у половины случается обострение Даннинга-Крюгера, с комментариями типа «ты идиот». А когда те же вопросы им будут задавать на собеседовании, все они обосрутся, потому что никогда не задавались такими вопросами

олсо, совершенно непонятно, как посетители Толксов куда ты переместил этот топик (которые не все программисты) смогут ответить на вопрос о деталях реализации sbcl и lispworcs. Таких людей три с половиной штуки, например, Лавсан и АлексОтт

вот ты знаешь, как оптимизируется этот случай?

(у меня есть ряд совершенно таких же вопросов по java, но они не задаются, просто потому что как деть ясно, что в /development никто не знает на них ответа :()

«Преждевременная оптимизация — корень всех зол.»

— Дональд Кнут, статья «Structured Programming with go to Statements» в сборнике «Computing Surveys» (Vol. 6, № 4, декабрь 1974, стр. 268).

Я просто уверен, что сам ты не пытался провести элементарные перфоманс тесты этого куска. И если я тебе сейчас скажу, что ты не прав, и видно что оно оптимизируется, тебе даже ответить-то будет нечего. Позорище :)

спасибо за поддержку:)

вот ты знаешь, как оптимизируется этот случай?

Нет. И мне плевать. Я просто ассенизатор.

P.S. Найти в результате жизнедеятельности анонiмуса вопрос о деталях реализации lispworcs (что это такое, кстати?) - знак мастерства. Хорошо, что я не снес топик.

это http://www.lispworks.com/ напечатанный с опечаткой) почти стандарт в лисповском мире. Но это платная проприетарщина, для некоммерческой(!) разработки стоит больше косаря евро, для коммерческой начиная с 4 косарей евро, так что непонятно стоит ли зашквариваться об такой ад.. но лисперы едят и нахваливают

А я думал, это клан орков.

Либо я чего-то упускаю, либо вы оба наркоманы. Чему там оптимизироваться, если иннер функция захватывает контекст. Алсо, «создание функции» это не какой-то сложный механизм, а ни что иное, как выделение структуры с двумя членами — собственно указателя на функцию и массива захваченных переменных, обычный конс и не более (без всяких оверпарсингов овер-read'ов). Если бы тут был проброс сквозь еще один уровень вложенности, то можно было бы порассуждать, какую схему захвата использует реализация — флаттенинг, иерархию контекстов, или вундервафлю местного разлива — но его тут тупо нет. Нет никакого оверхеда, потому что альтернатива — создать контекст самому и таскать его руками рядом с функцией, пока та не помрет.

если иннер функция захватывает контекст.

причем тут это?

«создание функции» это не какой-то сложный механизм,

тем не менее это дурной тон

Опять убейте.

Если это экстраполировать на ООП-стиль, тут сразу бросается в глаза, это равноценно тому, что вместо

Input := Object clone do(
  input ::= nil
  output ::= nil
  create := method(input, output,
    self clone setInput(input) setOutput(output)
    invert
  )
  invert := method(bla-bla)
)

Input := Object clone do(
  input ::= nil
  output ::= nil
  create := method(input, output,
    self clone setInput(input) setOutput(output)
    invert := method(bla-bla)
    invert
  ) 
)

Input/Inverter

//fix

если иннер функция захватывает контекст

А то что в схеме функции не могут захватить динамический контекст, это опять же проблема их недоязычка, он, же, один из авторов, Сассман, его и создал. Если ЯП у него кривой, это не значит, что надо студентам втирать говнопаттерны, пусть страдает, пробрасывает все явными параметрами. А то ведь хотят и рыбку съесть, и на х сесть.

В этом случае ты явно создаешь контекст-инвертер и таскаешь его, хотя внутри setInput() дело облегчается неявным селфом. Маллок так или иначе происходит, кроме случаев, когда конпелятор так крут, что может выоптимизить объекты на стек, но я в это не верю (а если так, то ему ничего не стоит и замыкания лифтануть, верно?). В оригинале же инвертер не имеет связанного контекста, и он добавляется по мере необходимости в сам input (add_action) и ранлуп (after_delay). Таким образом, оригинал аналогичен первому, а не второму коду из последнего коммента. К тому же, если посмотреть внутрь method, то там асинхронка after_delay, и инвертер также захватится на это время, причем целиком, а не только в части output, хотя я наврал про «их тут тупо нет», output захвачен сквозь invert(), поэтому равнозначно. Ты просто превратил два замыкания внутри халявной функции в обьект-контекст с методом и одно замыкание над ним, ничего принципиально не поменялось.

дурной тон

Боюсь у данной темы слишком маленькая аудитория, чтобы можно было определять, что есть дурной тон, а что «мейнстрим и бест практис». Так что это вкусовщина.

в схеме функции не могут захватить динамический контекст
динамический

Не понял, что именно ты имеешь ввиду. +Судя по примеру все они могут.

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