LINUX.ORG.RU
Форум — Development  

[лисп] уже почти достал


0

0 

Добрый вечер!
  Во-первых, мне не нравится, что вместо 
a.b.c я пишу (c-of (b-of a)). Я уже писал про то, что язык должен 

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

  Я было подумал про Яву... Но ява - это не динамический язык. 
Возможность поменять 1-строчку в многомегабайтном коде и приступить
к его отладке через доли секунды имеется только в лиспе... 
  Поэтому возникает такая идея:
сделать новый синтаксис для лиспа. Который бы на первом этапе
 преобразовывал
function m(a) {
  let u=a.b;
  let count=u.count();
  <comment>бебебе</>;
  u.c(x) = 34*5;
  return u.count()-count;
}
сначала в
(" " function (".()" m a) 
  ("{;" 
    (" " let (= u (dot a b)))
    (:t comment "bebebe")
    (" " let (= count (".()" (dot u count))))
    (= (".()" (dot u c) x) (* 34 5))
    (" " return (- (".()" (dot u count)) count)))

и потом - в

(defun m (a)
  (let* ((u (a-of b))
         (count (count u)))
     (setf (funcall (u-of c) x) (* 34 5))
     (- (count u) count))

(последнее преобразование, причём, чтобы по выбору рендерило код либо на лиспе, либо на php, либо на javascript). 

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

плюс к тому, чтобы 
(defComposedFun fooBar (x) foo bar) не порождало функцию
(defun fooBar () (bar (foo x)))
а производило inline-подстановку foo в bar и возвращало исходник. 

Плюс к тому, чтобы можно было писать не только include, но и 
exclude, чтобы можно было генерить и страницу, и аякс-скрипт в ней
в одном файле, типа:

atCompileTime {
  <defmacro webFile args = (string relativePathname,&body body)>{
    <quote>exclude(<unquote>getenv(www-root) + relativePathname</>,
                   <unquote>body<//>
  }</defmacro>
  webFile("application.html",
    <html><head> ... </html>)
  webFile("ajax.php",
    <?php>...</>)
}

Уф. Хватит на сегодня. Жалко, что на ЛОРе темы не всплывают, а то можно было бы теперь долго здесь флудить...
★★★★★
← Странно-интересное
декомпиляторы Java →

 ← 1 2 3

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

anonymous
()

ну сделай, кто тебе мешает? каждый сходит с ума, как может.

volh ★★
()

и чтоб не смел возвращаться, пока не сделаешь.

volh ★★
()

> Поэтому возникает такая идея: сделать новый синтаксис для лиспа.

Лисп с человеческим лицом? Одобряю.

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

А потом от лиспа останется только возможность изредка оперировать AST в макросах.

www_linux_org_ru ★★★★★
()

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

У тебя такой хоть один проект есть? D-шный компилятор весьма быстр, и статическая типизация ловит ошибки еще до начала отладки.

В лиспе интересно *только* оперерирование AST.

www_linux_org_ru ★★★★★
()

>Поэтому возникает такая идея: сделать новый синтаксис для лиспа.

Прожили же 50 лет со старым синтаксисом и ничего

Один тут всех взялся на джаббер пересаживать, другой - лисп переделывать... Ребята, вы чего?

mint ★
()

возьми смоллтолк - там почти такие же возможности по хаканию кода на ходу

ott ★★★★★
()
Ответ на: комментарий от mint

ничего странного, осеннее обострение прогрессирует

ott ★★★★★
()

Не понимаю... Как вообще можно _читать_ код на ЯП, который настолько далёк от реальных человеческих языков. ИМХО именно по этому код на lisp, haskell и других подобных "мозговыносящих" языках выглядит настолько непонятно и нечитабельно. Толи я ещё до этого не дорос, толи у труЪ-программеров как-то ненормально восприятие работает...

Deleted
()

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

> Который бы на первом этапе

Препроцессор, естественно, убивает эту возможность.

Davidov ★★★★
()
Ответ на: комментарий от Legioner

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

anonymous
()
Ответ на: комментарий от Deleted

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

anonymous
()

>во-первых, мне не нравится, что вместо a.b.c я пишу (c-of (b-of a))

ну напиши макру, аналогичную infix, чтобы преобразовывалось ( a dot b dot c) = (a dot (b dot c)) = (:. a (:. b c)) = (x-of a (x-of b (x-of c nil))) = (c-of (b-of a))

>сделать новый синтаксис для лиспа. Который бы на первом этапе преобразовывал
>function m(a) {
> let u=a.b;
> ..
> }
>сначала в
>(" " function (".()" m a)
> ("{;"
> (" " let (= u (dot a b)))
> ..
> (" " return (- (".()" (dot u count)) count)))
>
>и потом - в
>
>(defun m (a)

а зачем нужны странные символы " ", "{;" ?
" " -- это аналог infix, а "{;" -- зачем?

сдаётся, что любую программу, записанную в виде "алгоритма" можно преобразовать в "функциональный" вид, по аналогии с нормальными формами в логике (ДНФ, КНФ).
Получить форму вида map lambda(X) C, где X -- список свободных переменных, C -- констант, потом несколько таких функций объединить, то есть с композицией f(x,c1)=M l(X) C1; g(y,c2)=M l(Y) C2 получить
h(xy,c1c2)=M l(X Y) (C1 C2).
Что-то вроде "разложить линейную комбинацию по базису", по базису функций. А сами функции, в свою очередь, тоже могут быть не совсем независимыми, а выдаваться каким-то функтором, в итоге получить "оптимальное"(в каких-то условиях) разложение на базисные функции; потом как-то определить функтор над этим функтором и т.п.
В итоге, для заданной алгоритмом системы получить разбиение на функции без побочных эффектов (которые удобнее преобразовывать, чем императивный алгоритм). Плюс, иметь разные критерии "оптимальности" разложения и перестраивать его, если критерии изменились.

anonymous
()
Ответ на: комментарий от Deleted

>код на lisp, haskell и других подобных "мозговыносящих" языках выглядит настолько непонятно и нечитабельно

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

jtootf ★★★★★
()

> 1.function m(a) {
> 2. (" " function (".()" m a)
> 3. (defun m (a)
>(последнее преобразование, причём, чтобы по выбору рендерило код либо на лиспе, либо на php, либо на javascript).

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

зачем нужен второй CST? и как можно его получить проще, чем заморачиваясь с парсером, BNF, (каким-то навороченным reader macro?), всё равно ведь придётся разбирать терминальные символы, и выдавать не дерево AST, а что-то вроде (<нетерминал> <терминал> ... )? то есть, рекурсивный парсер вместо построения AST сразу?

тогда 2 уж скорее должно быть что-то ближе к
2'.(" " function (".()" m a)
("{;"
(" " let (u = (a ddot b)))
(:t comment "bebebe")
(" " let (count = ( (u ddot count) ".()" )))
(" " let ( (u ddot c) ".()" x) = (* 34 5))
(" " return ( ( (u ddot count) ".()" ) - count)))

а 2 должно получаться из 2' на промежуточном этапе (и приводиться к более лисповому виду 3)


anonymous
()

> Во-первых, мне не нравится, что вместо a.b.c я пишу (c-of (b-of a)).

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

Ну а ещё, если тебе так надо иметь возможность писать "a.b.c" - сделай такую макру. Тебе никто не запрещает менять синтаксис языка. Чего-то не хватает, что-то не соответствует лично твоим привычкам - возьми и измени это, работы на пять-шесть строк кода.

> сделать новый синтаксис для лиспа.

Ну, и какие трудности? Именно это и есть идиоматический подход в Лиспе.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

> Лисп с человеческим лицом? Одобряю.

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

> А потом от лиспа останется только возможность изредка оперировать AST в макросах.

Потом от Лиспа останется Qi, с возможностью выпадать в низкоуровневый Лисп при необходимости.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

> У тебя такой хоть один проект есть?

Ну, у меня есть. Очень важно иметь возможность изменить код без остановки работы. Почитай, как в NASA правили удалённо код на Лиспе на спутнике.

> В лиспе интересно *только* оперерирование AST.

Ты Лиспа не понял.

anonymous
()
Ответ на: комментарий от Deleted

> Как вообще можно _читать_ код на ЯП, который настолько далёк от реальных человеческих языков.

Код на Java гораздо более далёк от реальных человеческих языков. Просто ты привык к этому говну, и оно кажется тебе "естественным". Почитай:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

> ИМХО именно по этому код на lisp, haskell и других подобных "мозговыносящих" языках выглядит настолько непонятно

Код на них близок к естественному человеческому языку математики. Человеки, для которых математика неестественная, к программированию не способны вообще.

> Толи я ещё до этого не дорос, толи у труЪ-программеров как-то ненормально восприятие работает...

Просто ты не программист вообще, и никогда им уже не будешь.

anonymous
()
Ответ на: комментарий от anonymous

Так.

Для начала, чайники, не учите меня жизни.

Я лиспом занимаюсь с 2000 года. Да, я не писал на нём БОЛЬШИХ проектов.

Но я знаю его достаточно хорошо.

Сейчас почитаю и буду отвечать на остальное.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

> Для начала, чайники, не учите меня жизни.

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

> Я лиспом занимаюсь с 2000 года.

А я - с 91го.

> Да, я не писал на нём БОЛЬШИХ проектов

А я писал. Что дальше?

> Но я знаю его достаточно хорошо.

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

anonymous
()
Ответ на: комментарий от anonymous

>> Код на Java гораздо более далёк от реальных человеческих языков. Просто ты привык к этому говну, и оно кажется тебе "естественным". Почитай:

При чём тут Java? Я не пишу на java 8).

>> Код на них близок к естественному человеческому языку математики.

К математике он действительно близок. Haskell точно. Но только математика ни в каком месте не естественная для человека.

>> Человеки, для которых математика неестественная, к программированию не способны вообще.

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

>> Просто ты не программист вообще, и никогда им уже не будешь.

Ну спасибо...

Deleted
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от Deleted

> При чём тут Java? Я не пишу на java 8).

Любой другой ныне популярный язык обладает ровно теми же недостатками.

> Но только математика ни в каком месте не естественная для человека.

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

> Да да да, а человеки без докторской степени по физике просто не достойны пользоваться микроволновкой и телевизором...

Не передёргивай. Программирование - чисто инженерная работа.

> Ну спасибо...

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

anonymous
()
Ответ на: комментарий от anonymous

>> Любой другой ныне популярный язык обладает ровно теми же недостатками.

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

>> Для быдла может и неестественная, но быдлу не надо программировать. Для инженера же язык математики наиболее естественный и понятный. Не передёргивай. Программирование - чисто инженерная работа. Скажешь, я не прав? Никогда не поверю, что человек с такими ущербными взглядами может быть программистом. И, не путай быдлокодеров с программистами, ок?

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

P.S. Не могли бы вы сбавить тон и куда-нибудь засунуть своё ЧСВ? Разговаривать с вами очень неприятно.

Deleted
()
Ответ на: комментарий от Deleted

> Ничего не бывает без недостатков. Простота использования - это плюс. А сложность понимания - это минус.

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

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

Это не "мегаязык", это метаязык. Который может легко трансформироваться в любой язык, который годится для любой конкретной области.

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

Хорошо будет. Глюкавого говна не будет.

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

Барахло не нужно, а хороший софт пишут инженеры, пишут для себя (и потому - пишут хорошо).

> Разговаривать с вами очень неприятно.

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

anonymous
()
Ответ на: комментарий от anonymous

> а зачем нужны странные символы " ", "{;" ? " " -- это аналог infix, а "{;" -- зачем?

"{" - это то, во что завернуть. ";" - это то, чем разделять.

Так, кое что интересное написали. Насчёт MBase - я не думаю, что в наше время конечному пользователю нужно писать парсеры. Языков уже достаточно много. Достаточно заложить в систему несколько наиболее популярных парсеров и иметь хорошие средства управления ими. Т.е., возможности по написанию парсеров уходят на второй план. Хотя ещё погляжу, если будет время.

Т.е., я предлагаю делать, в целом, как в лиспе - сначала читаем дерево целиком и получаем дерево, а не поток лексем. Дальше напускаем нечто типа macroexpand.

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

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

Например, есть совершенно практическая задача. Программы на JavaScript выглядят очень уродливо, поскольку они должны быть кроссбраузерными. Этот вопрос решается макропроцессором. Остаётся второй вопрос - выбросить из javascript-библиотеки функции, ненужные для данного приложения. На С этот вопрос выполняется компоновщиком, а в Javascript такого понятия нет. Особенно интересно становится, когда часть приложения находится на клиенте, часть на сервере. Часть функций сервера используются клиентом, часть - нет. Значит, для данной конкретной инсталляции можно выбросить ненужные на сервере функции и провести соответствующую оптимизацию.

> А мне крайне неприятно разговаривать с воинствующим невежеством, отстаивающим своё право быть невежественным и глупым

Что удерживает Вас в теме, где нет ни одного достойного собеседника? Идите творить своё неглюкавое неговно.

Про R-lisp и Qi я прочитаю, спасибо за ключевые слова.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

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

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

> Насчёт MBase - я не думаю, что в наше время конечному пользователю нужно писать парсеры. Языков уже достаточно много.

Однако, именно парсер ты и хочешь написать.

> Языков уже достаточно много.

Ты забыл про DSL. Их никогда не бывает "достаточно много". Особенно если они на языке, близком к естественному - тут проще рукописного парсера ничего не может быть. Разве что, движок нужен GLR, а это мало кто из генераторов парсеров умеет пока.

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

С DSL это не пройдет. Половине DSL вообще парсер не нужен, достаточно S-выражений, другая же половина требует узкоспециализированных синтаксисов.

> Про R-lisp и Qi я прочитаю, спасибо за ключевые слова.

Обязательно почитай исходники Qi, это наилучшая демонстрация того, как делать из Лиспа другие языки.

anonymous
()
Ответ на: комментарий от den73

> Т.е., возможности по написанию парсеров уходят на второй план. Хотя ещё погляжу, если будет время.

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

anonymous
()
Ответ на: комментарий от anonymous

>> В лиспе интересно *только* оперерирование AST.
>Ты Лиспа не понял.

разверни мысль, в чём фишка.
Вот есть "обычный" язык co статической типизацией. В итоге, к семантике сигнатур функций жёстко привязаны типы, компилятор проверяет семантику и выдаёт корректный с учётом типов код. В итоге, мы не можем заменить любую функцию на суперпозицию её и любой другой функции, нужно писать интерфейс, совместимый по типам, к которому, желательно, имеет доступ компилятор в compile-time, а не просто программа в run-time. Этот интерфейс является комбинатором в функциональном смысле. Рефакторинг тоже является таким интерфейсом.
В Лиспе за счёт динамической типизации и того что в элемент списка можно *единообразно* подставить атом = (список)=(функция параметры ..) = (функция1 функция2 параметры' ..) , любая функция (с подразумеваемой совместимой семантикой) становится комбинатором, код становится расширяемым в любой точке, это уникальная возможность, да.
Но насколько она действительно необходима? Жертвуем эффективностью выполнения на реальном железе за счёт потенциальной расширяемости. Хотя расширяемость можно обеспечить просто нормальным интерфейсом к AST компилятора и соглашениями вызова compile-time/run-time.
Если известно, что код расширяться не будет (например, наполовину состоит из библиотечных вызовов), то от потенциальной универсальности модели исполнения ни холодно, ни жарко.

anonymous
()
Ответ на: комментарий от anonymous

> разверни мысль, в чём фишка.

В том, что фишка - это оперирование AST + инкрементальная компиляция. Без второй части возможности первой весьма ограниченны.

> Но насколько она действительно необходима?

Фатально необходима. Без такой фичи очень непросто.

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

> Жертвуем эффективностью выполнения на реальном железе за счёт потенциальной расширяемости.

Вовсе нет. Слаботипизированное AST не мешает иметь строго типизированный, эффективно компилируемый код.

> Хотя расширяемость можно обеспечить просто нормальным интерфейсом к AST компилятора и соглашениями вызова compile-time/run-time.

Можно, но сложно. Чем сложнее AST, тем сложнее им манипулировать.

Кроме того, без инкрементальной компиляции это всё лишено смысла.

anonymous
()
Ответ на: комментарий от den73

>от anonymous 22.10.2008 14:12:07

тут 2-3 разных анонимуса, я -- не он. Отвечаю на свои сообщения.

>"{" - это то, во что завернуть. ";" - это то, чем разделять.

или " " -- правило вывода из BNF, "{;" -- шаблон visitor для обхода дерева

> Можно, но не нужно. Есть некоторые преобразования, которые делают любые компиляторы.

да, например, что-то похожее есть в MBase (там "верхний" язык компилятора описывается на "нижнем", который в итоге описывается через Y комбинатор, лямбды для лексической видимости, и "базовый" лисп). Сюда же можно добавить CPS, хвостовую рекурсию и т.п.
"Нормальные формы функций" было бы интересно получить лично мне, чтобы эффективно их исполнять + наглядно их представить в виде аспектов, показать что-то вроде schematic tables из programming by example, ну да это всё лирика.

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

на конкретном наборе яваскрипт-приложений, изменится приложение, и заново строить образ (ага, вот например из готового образа выкинуть лишние функции). Можно посмотреть например, Kamen Lisp http://www.progmatism.com/software/kamen/index.php , простой JS движок вроде SEE (http://tkhtml.tcl.tk/hv3.html -> http://www.adaptive-enterprises.com.au/~d/software/see/).

anonymous
()
Ответ на: комментарий от anonymous 

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

Например, на Схеме можно так сказать (если бы в ней 
не было рекурсии):

(define Y
 (lambda (fn)
  ((lambda (proc)
    (fn (lambda (arg) ((proc proc) arg))))
   (lambda (proc)
    (fn (lambda (arg) ((proc proc) arg)))))))

anonymous
()
Ответ на: комментарий от anonymous

> Разве что, движок нужен GLR, а это мало кто из генераторов парсеров умеет пока.

а зачем именно GLR с O(n^3) в худшем случае? можно взять packrat c O(n) (хотя на простых грамматиках разницы может и не быть)

> Половине DSL вообще парсер не нужен, достаточно S-выражений, другая же половина требует узкоспециализированных синтаксисов

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

anonymous
()
Ответ на: комментарий от anonymous

> а зачем именно GLR с O(n^3) в худшем случае?

Тебе жалко, что ли?

Предложения естественного языка редко бывают более пары десятков слов.

> можно взять packrat

Не пойдёт.

> второй половине нужен парсер для синтаксиса, первой -- для семантики.

Для семантики уже не парсер нужен, а транслятор.

> Чтобы построить однообразное семантическое дерево.

Не может оно быть однообразным. Вот только что закончил один eDSL, у которого не AST, а весьма циклический граф.

anonymous
()
Ответ на: комментарий от anonymous

> фишка - это оперирование AST + инкрементальная компиляция. Без второй части возможности первой весьма ограниченны.

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

> Слаботипизированное AST не мешает иметь строго типизированный, эффективно компилируемый код.

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

> Чем сложнее AST, тем сложнее им манипулировать.

ок, какие возможности именно лиспа облегчают именно работу с AST?
именно макры, `(.. ,x ,@y) ?
visitor pattern, pattern matching можно реализовать в любом языке

> Кроме того, без инкрементальной компиляции это всё лишено смысла.

можно реализовать на уровне встраиваемого лиспа в си (например) движок "основного приложения". Чуть проще, чем реализовать свой линкер, да. Потом правда правило Гринспуна вылезет :)

anonymous
()
Ответ на: комментарий от anonymous

> Это можно реализовать и встроенным лиспом + подгружаемая .so + внешний компилятор для этой .so

По одной .so на каждое исполненное выражение? А не жирно будет?

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

Естественно.

> ок, какие возможности именно лиспа облегчают именно работу с AST? именно макры, `(.. ,x ,@y) ?

Именно, quasiquoting.

> visitor pattern, pattern matching можно реализовать в любом языке

Для большинства задач это overkill. Слишком сложно. Лисп же простые задачи решает просто, тем и силён.

anonymous
()
Ответ на: комментарий от anonymous

> По одной .so на каждое исполненное выражение? А не жирно будет?

мда, тогда придётся делать свой линкер, http://linker.iecc.com/ :))

anonymous
()
Ответ на: комментарий от anonymous

> хочется, правда, curly braces вместо

Ещё одного Си по голове стукнули? Что вы все находите в этом уродском синтаксисе?!?

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

anonymous
()
Ответ на: комментарий от anonymous

> Ты забыл про DSL. Их никогда не бывает "достаточно много". Особенно если они на языке, близком к естественному - тут проще рукописного парсера ничего не может быть.

Лично мне парсеры языка, близкого к естественному, не нужны, хотя я не спорю, что кому-то они могут пригодиться. С моей точки зрения, в лиспе органично выглядят и легко реализуются DSL именно в лисповом синтаксисе. Простые DSL - это просто наборы макросов (уже получается то, что не снилось другим языкам). В остальных случаях (напр., screamer, ap5) используются code walkers.

HOP - надо почитать подробнее. Не понравилась частность подхода. Я хочу более общий подход - сегодня я буду генерить php/javascript/html, а завтра delphi/sql/tsql. В целом, моё частное мнение состоит в том, что синтаксис javascript лучше, чем у лиспа. Возможно, я просто ещё мало работал с javascript. Я почему-то думаю,что если туда добавить квазицитирование и возможность непосредственно вставлять теги, то будет то, что надо.

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

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

Могу рассказать о своём (правда, очень небольшом) опыте использования lisp для генерации js. Всё сломалось очень легко и тупо. В js массово используется МП, т.е. иногда нужно создавать строки js кода из js же. В js это делается удобно по очень простой причине - там можно разделять строку и одинарными, и двойными кавычками.

В лиспе этого нет. Да,я написал ридермакро, позволяющее писать строку вот так:

#q~Это'@"##\строка~

Но при этом сломалось slime и lisp-mode в емаксе. А это - плохо.

Кроме того, parenscript позволяет писать a.b, хотя это не по-лисповому получается. По лисповому было бы писать (slot-value a 'b).

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

Далее можно прийти к такому же выводу и для html, хотя это уже более спорно. И т.п.

Остальное потом.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

> HOP - надо почитать подробнее. Не понравилась частность подхода.

уточнение: он не только серверный, там идея как раз single source для клиента и сервера. Ещё по ссылке с HOP можно посмотреть язык Links, примерно то же самое, но с Ocaml-подобным синтаксисом. В ссылке про Links интересная публикация про SLinks, там генерируются SQL запросы из OCaml-подобного языка и *оптимизируются*.

> Я хочу более общий подход - сегодня я буду генерить php/javascript/html, а завтра delphi/sql/tsql.

добавить новые кодогенераторы, и вперёд. Для php/js/html также интересен Haxe/Neko, см. http://haxe.org/doc/intro , "лисповый" подход как раз интересен если придётся перенацеливать кодогенератор на другой целевой язык (на выходе).

anonymous
()

> язык должен быть правильно построен по частотам - более часто встречаемые идиомы должны быть более короткими

если уж на то пОшло, то curly braces тоже не удобны (не удобнее round braces), и рулят только на программерской раскладке Дворака, где их можно нажимать без кнопки Shift. А рулят [] или `', которые нажимаются без шифта. А конструкции, которые встречаются реже, чем блоки кода можно обозначить и символами с шифтом, диграфами, триграфами, и т.п.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3
← Странно-интересное
Development
декомпиляторы Java →