Comments 35
Если я правильно понял, то Вы делаете стековую виртуальную машину, что очень походит на виртуальную машину луа.
Может проще писать на луа, который к тому же на порядок быстрее интерпретатора питона?
Не по теме: с красно-зелёными кубиками офигенная залипалка! Хочу такую на фон!
согласен, тоже залип.
Но!..
Красно-жёлтые же?
(#d53031 называется клубнично-красный, а #bbcc33 - нечто между
"блестящим жёлто-зелёным" и "грушево-зелёным", дальтоник что ли я?)
Вполне возможно, что у меня amoled привирает
блестящим жёлто-зелёным
грушево-зелёным
Т.е. два цвета в названиях которых оба раза встречается слово "зелёный" это таки жёлтый? )
Да что вы начали-то. Синее платье, очевидно же :)
Эх-х-х, Сарказм - сарказм:
Вот видишь начало статьи:
... избавляемся от переменных
Насколько сложные программы вы сможете написать на питоне, не пользуясь в принципе переменными
и ты думаешь: ДА! ЭТО ОНО!! Как круто, что кто-то озаботился!!!
И тут следующая фраза
за исключением пары глобальных массивов
вот прямо всё ломает. Зачем так издеваться над людьми?
Если уж заявили программы без переменных - нужно соответствовать!!!
Уточнение: есть задачи на написание кода, который не пользуется ОЗУ. И там пока всё без затей: пишут на ассемблере. Написать код на питоне, который не пользуется переменными ... то есть вообще не пользуется - как задачка?
Ваша задача не имеет решения в общем случае.
Уважаемый Haqreu!
Многие задачи не имеют решения в общем случае. Например, валидация кода на завершение, отсутствие крэша. И всё равно их пытаются решать: статические анализаторы и т.п. Поэтому отсутствие решения в общем случае - ну так себе аргументик.
Кроме того, у вас под именем подпись:
Довожу здравый смысл до абсурда
Пардонь-те, Задачка недостаточно абсурдна?
Уточнение: есть задачи на написание кода, который не пользуется ОЗУ. И там пока всё без затей: пишут на ассемблере.
Программирование на ассемблере не означает, что ОЗУ не используется. Не сильно много я видел программ на ассемблере, котороые не пользовались бы стеком...
К сведению - в 90-х были такие приборчики, назывались АОН (автоматический определитель номера). Большая часть из них была сделана на Z80 без установки оперативной памяти. только с ПЗУ.
Doom сумеете на АОНе запустить? :)
Мы ж тут, вроде, про компилирование и запуск произвольных программ говорим, а не про примитивный дешифратор.
Большая часть из них была сделана на Z80 без установки оперативной памяти
В АОНах на Z80 была или 537РУ10, или РУ17. Были модели на 16C7* например – там да, отдельного ОЗУ не было, потому что маленькое ОЗУ прямо в самом микроконтроллере.
Программирование на ассемблере не означает, что ОЗУ не используется. Не сильно много я видел программ на ассемблере, которые не пользовались бы стеком
Здесь ключевой момент в отсутствии ОЗУ, а использование ассемблера это следствие. И да, стеком не пользуются. Пытались писать такие вещи на чистом C и не зашло: как Вы уже отметили, без стека мало кто может.
Однако такая программа (блок кода, который работает без использования ОЗУ) есть в подавляющем большинстве современных компьютеров. Очевидно, этот код занимается инициализацией ОЗУ. В архитектуре x86 это кусочек BIOS-а.
Предлагаю к данной главе "задачу со звёздочкой": реализовать хвостовую рекурсию.
Edit: оптимизацию хвостовой рекурсии.
Кстати, вопрос. Как считаете, код факториала, что я привёл в этой статье, это хвостовая рекурсия или нет?
Нет, конечно. Ведь после рекурсивного вызова нужно выполнить умножение.
Именно в этом и вопрос. Насколько сложно автоматически привести код к классической хвостовой?
Хороший вопрос, жаль, моей квалификации не хватит, чтобы на него ответить.
Тут недавно кто-то выкладывал цикл статей по теории оптимизирующих компиляторов, может быть, на этом уровне найдётся пример оптимизации, преобразующей рекурсивный вызов f(n) в рекурсивный же вызов f(acc,n) и разворачивающей, где надо, цепочку вызовов.
Но не уверен, что такая оптимизация справится с более сложными задачами. Как пример – берём наивную рекурсивную реализацию qsort. Там есть хвостовой вызов, но фокус в том, что из двух вызовов хвостовым может быть только один, и чтобы минимизировать использование стека – нужно выбрать, какой из двух вызывать рекурсивно (тот, что для меньшей части массива), а какой подвергнуть TCO (тот, что для большей).
Тут недавно кто-то выкладывал цикл статей по теории оптимизирующих компиляторов
Ссылку в студию!
Да, оно самое.
Я, честно говоря, увидев ваше "избавляемся от переменных", ожидал увидеть переход к SSA и далее к чистым функциям, и не понимал, как это укладывается в выходные)))
Вроде в соседней ветке вручную договорились начинать. Студентам можно главу SICP 1.2.1 показать для осмысления.
Руками или сразу в компиляторе? Если сразу в компиляторе, то это тема для отдельного разговора, см. предпоследний раздел оглавления.
Прекрасные статьи!
В предыдущей статье есть пара ошибок. Вы сказали следующее:
А случилась у нас ошибка компиляции, причём именно компиляции, а не вывалилось во время исполнения.
Это неправда. Оно вывалилось как раз во время исполнения. Компилятор питона не умеет отлавливать подобные вещи.
А ещё в питоне ключевого слова local
нет и никогда не было.
Компилятор за выходные: избавляемся от переменных