Ну а как в целом описать процесс получения бинаря?

А зачем?

Всё это происходит как происходит — можно копаться в исходниках за подробностями, SBCL представляет из себя лисп-среду в которой полно всего, помимо непосредственно макро-экспандера, компилятора в IR1 и т.д. до машинного кода.

Компиляция макросов и «базового» лиспа (и что-то мне подсказывает, что понятие неформализовано)?

Понятие базового лиспа который остаётся после раскрытия макросов прекрасно описано в стандарте (и CLHS). И SBCL после раскрытия макросов и своих собственных макро-подобных определений занимается его компиляцией — не будь ясно что из себя представляет этот базовый лисп, непонятно было бы как составлять IR1.

В любом случае, выхлоп «компилятора» не отпускается в свободное плавание, а обрабатывает вход под чутким контролем образа.

Компилятор там обычный. Ну и везде так, то есть в любом рантайме оснащённым компилятором (JVM, .NET, Cling).

А зачем?

Очевидно зачем: чтоб прояснить суть определений компилятор/интерепретатор.

Компилятор там обычный. Ну и везде так, то есть в любом рантайме оснащённым компилятором (JVM, .NET, Cling).

Про компилятор никто не спорит. А вот значение рантайма, не уверен, что одно и то же (имхо наличие его принципиально, а jvm/.net + vm / vm + gc - несколько на другом уровне).

Так в контексте ваших определений pypy - _компилятор питона_? Если нет, то в чем принципиально отличие от sbcl.

Очевидно зачем: чтоб прояснить суть определений компилятор/интерепретатор.

Так они и так ясны :)

Про компилятор никто не спорит. А вот значение рантайма, не уверен, что одно и то же

Ну если с компилятором всё понятно, то что ещё нужно? А VM/рантайм/железо это уже на тему выполнения (интерпретации в широком смысле).

Я как-то не вижу чем рантайм CL принципиально отличается.

Так в контексте ваших определений pypy - _компилятор питона_?

Я про него ничего не знаю.

Так они и так ясны :)

Так для себя же)

Я как-то не вижу чем рантайм CL принципиально отличается.

Тащит туда все, что было необходимо для компиляции. Аппелируя к: compilation : SourceLanguage -> TargetLanguage — чистая функция, есть соответствие. Если в рантайме в общем случае необходим(или ошибаюсь?) вызов компилятора или работа в режиме интерпретатора, то получается, что изначально была, по-крайней мере, _не полная_ компиляция.

Тащит туда все, что было необходимо для компиляции.

Ну как и любой JIT? Компиляция в рантайме.

В CL раскрытие макросов, то есть произвольный пользовательский код входит в компиляцию, так что и его нужно тащить, но на это нужно смотреть как на написание этим произвольным кодом базового лиспа (по идее это должна быть честная пре-трансляция, то есть вполне предсказуемая, просто доопределяемая) который потом подвергается обычной компиляции. Где-то ещё тоже можно (хотя практически сложнее) написать произвольным кодом базовый код и подсунуть его компилятору в рантайме (через его API, как Cling, например, использует библиотеки Clang и LLVM).

compilation : SourceLanguage -> TargetLanguage — чистая функция, есть соответствие

Это упрощение, но у классической компиляции принцип примерно такой.

то получается, что изначально была, по-крайней мере, _не полная_ компиляция

Не очень понял. Вызов compile когда он происходит вполне полный, просто целиком CL это не только компилятор, но среда, ну как обычная ОС — можно в REPLе вызывать компиляцию сколько хочешь, писать новые программы, в т.ч. программы которые вызывают компилятор, вызывают новый сеанс REPL-а и т.д.

Вызов compile когда он происходит вполне полный, просто целиком CL это не только компилятор, но среда, ну как обычная ОС — можно в REPLе вызывать компиляцию сколько хочешь

Для нормального понятия компиляции существует понятие бинарного (выполняемого) кода, который может выполняться без наличия компилятора. UNIX тоже среда, но UNIX без компилятора Си может успешно работать. Может ли работать исполняемая среда Common Lisp без компилятора (либо интерпретатора) Common Lisp?

Если «обычная ОС» будет требовать наличия компилятора для функционирования, то я буду считать, что либо «ОС» не до конца скомпилирована, либо «компилятор» на самом деле интерпретатор (например, bash и perl технически компилируют большую часть в память, но по использованию являются интерпретаторами, так как не могут сохранить результат в бинарный файл)

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

а собственно, пример можно расписать? а то непонятно:

если уравнение диофантово, то мы тупо можем перебрать остатки, по случаям. использовать признаки делимости, сократить все варианты комбинаций в переменных под «остатки по модулю p_i», перебрать все комбинации от 0 до p_i-1.

прогнать все такие варианты остатков, перебрать все варианты максимумов.

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

что-то особо не вижу проблемы.

а зачем мне решение? Ты просил код, а не решение.

Ну а откуда ты возьмешь код, если у тебя нету решения? Смотри, есть функция f, она принимает некоторое число и возвращает код. И этот код f(n) идет на евал. Ты не знаешь заранее какое у тебя n (это решение). Как ты получишь код, который идет на евал, до того как получишь решение?

эквивалентными преобразованиями, так же как работает суперкомпиляция // ваш К. О.

сгенеррится сам через время равное ∞.

Что эквивалентно тому, что он никогда не сгенерится, ок.

а что гарантирует что процесс вычислений сходится? вот в Н-моделях например — сходится к решению.

курс по метакомпилятору META II

Что-то я не понял? Он чем-то принципиально отличается от yacc (и прочих генераторов компиляторов по грамматике)?

Из интерпретатора компилятор эта штука делать не умеет (или покажите, куда ему скормить bash?).

Этот поток _можно_ сохранить

Сохрани, пожалуйста. Или, по крайней мере, опиши метод сохранения.

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

Он чем-то принципиально отличается от yacc (и прочих генераторов компиляторов по грамматике)?

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

получается такое «преобразование неподвижной точки», которое затем допиливается до нужного языка.

Из интерпретатора компилятор эта штука делать не умеет (или покажите, куда ему скормить bash?).

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

Нету никаких входных данных. N - максимальное решение уравнения.

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

А код обрабатывающий сам eval — вполне конечен, и не очень большой.

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

метациклические вычислители отменили? тот же Eval-Apply это две стадии, с одной откладываются на другую, с другой — на первую. и всё прекрасно компилируется в 2 стадии eval-apply. почему с евал1-евал2-апплай1-апплай2 вдруг проблемы?.

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

А откуда ты возьмешь n?

символьно вычисляя и эквивалентно преобразовывая.

«Программой» называется текст определенного вида. «текстом» называется конечная последовательность символов определенного языка. КОНЕЧНАЯ. Бесконечная последовательность символов не является ни текстом, ни программой.

Бесконечная последовательность символов не является ни текстом

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

«Программой» называется текст определенного вида. КОНЕЧНАЯ.

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

то, что есть необратимые явления с ростом энтропии. И ты с этим ничего не поделаешь. А если твоя модель этого не описывает, то это просто дерьмовая модель.

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

я тут тебе ниже философское обоснование ща накатаю.

Ну и какие проблемы? Пусть существует, построить (а тем более использовать!) его все равно нельзя.

его не может существовать, т.к. пространство не имеет «разрывов». Во всяком случае, мы этого не наблюдаем. Потому удвоение сферы невозможно. И способа тоже не существует. Т.е. он существует только если эта твоя сфера представляет собой множество точек мощности алеф1 над ℝ. Подчиняющихся условию x²+y²+z²=1. Вот тогда её можно «разобрать» и «собрать» из кусочков две сферы. Но это дефект модели. Тоже самое, что танк можно растоптать ногами. Можно. Если этот танк — бумажная модель.

возьмём интерпретацию Хью Эверетта (Мультиверс) квантовой механики.

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

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

Следует отметить, что вся информация о волновой функции электрона, доступная до проведения опыта, не может дать ответ на вопрос: «Какая именно конфигурация будет наблюдаться в процессе эксперимента?». С точки зрения математики, подобное нарушение гладкости волновой функции не следует из свойств уравнения Шредингера.

(а ты говоришь --не было, ни единого разрыва... вот же они)

Эверетта смущала копенгагенская интерпретация, в которой получалось (как будто что-то плохое) дискретность времени и пространства: при измерении волновая функция коллапсирует, то есть реальность существовала только между измерениями.

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

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

поэтому он просто смотрел на формулу, и подумал, а что если сохранить непрерывность. и что если первична волновая (универсальная) функция, а не то, во что она сколлапсировала.

он показал, что волновая функция обладает такими свойствами, что можно понимать измерение как ветвление универсальной волновой функции, или как форк реальности, когда на каждое действие-измерение возникает альтернативная вселенная из мультиверса (многомирья):

«С точки зрения теории все элементы суперпозиции (все “ветви”) “реальны” и ни одна из них не более “реальна”, чем остальные».

он показал (врезка), что для опытов А и В с вероятностями 0.8 и 0.6, например, т.е. такими что сумма их квадратов =1 (=0.64+0.36), можно выразить всё то же самое, что и в копенгагенской интерпретации.

и организовать таким образом свою собственную причинность (в одной конкретной вселенной из всего мультиверса): цитата:

«Эверетт предположил, что частицы вселенной в совокупности можно уподобить вычислительной системе, или в его терминологии «сложному автомату»»

UNIX без компилятора Си может успешно работать. Может ли работать исполняемая среда Common Lisp без компилятора (либо интерпретатора) Common Lisp?

Может (точка входа и шейкер, или по типу LLVM+Clang/GHC API с доступной разделяемой либой компилятора и т.п.), если нужен REPL/интерпретация — пусть будет интерпретатор (как bash и т.п.), если нужен REPL с JIT/компиляцией — пусть будет компилятор (аналогично с UNIX).

Если «обычная ОС» будет требовать наличия компилятора для функционирования, то я буду считать, что либо «ОС» не до конца скомпилирована, либо «компилятор» на самом деле интерпретатор

Ну ОС это типа рантайм, она уже скомпилирована нормально и работает, требует наличия компилятора в машкод не она, а возможности (хм, собственно, компиляции чего-то в машкод, я не пойму что тут обсуждать :)).

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

составимость сфер означает, что можно эти события разобрать и собрать другим образом, получив ДВЕ таких «вселенных» для многомирья: в одной сфера собрана из одних событий и вероятностей, в другой — из других таких событий.

в интерпретации Эверетта все ветви реальности равновероятны и вселенные не общаются между собой — после форка у них общая только история.

ИМХО, требование «не общаются» лишнее — просто сложнее придумать такую среду, метациклический вычислитель, в пределах которой общение возможно.

змея поедает свой хвост, ага.

ИМХО, форканье реальностей в мультиверсе Эверетта можно более логично понимать как «многомерное время».

ну например, мы можем считать что t = (t1) = (t1,0) = (t1,0,0) = (t1,0,0,0) = ... = (t1,(0)) = (user_time,system_time,idle_time, io_time, ...)

ИМХО, такое векторное многомерное время также ничему не противоречит: ни исходному квантовому уравнению, ни его Эвереттовской интерпретации.

логично предположить, что существуют эквивалентные представления: (t_1',0) = (0,t_2') для каких-то там «двойственных», («сопряжённых», «запутанных») t_1',t_2'.

в итоге, интерпретация Эверетта задаёт не линейную одномерную «стрелу времени» от 0 до +бесконечности (или, в полярных координатах, от 0 до 2*pi, длину окружности какого-то радиуса) + бесконечно много форков реальностей мультиверсума + непонятно какую «причинность» между ними,

а ломаную из различных причинностей (которые не факт что вообще можно сводить к одной оси какой-то там стрелы, к тому же ещё и виртуальной абстрактной в сферическом вакууме — cр. логический закон правило силлогизма про причинно-следственную связь, а «абстрактное единое время» как бы намекает нам, что сводить можно всегда, невзирая на матерьяльную импликацию — хотя бы тупо сопоставив а.е.в. EIP регистр, а не «логическое» замыкание, например), ну или в полярной системе координат — многомерную спираль (или, многомерный тор? вихревую губку? сферического коня Калаби-Яу? и т.п. по вкусу), где бесконечномерное время последовательно приближается некоторым конечным набором временных координат (также, как p-адические бесконечномерные приближаются конечным набором простых чисел, или трансцендентные десятичными дробями)

хотя, что смущает:

«Эверетт, можно сказать, предложил просто довериться формулам. И если математика показывает, что объекты квантового мира существуют постоянно и непрерывно, а не кусочно-рваными фрагментами от измерения до измерения, то так оно, скорее всего, и есть на самом деле.»

=> в мультивремени всё ещё остаются «кусочно-рваные фрагменты», просто теперь они становятся не столько единым дискретным временем «от измерения до измерения», сколько конечномерными приближениями бесконечномерного мультивремени, от реальности к реальности, от вселенной к вселенной, в разных временах и причинностях.

мы говорим о более широком жизненном цикле, чем волновая функция-измерение-коллапс-схлопывание в общей стреле времени (самоорганизации аналогично КДТ, но только там время скалярно): составление фрагментов, стыковка фрагментов в многомерном времени, самоорганизация фрагментов согласно какой-то внутренней причинности (что позволяет получить кусочно-линейную ломаную из кусочков локальных причинностей, приближающую виртуальную «абсолютную» стрелу времени), самореализация этой «причинности» в соответствующей «локальной вселенной» мультиверса (с нужными условиями реализации), самоорганизация «локальных вселенных» по событиям и причинностям, и так далее — то же самое для фрагментов условий, а не фрагментов событий, в общем, turtles all the way down вниз по башне мета (события-условия-причины условий-причины причинностей-...).

Радикально новая идея Эверетта состояла в том, чтобы задать вопрос: «А что если процесс измерения не прерывает эволюции волновой функции? Что если уравнение Шредингера применимо всегда и ко всему — и к объектам наблюдения, и к наблюдателям? Что если ни один из элементов суперпозиции никогда не исчезает из реальности? Как будет выглядеть для нас такой мир?»

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

«использовать его нельзя» можно: для этого нужно построить квантовый компьютер, способный использовать эти эффекты самоорганизации пространства-времени и строить сплайны из многомерных ломаных в нужных самореализующихся вселенных мультиверса, а не одномерных прямых в универсуме-абсолюте-сферическом-и-в-вакууме :)

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

если есть такой жизненный цикл: семечко, падает в землю, прорастает, вырастает, цветёт, завязывается, плодоносит, даёт другие яблоки с другими семечками (которые тоже падают в землю, прорастают, плодоносят и далее по списку), .... засыхает, умирает из-за «возрастания энтропии» --- то какое нам нафиг дело, что энтропия этого одного конечного элемента-яблока возрастает и он *когда-нибудь в локальном времени* должен умереть?

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

если же реализуется в нескольких, то всегда в какой-то другой находится на более ранней фазе жизненного цикла.

поэтому если обеспечить возможность общаться, и передавать информацию между такими локальными вселенными мультиверса (назад по ЖЦ, но вперёд по мультивремени), то ... PROFIT!!!

поэтому не нужно «обращать время» и отматывать энтропию назад — как только на этапе модели ЖЦ обеспечено самовоспроизводство, и саморазвитие при подобающих условиях, задача «обеспечить неубывание энтропии» или даже «обеспечить подачу энергии» — не важна.

важна задача «обеспечить условие самовыживаемости, самоорганизации причинности размножения и отбора».

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

в итоге из конкретных кусочков-причинностей образуется ЖЦ вероятного и возможного.

всё возможно, если правильным образом подобраны условия, есть возможность развития и есть «мотивация» для развития.

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

ср. например, алгоритм Эверетта про множители Лагранжа, для Байесовской вероятности и байесовскую машину, сети Байеса, алгоритмы Маркова, Н-модели, вычисления в ограничениях :

вторые — не совсем алгоритмы, а так, примазались, но результат — тот же, что и чётко детерминированного алгоритма, так-то!. это два эквивалентных представления.

если предполагать, что некая «башня мета» существует, то цепочка такая: метаметамодель, которая будучи частично вычисленной (проинтерпретированной) выдаёт граничные условия, метамодель ограничений, которая будучи корректно сформированной Н-моделью, например, вычисляется в то же самое, во что вычислялся бы найденный (и кем-то сформулированный в терминах своей собственной «причинности») алгоритм.

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

«самоорганизация причинности» «виртуальной локальной стрелы времени локальной вселенной» из «реального абсолюта мультивремени».

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

а не материя (пространство «физическое» координат) или время (пространство «виртуальное» состояний).

локальное (виртуальное) время в какой-то новой вселенной образуется из самоорганизации причинности в «реальном абсолюте мультивремени».

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

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

т.е.: «не пространство задаёт время, а законы задают время, из которого следует организация пространства»

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

про проблему останова Тьюринга

ещё сдаётся мне ИМХО, что проблема останова Тьюринга не так фундаментальна, как её малюют — она ничего не говорит о переходе язык/метаязык, да и в рамках «объектного языка» (по теореме Тарского) ещё можно побороться:

например, для квантовых компьютеров. есть алгоритм Шора: «оперируя „волнами вероятностей“, свести задачу факторизации математическую к физической -- определения периодичности кристаллической решётки».

ещё интересен алгоритм поиска Гровера, где «нежелательные ответы сами себя гасят, а верные, накладываясь, усиливают друг друга».

тогда обратный алгоритму Шора будет: свести задачу определения периодичности длинной последовательности (мощности алеф0 или больше: зацикливание, и т.п.) к задаче факторизации:

т.е., если факторизуется, то последовательность «не зацикливается» из не q в не p <=> если последовательность XXX зацикливается, то число YYY не факторизуется

(компьютеры квантовые, т.е., умеют быстро определять, факторизуется ли число).

если это «зацикливание» в свою очередь организовано как метациклический вычислитель (метаинтерпретатор, метакомпилятор)

то сводим к этой задачу «компиляции фэкспров».

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

или к вычислению «когерентных(квантово запутанных) фракталов во взаимно простых числах».

принцы рыбки в янтаре

мы не пытаемся построить «правильный» алгоритм функционирования Амбера и распорядок половой жизни Оберона, или Логруса и Мерлина-принца или там другого начальника хаоса — может его, алгоритма, для хаотического Логруса и не существует.

Мы просто пытаемся факторизовать Корвина по Логрусу, и Мерлина по Амберу (они оба в этот момент проходят свои лабиринты), и действуем в связи с тем, получилось или нет. А по скольку все отражения Амбера связаны, и тени Логруса тоже, то и в конкретно этой вселенной тоже чего-то получается.

обратимость

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

например: составление из сферы двух — это форкинг реальности; составление трёх из двух — это в обратимых вычислениях, слияние, объединиение и рождение новой (не стирая двух старых).

вот пускай мультиверс и считает все варианты, всё равно в какой-то конкретной вселенной причинность организована таким образом, что локально в ней реализуется только что-то одно (остальное и стирать не надо, если нет доступа).

есть доступ/нету — определяется тем самым способом разбиения на состояния и вероятности.

векторный гипертекстовый покерфейс

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

вдругорядь и достигнем желаемого. вельми понеже зело узреть сие благолепие.

или оное оук уже ие (ѣ) построено — надобно токмо узреть сие, ижеи скрытое в листве, духу, а не глазу доступное из мiра горнего, мiра дальнего.

образами сиречь ѣроглiѳами :

енъ фита ижица есмь инить ижеи одь ижа. эдо юнь ять ята ота еры омъ ерь.

</покерфеic-нацепяше>

фрактальчик это множество.

Множество точек в метрическом пространстве, если точнее.

ультраметрическое подойдёт?

1. как раз _можем_.

Ты можешь разбить шар на неизмеримые множества?

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

например, такое вот разбиение, как у Эверетта в диссере — на всевозможные состояния, связанные разными причинно-следственными связями и их, состояний, вероятности (он вообще-то про равновероятные события и необщающиеся вселенные.
но что, если взаимообусловленные умеют общаться через какой-то метавычислитель?) .

неизмеримо, потому что способ разбиения на состояния зависит от типа связи (как ты бы сказал, потому что «фекспры нельзя компилировать» — коллапс волновой функции возникает при интерпретации, подсчёте, определении циклов, сопоставлении, применении аксиомы Архимеда и измерении, а деревья такой интерпретации есть вещий лес, или с циклами, которые можно иногда уложить в другие деревья метаинтерпретаций)

множество состояний неизмеримо (ну нету у нас для него аксиомы Архимеда, заранее, до интерпретации), а полная вероятность событий = 1.

кластер метапарадигм, же ну — решение существует, а проинтерпретировать и построить его нельзя, сразу коллапсирует )))

сферический суперуспешный стартап в вакууме)))
(он ещё и Дункан Маклауд, т.е. вторая копия-клон сразу коллапсирует, может остаться только один, лол)

но мы не ищем лёгких путей — полетим на Солнце ночью
(будем строить, не интерпретируя, а символически вычисляя и эквивалентно преобразовывая, и выкинем аксиому Архимеда)

такъ победiмъ !!!

2. не шар, а сфера. Это разные вещи. Уточню, что сфера имеет объём равный нулю.

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

если пространство ультраметрическое, то в нём любая точка шара — это её центр.

то есть, сфера и есть шар в ультраметрике.

«система бесконечно вложенных друг в друга шаров, «центр которых везде, а край нигде»»

убрали циклы из графа => можем пройти по остову и посчитать все ветки, свести их в новый граф (остаточную программу).

как только отсекли циклы.

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

вообще, парадоксы не такие уж и парадоксы: Банаха-Тарского про удвоение шара — это форкинг реальности в мультиверсе в параллельную реальность и параллельное мультивремя; парадокс Хаусдорфа про составление трёх из двух — это наоборот, слияние, двух реальностей в одну новую (+ 2 старых, которые в обратимых вычислениях «не выкидываются»).

бобёр выдохнул.

ага.

возьмём интерпретацию ... квантовой механики.

Нинужно же :)

Ну ОС это типа рантайм, она уже скомпилирована нормально и работает, требует наличия компилятора в машкод не она, а возможности

Ну вот. А в случае интерпретатора (bash, например) или Common Lisp компилятор требуется всегда.

Может (точка входа и шейкер, или по типу LLVM+Clang/GHC API с доступной разделяемой либой компилятора и т.п.)

В смысле, компилятор в полном объёме? Тогда получается что программа требует компилятора во время выполнения, то есть с точки зрения использования — интерпретируется.

Или только используемые функции? Тогда что будет при выпадении в отладчик. Там же должен быть REPL? Или мы уже не про Common Lisp? В Scheme/Racket или Haskell — да, в рантайме есть только GC, то есть там однозначно компилятор.

если уравнение диофантово, то мы тупо можем перебрать остатки, по случаям. использовать признаки делимости, сократить все варианты комбинаций в переменных под «остатки по модулю p_i», перебрать все комбинации от 0 до p_i-1.

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

символьно вычисляя и эквивалентно преобразовывая.

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

он показал, что волновая функция обладает такими свойствами, что можно понимать измерение как ветвление универсальной волновой функции, или как форк реальности, когда на каждое действие-измерение возникает альтернативная вселенная из мультиверса (многомирья):

Ты херню полную несешь. Эверетта не устраивал тот факт, что коллапс волновой ф-и нарушает принцип причинности. И Эверетт решил убрать коллапс вообще. Нету никакого коллапса. И ветвлений никаких не происходит при измерении. При измерении вообще ничего не происходит, кроме взаимодействия волновых ф-й в соответствии с у-ем Шредингера. Ветвление же нарушает тот же принцип причинности, то есть не устраняет проблему, которую Эверетт пытался устранить.

А в случае интерпретатора (bash, например) или Common Lisp компилятор требуется всегда.

Интерпретатору не требуется компилятор (в машкод). Он требуется для JIT, это дополнительная оптимизация, как и байткод, но без них всё равно возможна интерпретация.

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

Wut? Любое выполнение это интерпретация чего-то чем-то. А компилятор во время выполнения нужен... если он нужен, то есть если нашей системе нужен JIT.

Тогда что будет при выпадении в отладчик. Там же должен быть REPL? Или мы уже не про Common Lisp?

Там может ничего не быть (как в SBCL с ключами которые всё это отключают). Там может быть обычный интерпретатор, он же какой-то REPL. Если этот интерпретатор хочет JIT — тогда ему нужен компилятор.

В Scheme/Racket или Haskell — да, в рантайме есть только GC, то есть там однозначно компилятор.

У GHC есть API доступный в рантайме, то есть компилятор. Ну и я всё-таки не понял о чём мы тут — что значит «однозначно компилятор», в SBCL тоже однозначно компилятор, выполнение рантаймом и все-все-все.

В Scheme/Racket или Haskell — да, в рантайме есть только GC, то есть там однозначно компилятор.

Чего? Евал ты куда потерял?

Евал ты куда потерял?

В случае Scheme если явно в коде нет комбинации (eval ...) то вызвать его никак не сможешь. Поэтому его там нет. Также как из Си я могу вызвать system(«gcc ...»), но это надо явно написать в коде, а не необходимая возможность для любой программы на Си.

Интерпретатору не требуется компилятор (в машкод).

Я имел в виду, что может быть компилятор внутри интерпретатора (perl, python, bash). Пусть утверждение звучит так «в случае интерпетатора во время выполнения программы необходима доступность исполнителя, понимающего исходный язык программы».

Там может ничего не быть (как в SBCL с ключами которые всё это отключают).

Это уже нарушение стандарта. http://clhs.lisp.se/Body/09_a.htm

If there is no such handler and the signaling function is error or cerror, the debugger is entered in the dynamic environment of the signaler

если он нужен, то есть если нашей системе нужен JIT

JIT по-факту интерпретатор байткода VM (JVM или LLVM). Но компилятор исходного языка для JIT не нужен. Скажем в Racket в байткоде не будет половины переменных и почти всех констант, потому как оптимизация. А вот в CL необходим именно компилятор или интерпретатор CL при выполнении программы.

У GHC есть API доступный в рантайме, то есть компилятор.

На GHC программа может его не использовать и тогда его в рантайме (в бинарнике) не будет. Это аналог system(«gcc ...») для Си или линковки с libgcc.

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

Пусть утверждение звучит так «в случае интерпетатора во время выполнения программы необходима доступность исполнителя, понимающего исходный язык программы».

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

JIT по-факту интерпретатор байткода VM (JVM или LLVM).

Нет, сам по себе JIT это компилятор, а не интерпретатор. И когда я говорил JIT, я подразумевал рантайм компилятор в машинный код — в JVM и LLVM именно такой. JVM называют VM потому что там может отсутствовать JIT и VM будет интерпретировать/исполнять байткод, а в LLVM есть JIT и в этой части он вовсе не VM (хотя там EE вроде предоставляет возможность обычной интерпретации). Какого рода компилятором является JIT — из исходного кода или из байткода это уже зависит, в JVM это из байткода, в байткод компиляция ahead of time, в LLVM — из IR/биткода или средствами Clang+LLVM можно сделать прямо из исходного кода.

Это уже нарушение стандарта.

А вот в CL необходим именно компилятор или интерпретатор CL при выполнении программы.

Если хочется полноценной CL среды — конечно. Но не обязательно компилятор, может быть просто интерпретатор/VM, то есть как везде.

На GHC программа может его не использовать и тогда его в рантайме (в бинарнике) не будет. Это аналог system(«gcc ...») для Си или линковки с libgcc.

Да, хотя бы dlopen(3) & co.

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

Ну вот. Интерпретатор может для выполнения предварительно транслировать исходник в маш. код (будет называться JIT). Но он всё равно интерпретатор (так как исполняет код, а не формирует бинарный файл).

Нет, сам по себе JIT это компилятор, а не интерпретатор

По отношению к куску кода — да. По отношению к программе в целом — нет, так как не возвращает результат компиляции всей программы, а постоянно работает во время выполнения.

Если хочется полноценной CL среды — конечно.

Ну так получается, если это ANSI CL, то он обязан быть интерпретатором (исполняемый файл обязан содержать в себе интерпретатор CL).

Какого рода компилятором является JIT — из исходного кода или из байткода это уже зависит

Не видел ни одного JIT из исходника.

или средствами Clang+LLVM можно сделать прямо из исходного кода.

В смысле в исполняемом файле код на Си и компилируется во время исполнения? А как такое там сделать?

В случае Scheme если явно в коде нет комбинации (eval ...) то вызвать его никак не сможешь. Поэтому его там нет.

Есть. Исполнение программы это (семантически) евал форм. Когда рантайм видит (define ...), то выполняет определенные сайд-эффекты.

Есть. Исполнение программы это (семантически) евал форм

Семантически — да. Но любую форму eval от константного выражения можно заменить на результат компиляции. Таким образом в скомпилированной программе ссылки на eval (и всё, от чего он зависит) уже нет.

Когда рантайм видит (define ...),

Например, в Racket в рантайме уже нет никаких define. Там есть только байт-код LLVM.

Но он всё равно интерпретатор (так как исполняет код, а не формирует бинарный файл).

Ок, код от JIT выполняют процессор с рантаймом, вот

http://root.cern.ch/drupal/content/cling

Cling is an interactive C++ interpreter, built on the top of LLVM and Clang libraries. Its advantages over the standard interpreters are that it has command line prompt and uses just-in-time (JIT) compiler for compilation. Many of the developers (e.g. Mono in their project called CSharpRepl) of such kind of software applications name them interactive compilers.

ещё интерактивным компилятором обзывают.

По отношению к куску кода — да. По отношению к программе в целом — нет

Вот так это может выглядеть

http://llvm.org/docs/doxygen/html/classllvm_1_1ExecutionEngine.html

http://llvm.org/docs/doxygen/html/classllvm_1_1JIT.html

http://llvm.org/docs/doxygen/html/classllvm_1_1Interpreter.html

ExecutionEngine::getPointerToFunction реализует JIT::getPointerToFunction — он будет компилировать, чего не будет делать Interpreter, выполнять можно с помощью ExecutionEngine::runFunction, который реализуют и JIT::runFunction, который просто просто звонит на скомпилированный код, и Interpreter::runFunction, который интерпретирует биткод.

Не видел ни одного JIT из исходника.

А в SBCL не JIT из исходника? :)

В смысле в исполняемом файле код на Си и компилируется во время исполнения? А как такое там сделать?

У clang тоже есть API, так что прямо начиная с парсера и т.д.

Но любую форму eval от константного выражения можно заменить на результат компиляции. Таким образом в скомпилированной программе ссылки на eval (и всё, от чего он зависит) уже нет.

Нельзя, я же могу взять и: (define eval 'huy)

Например, в Racket в рантайме уже нет никаких define.

Есть.

потому что он именно что конпеляет в негроконцоли

А где в рантайме есть дефайн? Если бы в рантайме был дефайн, можно было бы сделать (define (codefine x y) (define x y)). Нигде его нет, не только в Racket. Вообще, в рантайме нет никаких спецформ и макросов.

Исполнение программы это (семантически) евал форм

Исполнение программы это семантически тот eval, который сам есть исполнитель этой программы, который находится на верхнем уровне. А тебе, на уровне ЯП, могут предоставить и урезанную версию, и вовсе ничего.

Нигде его нет, не только в Racket. Вообще, в рантайме нет никаких спецформ и макросов.

В Common Lisp есть. По любой неотловленной ошибке обязан вызываться отладчик с REPL. Где, в частности можешь и играться с командами типа (defmacro (mydefun &body body) `(cl:defun @,body)).

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

Если бы в рантайме был дефайн, можно было бы сделать (define (codefine x y) (define x y))

А и можно.