Пошел нахуй, штя. Сколько раз повторять еще? Я от тебя устал.

Что интерфейс (ну и функционал, конечно) любого аппликативного парсера воспроизводится посредством обвёрток над интерфейсом монадического парсера.

А вот это уже что-то новое. Если речь идёт о текущем состоянии дел — может быть, не смотрел внимательно. Но вообще, я не вижу, почему нельзя написать аппликативный парсер, монадическим не являющийся.

Для тебя это баззворды?

В том виде, в котором ты их употребляешь — несомненно.

не меняется структура типов структур и преобразований.

Не распарсил. Расставь приоритеты: структура ((типов структур) и преобразований), или структура (типов (структур и преобразований)) или ещё что? А потом объясни, в чём отличие.

Я элементарные вещи рассказываю.

Ты вообще ничего не рассказываешь. Ты кидаешься умными словами, не вкладывая в них никакого значения.

Реализация вычислителя и компилятора CL требуют уже работающего CL

Возвращаясь туда откуда начали: как отсюда следует, что CL не язык программирования?

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

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

Их ELF нужно загружать в память для которой не выполняется GC, потом они захотят себе стека, поэтому кроме лиспового стека нужен сишный стек, потом они начнут хотеть malloc/free, поэтому кроме лисповой кучи нужно держать ещё классическую кучу (без GC), что ещё ничего, но потом они захотят треды на основе кванта времени (так как у них нет возможности делать reduction level yielding - до тех пора пока есть синхронное I/O и IPC) и если мы хотем лёгкие треды и сообщения в таком лиспе (я бы, например, хотел), то это уже плохо, потому что вытесняющий и кооперативный шедулеры трудно заставить (если вообще возможно) сосуществовать вместе. Ну и сейчас работающие сишные программы работают как работают, а в такой ОС они начнут делить время с ядерным GC что сделает их в несколько (!) раз медленнее. Как вариант - сделать GC сервером (на микроядерный манер, хотя MM за пределами ядра это нонсенс) и не использовать его в ядре (шедулер, IPC, I/O), но тогда это уже будет не лисповая ОС, а классическая, но с более lisp-friendly интерфейсом.

Ну и главный вопрос - зачем? Что есть такого в лиспе чтобы тащить его в ядро. Я пока ничего не вижу.

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

К сожалению для шти, этот постулат неверен, и он - ебанько.

ну метаклассы же

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

кстати поэтому я в том числе не люблю хаскель, ггг

И первое, и второе. Хотя имел ввиду изначально первое.

delphi не Ъ ввиду того, что я то под линуксом сижу.

можешь глянуть на freepascal. Мне помогает и для скромных нужд хватает.

В случае CL - все.

Ну, скажем, Graphic Lisp был написан на чистом C.

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

Тогда неясно, зачем он вообще нужен.

Для того, для чего нужны языки высокого уровня.

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

Слив засчитан.

Реализация вычислителя и компилятора CL требуют уже работающего CL.

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

Возвращаясь туда откуда начали: как отсюда следует, что CL не язык программирования?

Это-то как раз понятно, из ложного утверждения следует что угодно.

То есть, ты таки не в курсе, о чём говорит теорема Гёделя?

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

ну метаклассы же

И животноводство.

Кажется, я начал понимать. Ты, видимо, считаешь, что лисп работает каким-то магическим образом. Я тебя разочарую: он работает ровно таким же образом, каким и любые другие языки.

Кстати, «метаклассы» тоже не при делах: весь CLOS может быть реализован исключительно макросами.

Какой хороший, годный тред

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

You've made my day :)

Я не собираюсь доказывать отрицательные тезисы.

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

И первое, и второе. Хотя имел ввиду изначально первое.

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

Ты отрицаешь очевидное и общепринятое, ты и доказывай.

Все проще.

Ты на вопрос-то ответь. Ты считаешь, что CL может решать какую-то задачу, которую другие тьюринг-полные языки решить не могут?

компилятор CL требует контекста работающей лисп-системы, ввиду макросов как минимум.

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

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

Если второе — при чём тут макросы? Любую программу, которую можно написать на CL, можно написать без макросов.

Я пишу конпилятор лиспа, если чо. Так что знаю, как он работает лучше многих других.

CLOS(с MOP) не может быть реализован исключительно макросами, кстати, потому что тоже метацикличен, как и остальной лисп.
Читай AMOP, смотри closette:
http://www.laputan.org/pub/lisp/closette.lsp

http://en.wikipedia.org/wiki/List_of_educational_programming_languages
А эти молодые ученые уже всю классику Си/С++ прочитали? K&R, 2 книги Страуструпа?

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

Я утверждаю, что НИ ДЛЯ КАКОГО языка нет формально определённой семантики, а для некоторых — и синтаксиса (Perl, например).

В какой-то степени является исключением Хаскель: формальная семантика существует хотя бы в головах программистов на Хаскеле, причём реально используется. Правда, 1) эта семантика не включает FFI и unsafe-фичи, и 2) это не операционная семантика.

много раз ++

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

В обычных компиляторах компиляция AST всегда ведет к одному и тому же. Потому что это детерминированный вычислитель.

В лиспе то, как компилируется условное AST - зависит от контекста, причем не синтаксического, а от состояния лисп-системы. А оно может зависеть от даже фазы луны, в теории.


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

Или для того, чтобы можно было сделать сам компилятор?

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

Макросы потому, что компилятор раскрывает макросы в коде. Макросы это тоже код на лиспе. Функции, точнее. Вообще любого вида. Чтобы раскрыть макрос, надо сначала получить функцию которую макрос представляет собой. Для этого надо ее скомпилировать. Она тоже может содержать макросы, естественно. Это означает что компилятор и вообще, вычислитель, CL - метациклический.

Платиновые треды лора.

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

полиэтиленчик постигает суть работы любой ВМ, оянемогу :)

ебанько штя наконец допирает до сути лисп.
Не прошло и полгода.

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

Тогда нужно написать правильный (>>=) в терминах (<*>), (*>), (<*).

Вот пример с parsec:

{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FunctionalDependencies #-}

import Control.Applicative -- Alternative ( (<|>) )
import Control.Monad
import Text.ParserCombinators.Parsec hiding ( (<|>) )

infixr 2 <+>
(<+>) :: Applicative f => f a -> f b -> f (a, b)
(<+>) = liftA2 (,)

class ParseA a b | a -> b, b -> a where
  lift   :: a -> b
  parse_ :: Parser a
  parseA :: Parser b
  parseA = fmap lift parse_

data Term = Foo Char Char
  deriving Show

instance ParseA (Char, Char) Term where
  lift   = uncurry Foo
  parse_ =
        (char '{' *> letter <+> char ':' *> letter <* char '}')
    <|> (char '(' *> letter <+> char ',' *> letter <* char ')')

test :: [Either ParseError Term]
test =
  [ parse parseA "" "{a:b}" -- => Right (Foo 'a' 'b')
  , parse parseA "" "(w,q)" -- => Right (Foo 'w' 'q')
  ]

инстанс - почти BNF, но нужно ещё что-то придумать для вариантных типов (чтобы отображать варианты BNF в варианты ADT).

ну ничего, ничего, ещё 18 страничек и ты поймёшь, что любая более или менее нормальная ВМ пишется с этими заморочками в голове

да lisp - это относительно сложный случай, но не такой страшный

CLOS(с MOP) не может быть реализован исключительно макросами, кстати, потому что тоже метацикличен, как и остальной лисп.

Ну, естественно, функции никуда не деваются тоже, да.

8 (!!) страниц потребовалось ште чтобы понять ште што такое лисп.

Макросы — не при делах. Операционная семантика начинает работать ПОСЛЕ того, как они полностью развёрнуты, так что можно считать, что их нет.

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

я имею ввиду, CLOS определяется в терминах себя самого обычно.

Для бутстрапа он переопределяет себя саму от одного(closette, XCL) до 3 раз(в SBCL вроде 3 раза, хотя хз точно).

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

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

В лиспе то, как компилируется условное AST - зависит от контекста, причем не синтаксического, а от состояния лисп-системы.

Да пофиг во что там «компилируется условное AST». То, что ты можешь из репла компилять кусочки программы, не интересно.

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

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

Если лисп системы нет, компилятор тоже в принципе не реализуем.

Реализуем. Есть компиляторы CL, написанные не на CL.

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

И что, собственно?

Если под формальной ты понимаешь только денотационную - возможно.

Под формальной я понимаю формальную.

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

Может, и можно, только никто не сделал. Формально, я имею в виду.

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

Фигня. Как раз для форта существуют вполне приличные описания — очень далёкие от формальных, но тем не менее. Что неудивительно: язык-то мелкий, делать там особо нечего.

Реализуем. Есть компиляторы CL, написанные не на CL.

Нет.

И что, собственно?

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

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

Я о чем и говорю, что ее нет.

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

Ты не понимаешь.

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

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

Тогда нужно написать правильный (>>=) в терминах (<*>), (*>), (<*).

Стоп-стоп-стоп. Это ещё почему?

Я бы сказал, наоборот, никакого (>>=) писать НЕ НАДО, иначе парсер сразу станет монадическим.

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

ну есть же GCL, к примеру

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

И?

Как раз для форта существуют вполне приличные описания — очень далёкие от формальных, но тем не менее.

Значит они не полны. Потому что форт тоже может переопределять сам себя.