Занимаясь веб-девелопментом

> Можете представить программу на Haskell в скобочном синтаксисе (в тех местах где инфикс и layouts)? Монады от этого не пропадут.

Получится template haskell, не?

А вот на вопрос «как реализовать пользовательскую специальную форму со стратегий вычисления call-by-macro-expansion» будет конкретный ответ.

call-by-macro-expansion это однозначно зло; полезные вещи, которые с его помощью пытаются сделать, надо делать по-другому

> Но ты ведь на самом деле молчишь, да?

Да. Ты подслушал мои мысли.

> Например, на CL уже есть реализация metamath.

Qi же.

метахомячки это тоже хомячки, они не равно, но принадлежат к множеству хомячков.

навроде как метаклассы это классы.

> Считаешь что оно нужно? Может стоит пойти ещё дальше.

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

щас кстати читаю Let Over Lambda

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

насчет кривизны гигиеничных — там тоже есть интересная ссылка

это плюсовикам то про кривизну говорить?

> reader -> macroexpander -> evalutor -> compiler

а лучше reader -> macroexpander -> compiler

Ну так они в любом языке могут быть библиотеками.

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

Почему вдруг?

Да и тупые средства бутстрапа (типа s/.../.../ ) никто не отменял.

>всё это строго ортогонально «лиспам» и их s-выражениям

::facepalm::

>А если я в хаскеле напишу

Словишь ошибку компиляции.

> это плюсовикам то про кривизну говорить?

уж точно говорить не с теми, кто считает опытных программистов хомячками; так что тебе пока что отвечать не буду

>И не надо даже типизацию выдумывать.

::facepalm:: В таком тривиальном случае — ну конечно, не нужно. А если у тебя атом — результат вычисления? С блек^W побочными эффектами, взаимодействием с миром? Нет, ты конечно сейчас скажешь, что к каждому символу можно прицепить еще и некие метаданные (безотносительно каким способом).

Я с этим не спорю. Можно делать все. Можно даже для лиспа реализовать типизацию Хиндли-Милнера. Вон ребята из PLT сделали.

Опять же, я как-то говорил, что тип не является аттрибутом языка. Можно привести в пример встроенный язык 1С, там вообще в нет средств для работы с классами/объектами. Там метаобъекты определяются через метаданные, а их классы вообще жестко в платформу зашиты.

Можно привести эрланг. Там из коробки есть статический анализатор. И еще куча не из коробки.

(html
   (body
      (div :class :some-div-class :id id0
          text
text
     yexy
           (p :style :text-indent :1em
                   mnogabukaf))
      (div mnoga bukaf)))

Вот чё-то такое надо бы.

>А, узнаю, phd-level-topic через каждые две главы :)

А вот ерничать не требуется. Ты сколько въезжал в концепцию S-выражений? И и что, книжки тебе помогали?

это херотень какаято, не s-выражения

Да не выпендривайся ты. Сгенери на стороне сервера JSON и отпарзь на стороне клиента в любой самый извращенный html.

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

Скорее всего изоморфизма нет.

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

А при наличии лексической области видимости сама по себе строка с названием переменной ничего не значит.

И главное, кусок S-выражения при копировании и вставке в другое место приобретает возможно *совсем* другое значение.

Ридеровские макры и их вычисление как-то борется с этим, но это явно костыль.

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

предыдущий пост был про программы, а этот про данные

как в S-выражении запаковать данные, где имеются 2 ссылки на один мутабельный байт в памяти?

можно предложить некий синтаксис опять поверх S-выражений, но это опять костыль

Получится template haskell, не?

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

call-by-macro-expansion это однозначно зло

Как же сделать что-нибудь такое? Или не нужно? И ведь это самый простейший пример.

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

Ну чисто практически - есть over ~ 10^5 строк кода где используется такой подход - поколения программистов были не правы? Как делать правильно?

щас кстати читаю Let Over Lambda

А я вот так и не собрался :) гы!-макры это, имхо, выпендрёшь (а.к.а. пока не осилил). По крайней мере обычные макросы который везде используются покрывают все задачи, которые вообще нужно решать макросами. А вот какого практическое применение g!-штук пока не понятно (хотя, может next 50 years).

Ты подслушал мои мысли.

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

Qi же.

Ну Qi можно написать на чём угодно, как и metamath, впрочем, - там есть и на Си, и на Python, и на Haskell реализации. Неудачный пример, но есть, к примеру, CLOS - расширение которое без бустрапа расширяет базовый CL. Попытка сделать подобное на Си - построение отдельного рантайма, и использование будет выглядеть как вызовы функций (а не использование родного языка) и выполнение будет происходить в рантайме. В CL же есть возможность провести произвольную трансляцию кода в compile-time (раз) + новый язык выглядеть будет как родной (два). Да , звучит как типичные мантры, но всё же :)

всё это строго ортогонально «лиспам» и их s-выражениям

::facepalm::

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

Словишь ошибку компиляции.

Аналогично, будет ошибка компиляции и в CL.

> Ну просто пост есть, а фактических возражений не слышно.

Фактическим возражением был бы, например, компилятор расширенного Си, написанный на Си... OH SHI~, их уже не один и не два. Может быть, в Лиспе это сделать проще, но и в других языках тоже можно.

Ну Qi можно написать на чём угодно, как и metamath, впрочем, - там есть и на Си, и на Python, и на Haskell реализации.

О чем и речь.

В CL же есть возможность провести произвольную трансляцию кода в compile-time (раз) + новый язык выглядеть будет как родной (два). Да , звучит как типичные мантры, но всё же :)

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

Ты сколько въезжал в концепцию S-выражений?

Это как раз проще всего, как только видим в SICP

   *
  / \
 2   +
    / \
   2   3

(* 2 (+ 2 3))

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

> В CL же есть возможность

Это очень плохо говорить о сферических возможностях. Если говорить о чём-то, то только на конкретных полезных примерах. А то возможности есть, а применения нет.

компилятор расширенного Си, написанный на Си...

ЁПР~ это и есть бустрап. Вот если бы форма расширяющая си шаблонным образом превращалась в код на си и процесс компиляции продолжался бы дальше. Т.е. определение самой по себе расширяющей формы это ведь кода - кот наплакал, но в случае Си это потребует или реализации расширенного языка на языке (много кода), или runtime-like расширения (неудобно, тормоза, так как не задействуется стадия компиляции), либо препроцессинга, вроде m4 (нет доступа к типам и прочим internals - опять не то).

Ты говоришь не столько о свойствах языка, сколько о программной среде.

Эти свойства ассоциируются у меня с конкретным языком только потому что ничего подобного я больше нигде не вижу (even Smalltalk!).

Ну я не особо какой практик CL :) Но все проекты среднего и большого размера которые я видел активно используют макросы, т.е. расширяют CL пользовательскими специальными формами, где-то даже производится конверсия - трансформации кода.

> Как же сделать что-нибудь такое? Или не нужно? И ведь это самый простейший пример.

Щас отвечу, не особо думая (т.е. потом могу мнение поменять).

Зацепившись за кривое свойство захвата переменных, в лиспе из макросов и лямбды удается сделать let. Эка невидаль.

Кривое оно потому, что работает 1 раз, а при попытке взять его композицию обрушится.

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

Т.е. из линейно зависимого набора «let macro lambda» я выбираю два первых, а не 2 последних в качестве базиса.

Скорее всего изоморфизма нет.

Он не может не есть - он доказывается. Я говорил о том что АТД для AST изоморфно s-expression. На этом уровне ещё нет семантики (никаких переменных и т.д.), семантика привязывается уже к конкретному дереву с семантическими атрибутами (на этом уровне уже не важно представление, также как не важно, для контекстно-свободных языков, чем мы описываем синтаксис - BNF, продукциями по Хомскому - эквивалентные вещи).

топологическое (+)                                  -> (:or ...)      ;; вариантные типы
конструктор, а.к.а. топологическая n-арная операция -> (:operate .n.) ;; композитные типы
топологический элемент                              -> :keyword

И главное, кусок S-выражения при копировании и вставке в другое место приобретает возможно *совсем* другое значение.

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

как в S-выражении запаковать данные, где имеются 2 ссылки на один мутабельный байт в памяти?

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

> Но все проекты среднего и большого размера которые я видел

активно используют макросы

Вот ведь интересный вопрос, а с чем это связано? С тем, что макросы настолько могучи? Или с тем, что, как указывает Страуструп, в языке много недостатков? или много недостатков в программистах?

Поскольку, значительная часть сообщества CL-разработчиков, как бы там помягче сказать, не совсем вменяема, то одна из причин широкого использования макросов как бы на поверхности. А поскольку мы не имеем много примеров впечатляющего софта на CL, то причина номер два - недостатки языка, то же как бы напрашивается.

Так что судить о силе макросов на основе подобных наблюдений как бы не очень разумно. Говорить об этом имеет смысл только на конкретных реальных примерах.

> Он не может не есть - он доказывается. Я говорил о том что АТД для AST изоморфно s-expression.

и при этом ни полслова не сказал, что за операции определены у AST — почему я и сказал «Скорее всего»

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

Зацепившись за кривое свойство захвата переменных, в лиспе из макросов и лямбды удается сделать let. Эка невидаль.

Выражение

let x = s in t ≡ (λ x . t) s

это из чистого лямбда-исчисления, о том что let - сахар над чистым лямбда-исчислением (см. John Harrison, Introduction to Functional Programming). Вот в LC вводят такой сахар (последний пост) а в Haskell есть такие средства, только для прямых рук?

точно так же, как ты, можно было бы утверждать, что AST изоморфно последовательности байтов, и сказать:

На этом уровне ещё нет семантики (никаких переменных и т.д.), семантика привязывается уже к конкретному дереву с семантическими атрибутами

и при этом ни полслова не сказал, что за операции определены у AST — почему я и сказал «Скорее всего»

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

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

Главное на этом месте остановится и прокричать, что у LoL нет никакой практики - нет пока такой :) Настоящие AST - да, они вообще алгебраические, из них нельзя ничего вылепить другое (тот самый data в Haskell, который вводит обще-топологическое отображение между категориями). А вот в случае деревьев - есть отображение в, минимальные, s-деревья.

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

Извини, так сказать я не могу, потому что это не правда (по крайней мере не вижу связи тут).

>> и при этом ни полслова не сказал, что за операции определены у AST — почему я и сказал «Скорее всего»

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

Лисп головного мозга.

Там точно не деревья. Про что я уже и талдычу *давно*.

Самое близкое — это «дерево, дополненное обратными ссылками на место определения переменной».

Вот сейчас увидел взаимооднозначное преобразование. Но в математике всегда есть разные формы говорить об одних и тех же вещах. А вот в программировании выбирают самую простую/очевидную/удобную (как для решения прикладных квантово-механических задач используют самую подходящую её, КМ, формулировку). S-выражение это минимальное дерево, плюс оно читаемое, вот Хомский в своих работах по лингвистике использовал такую форму, а МакКарти использовал для создания того самого абстрактного искусственного языка.

Вот поставят перед тобой ТЗ - разработать протокол передачи HTML в бинарной форме, ты уже на этот экзотический изоморфизм (AST <-> байт-код) иначе будешь смотреть :) Конечно можно о нём просто не знать - просто решать задачу (как например, если мы заговорили об AST, о том что read/eval/print это катаморфизмы на ADT определяющих AST - можно ведь просто не знать).

> (по крайней мере не вижу связи тут).

что у тебя в дерево, что у меня в строку байтов не запихнута жизненно важна семантика; а без нее пофиг, что выбрать

Там точно не деревья. Про что я уже и талдычу *давно*.

Ты просто не знаешь. Как и с тем примером выражающим let через лямбду. Ты знаешь о том что такое продукции Хомского для контекстно-свободного языка? Или семантические атрибуты по Кнуту? Не то что бы я считал это важными знаниями - но нельзя обсуждать затронутые темы «просто так», на манер «а я вот так считаю», там есть прописные истины - их преподают, либо юзают самообразование.

Самое близкое — это «дерево, дополненное обратными ссылками на место определения переменной».

Эти графы, со связями переменных, возникают позже. Их не используют в синтаксических рассуждениях. Семантика - да, s-выражения и AST не имеют отношения к семантике.

> Ты просто не знаешь. Как и с тем примером выражающим let через лямбду.

С этой идеей я знаком года с 1995 (в виде «нужна локальная переменная? ну так определи новую функцию с лишним формальным параметром»).

И в любом случае я бросаю попытки обратить твое внимание на недревестность.

Лучше ты объясни, зачем нужны лет-подобные формы? Какие задачи ты решишь с их помощью?

Кстати, с чего бы это в аббревиатуре AST - слова «синтаксис» и «дерево», не знаешь? ;)

недревестность.

Цу! We need it! Недревестность :)

Лучше ты объясни, зачем нужны лет-подобные формы?

(mama has let, papa has let, so you has it too, or you not a human?) В haskell уже есть let, тот пример - вопрос на тему «как ввести простейшую специальную форму своими руками (на примере let)» - не покрывают ленивые функции этого, так как им есть дело до семантики (те самые переменные), а чтобы уметь в языке опереровать AST (макросы) нужно оперировать на уровне синтаксиса (да, TH, Liskell, etc. но заумно).

С этой идеей я знаком года с 1995

Кстати, круто :)

И в любом случае я бросаю попытки обратить твое внимание на недревестность.

Я кстати сказал - ты связываешь «недревестность» («графичность», графы) с семантикойм - это правильно. Но не имеет отношения к синтаксису. Мы говорили об «Абстрактных Семантических Деревьях».

Если нужна порция абсолютной истины:

1) Продукции Хомского, или BNF, параметризируются с помощью алгебраического РТД, этим определяется дерево вывода.

2) Чтение, вычисление, печать и прочие трансформации это катаморфизмы над этим АРТД, они же наделяют дерево семантическими атрибутами (они же могут использовать графические представления, та же методы graph reduction).

Это если очень формально.

> Ты знаешь о том что такое продукции Хомского для контекстно-свободного языка? Или семантические атрибуты по Кнуту? Не то что бы я считал это важными знаниями - но нельзя обсуждать затронутые темы «просто так», на манер «а я вот так считаю», там есть прописные истины - их преподают, либо юзают самообразование.

можно, но при условии что собеседнику (т.е. тебе) интересно, где он обламается со своим подходом; тогда бы быстро меня понял

вначале ты писал

S-выражения это способ записи данных и программ, представление, в которое строится изоморфизм из любого другого представления.

заметим — программ, а не синтаксической структуры программ, на которую ты съехал в последнее время

______________________________

я тут, кстати, интересуюсь, где меня может встретить облом

алгебраического РТД

Не обязательно Р, это в общем случае.

заметим — программ, а не синтаксической структуры программ, на которую ты съехал в последнее время

Т.е. я в начале не ясно выразился и только теперь ты более менее понял о чём я говорил? Когда я говорил «запись» я, очевидно, имел ввиду синтаксис. Синтаксис представления данных, программ. Вот теперь прояснили этот момент.

Ну и вообще s-выражения относятся только к синтаксису сами по себе. Когда говорят «Антоновка» - имеют ввиду яблоки, не груши :)

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

>mama has let, papa has let, so you has it too, or you not a human?

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

2. let-формы вносят совершенно неожиданную вещь — внезапно переменная оказывается определенной; такие случаи должны быть известны *заранее и всем*, и значит, фиксированы языком программирования

3. ну допустим у тебя есть способ делать let-формы; ты сможешь на их основе сделать хотя бы модификатор private? (и не плеваться потом на язык, да)

не проще ли сделать, например, интерфейс к таблице символов?

> Т.е. я в начале не ясно выразился и только теперь ты более менее понял о чём я говорил? Когда я говорил «запись» я, очевидно, имел ввиду синтаксис.

Записывать можно не только 1. код, скармливаемый компилятору, но и 2. код как результат распечатки кода программ — допустим, активных замыканий (что актуально в теме про лисп).

Ну и запись 1 и 2, очевидно, желательно иметь на одной основе. И для 2 деревья не годятся — значит, не годятся и для 1.

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

А представь систему, которая покрывает ВСЁ. Какая она должна быть громоздкая, на скольки громадных консорциумах ее будут стандартизировать и какому количеству человек и организаций она должна угодить? С такой неуклюжестью она будет отставать лет на 10 от рынка. А как быть с упоротыми? Одни до смерти будут стоять за одно, а другие - за противоположное.

Победа как раз в модульности, переносимости, интеграции с друг другом и взаимозаменяемости компонентов. man java