LINUX.ORG.RU

CL быстрее прочих :)


0

3

Новый, и как всегда красивый, пример кодогенерации от swizard

http://swizard.livejournal.com/158763.html

на этот раз решение задачи http://shootout.alioth.debian.org/u32q/benchmark.php?test=fannkuchredux&lang=...

★★★★★

Последнее исправление: psv1967 (всего исправлений: 1)

Ответ на: комментарий от Macil

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

Нужны типы - используйте CLOS, нужна трансформация параметров (и не только &body - любых) - пишите макрос. Нужно совместить - скрещивайте первое со вторым. Сложно (субъективный фактор!) - валите на винфак^W^W^W используйте штангу или что там вам по душе.

А то сами себя загнали в угол: «foo и bar *любые* допустимые S-выражения» - т.е. их вообще никак не разделить и не проверить на валидность, а потом жалуемся...

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

>Естественно логический, поскольку это непосредственно следует из использования s-выражений.

Это «следует» из твоего понимания «использования s-выражений». По-моему, лбая кодогенерация из каких-то параметров == трансформация кода (ибо в общем случае что за параметры - хз). И, поскольку в лиспе всё на списках (если не трогать ридер - К.О.), то отношение к DSL определяется только «DS областью». Да, это размывает определение что является еDSL в лиспе, а что нет.

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


НА сколько сильно должен отличатся от базового языка? С учётом того, что в лиспе с макрами можно делать (и делают) весьма различные «трансформации кода», и часто без определённой «DS области» (или она ограничивается одним макросом), и всё выглядит как список, то чем тогда «принципиально» отличается некий eDSL от другого кода на лиспе? ИМХО - только привязкой к «DS области».

Я тут подглядел, что язык программирования определят набор лексических, синтаксических и семантических правил. Если говорить о eDSL на основе s-выражений, то, лексические и синтаксические правила можно не учитывать. Таким образом, eDSL в CL должен иметь отличные от него семантические правила (иначе это просто API). Что безусловно требует наличия стадии трансформации кода (иначе откуда иная семантика?).


Демагогия в чистом виде (да, ИМХО)

(иначе не имеет смысла вообще говорить на эту тему)


а сможешь? ;)

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

>Нужна вазочка для пряников - используйте стиральную машину.

Аналогии такие аналогии... «Хочу использовать ночной горшок как вазочку для пряников, но, блин, запах!...» Отлично - сри в вазочку для пряников!

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

В следующий раз, чтобы обогнать gcc, swizard прикрепит к программке небольшой оптимизирующий компилятор, на правах пакетика)

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

Энто не настоящий К.О.!1

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

Контрпример: Например генерация произвольного бреда, где параметр - число, задающее глубину бреда. Очевидно - кодо^Wбредогенерация без трансформации.

поскольку в лиспе всё на списках

(listp 1) => nil

если не трогать ридер - К.О.

(listp `'(1 2 ,@'(3 4))) => t

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

И кстати, «CLOS и типы» - нет же никакой связи? Вон в SBCL чтобы отобразить types в classes целая эпопея в pcl написана. И если мы определяем тип - это ортогонально использованию классов (например нет возможности проводить диспетчеризацию в методах по _типам_ - по классам же). Хотя обратное определение - типов из классов и структур - есть. Разве в практике программирования на CL типы (те што deftypes) и классы как-то связаны? Ну а «типы штанги», которые тут упомянались, скорее нужно делать (если нужно) макросами и структурами, без задействования CLOS.

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

>Контрпример: Например генерация произвольного бреда, где параметр - число, задающее глубину бреда. Очевидно - кодо^Wбредогенерация без трансформации.

Почему? Из (bred 13) получили (иди в жопу, недоумок, ты нихера не понимаешь, я тебе не мудак какой-нибудь, лисп только и годен для задрачивания свизарда и для понтов архимага «я им бабки лопатой гребу и кучу фана имею»...) и так на 13 уровней - мы один список трансформировали в другой (ну да, у макр предназначение такое: вместо одного списка подставлять нечто другое =)

поскольку в лиспе всё на списках


(listp 1) => nil


эээ... что ты хотел этим сказать?

(listp `'(1 2 ,@'(3 4))) => t


1. сахар; 2. всё равно - списки :)

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


и что? как только «прибиндили» - имя (символ) о типе значения не знает нифига... Или ты о чём?

И кстати, «CLOS и типы» - нет же никакой связи? Вон в SBCL чтобы отобразить types в classes целая эпопея в pcl написана. И если мы определяем тип - это ортогонально использованию классов (например нет возможности проводить диспетчеризацию в методах по _типам_ - по классам же). Хотя обратное определение - типов из классов и структур - есть. Разве в практике программирования на CL типы (те што deftypes) и классы как-то связаны? Ну а «типы штанги», которые тут упомянались, скорее нужно делать (если нужно) макросами и структурами, без задействования CLOS.


извини - я не понял, ты что-то спрашиваешь или утверждаешь?

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

> Это «следует» из твоего понимания «использования s-выражений».

В смысле? s-выражение в CL однозначно определяют набор лексических и синтаксических правил, иначе ридер просто не сможет это прочитать. При чём тут моё понимание?

По-моему, любая кодогенерация из каких-то параметров

== трансформация кода



Извини, но в русском языке слово трансформация имеет другой смысл.

Демагогия в чистом виде (да, ИМХО)


Хм, справочники утверждают, что демагогия основанна на намеренном искажении фактов. Укажите пожалуйста, какие факты я искажаю? И это не тот вопрос, в котором можно прикрываться ИМХО, ибо не допускает многозначных трактовок.

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

> иди в жопу, недоумок, ты нихера не понимаешь, я тебе не мудак какой-

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

архимага «я им бабки лопатой гребу и кучу фана имею»



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

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

1) Кодогенерация не всегда трансформация. Пример с бредом - это на самом деле намёк на построение опорных деревьев - параметр число, а не список.

2) Что не всё в лиспах список. Quote - `поскольку в лиспе всё на списках'

3) Что reader хоть трогай, хоть нет - не имеет отношение к тому всё там на списках или нет. Quote - `поскольку в лиспе всё на списках (если не трогать ридер - К.О.)'

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

5) Утверждаю - не надо класть пряники в стиральную машину.

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

> swizard — Лучший!!!

То есть то, что у него кода почти в 2 раза больше, чем у жабы — это ничего страшного? А внутри ручной закат солнца.

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

>s-выражение в CL однозначно определяют набор лексических и синтаксических правил, иначе ридер просто не сможет это прочитать

использование == задание (определение)?

справочники утверждают, что демагогия основанна на намеренном искажении фактов.


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

Но ладно:

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


допустим

Если говорить о eDSL на основе s-выражений, то, лексические и синтаксические правила можно не учитывать.


К.О. mode? «всё есть список» (ну только вспомни про атомы...).

Таким образом, eDSL в CL должен иметь отличные от него семантические правила


почти любой макрос вводит «свои семантические правила». Либо весь CL «отличен сам от себя», либо это очень условное «утверждение».

Что безусловно требует наличия стадии трансформации кода (иначе откуда иная семантика?).


Ещё раз - 'почти любой макрос вводит «свои семантические правила»', любой макрос занимается трансформацией формы своего вызова в нечто иное, и любой eDSL в лиспе не делает ничего «нового» (по отношению к коду), и отличить его можно только предметной областью (да, ИМХО).

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

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

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

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

>1) Кодогенерация не всегда трансформация. Пример с бредом - это на самом деле намёк на построение опорных деревьев - параметр число, а не список.

в лиспе с использованием макр формально - всегда, ибо идёт «трансформация» одного списка в нечто иное

2) Что не всё в лиспах список.


ну да - кроме атомов. К.О.?

3) Что reader хоть трогай, хоть нет - не имеет отношение к тому всё там на списках или нет. Quote - `поскольку в лиспе всё на списках (если не трогать ридер - К.О.)'


опять не понял - сорри

4) О том что всё сложнее...


и чё?

5) Утверждаю - не надо класть пряники в стиральную машину.


ну и ходи вонючкой

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

Как извращаться? Разобраться, как аффинити выставлять? Если это для вас рокет-сайнс, идите лучше улицы мести.

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

> То есть, чтобы обогнать даже херово сгенерированный жабокод, приходится так извращаться? Кхм, зачем?

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

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

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

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

> То есть то, что у него кода почти в 2 раза больше, чем у жабы — это ничего страшного? А внутри ручной закат солнца.

1) должен заметить, что оный закат происходит отнюдь не в ручную

2) само решение короткое, и декларативное. лучше чем у жабы однозначно.

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

Я согласен с тобой по части «макросы/dsl». И про трансформацию, просто нужно выражаться немножко более консистентно.

2) Что не всё в лиспах список.

ну да - кроме атомов. К.О.?

К.О. то К.О. на этот раз, но не очень конструктивный Капитан. Вот возьми любой язык - что такое список, просто гетерогенный и динамический кортеж объектов, один из типов данных которые часто используют - можно им «мерять» XML, например, ну и всё. Но вот в лиспах, по МакКарти, решили - а давайте списками будет ещё и программы записывать (ну как тот же XML, только на вид приятнее), сказано - сделано. Это такая уникальная особенность (отсюда символьные вычисления (в лисповом смысле), макросы как трансформации AST -> AST, где AST представлен весьма сыро - как списки списков). Но эта особенность (списки и символы -> символьные вычисления -> макросы -> DSL, по нарастающей) хоть принципиальна, но не достаточна чтобы приходить и кричать «всё список!». Поясню - вот ты говоришь атом, но что такое атом? Атом это не список :) Массив (сколь угодно мерный) - атом, структура - атом, объект класса - атом. Т.е. список это один тип данных - мощность единичка, а атомы - это счётное множество всевозможных (в том числе определяемых пользователем) типов данных (в том числе разных классов CLOS). Разница получается бесконечно большая :) Скорее всё atom (ну и списки сбоку, программы будим ими пейсать, макросы делать на них).

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

Как я сейчас завидую тем у кого не западает клавиша «К» :)

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

>один «не компетентный человек» может задать столько вопросов, что и 100 «компетентных» не ответят... нет не «не смогут», просто не захотят :(

Это ты так «по-умному» сказал «не спорь с дураком - ...»? =)

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

вот видишь? ажно перетончил :)

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

> почти любой макрос вводит «свои семантические правила».

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

Когда мы смотрим iterate (или даже loop), то видим, что внутри блока iter (loop) для контроля над процессом выполнения используются символы, которые не являются функциями или макросами. Конструкции типа (for x from 0 to 10) не являются верными с точки зрения CL и попытка использовать их вне блока iter закончится ошибкой. А iterate определяет множество таких конструкций. Таким образом можно смело утверждать, что iterate определяет отдельный язык, который расширяет семантические правила CL и который можно использовать внутри блока iter. Но такая техника, как я уже говорил, на практике редко.

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

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

>К.О. то К.О. на этот раз, но не очень конструктивный Капитан.

ну уж какой есть =)

Вот возьми любой язык...


Теперь это «конструктивный Капитан»? Я о чём - я давно нить потерял в «непротиворечивых разногласиях» в полемике с тобой. С чего всё началось? Мне «запало в душу» «foo и bar *любые* допустимые S-выражения» - ну ограничь валидность foo и bar. Или я опять чего-то не догоняю.

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

>а я скажу: «это пример ненужного и негодно-жирного троля».

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

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

> Как извращаться? Разобраться, как аффинити выставлять? Если это для вас рокет-сайнс, идите лучше улицы мести.

Аффинити — не извращение. Извращение — длинная портянка лиспокода для него. И всё ради того, чтобы обогнать жаву, портянка которой в два раза короче. Клиника же.

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

Это ты Macil сказал - и в принципе всё правильно. Если в defpackage дважды использовать :lock то про это рестарт и будет жаловаться. Но и про пряники в стиральной машине было и про «всё списки» тоже (и про reader, который как бы фича, но на самом деле обычный инструмент), прокрути наверх - посмотри.

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

>Конструкции типа (for x from 0 to 10) не являются верными с точки зрения CL

[почти] все макросы идут лесом... И это твоя т.з. (К.О. mode - у CL т.з. не может быть в принципе =)

CL и попытка использовать их вне блока iter закончится ошибкой.


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

Таким образом можно смело утверждать...


...что дон Кихот всю жизнь боролся со своими злейшими врагами. И?

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


Ладно. Ты видишь принципиальную разницу, я - нет. На этом и разойдёмся

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

>Это ты Macil сказал - и в принципе всё правильно. Если в defpackage дважды использовать :lock то про это рестарт и будет жаловаться. Но и про пряники в стиральной машине было и про «всё списки» тоже (и про reader, который как бы фича, но на самом деле обычный инструмент), прокрути наверх - посмотри.

Я посмотрел в зеркало - вроде не баран. Но ощущение почти такое...

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

> Аффинити — не извращение. Извращение — длинная портянка лиспокода для него. И всё ради того, чтобы обогнать жаву, портянка которой в два раза короче. Клиника же.

Смею заметить, что это еще при учете, что «жаба генерирует плохой код».

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

> попытка передавать макросам не то, что они ожидают,

всегда закончится ошибкой. И?


Как и функция. Мы говорим про семантические правила, а не про поведение.

...что дон Кихот всю жизнь боролся со своими злейшими врагами. И?


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

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

> 2) само решение короткое, и декларативное. лучше чем у жабы однозначно.

Это ты про тот 80-строчный макрос? Кхм, мы в разных мирах живем, видимо.

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

Аффинити — не извращение. Извращение — длинная портянка лиспокода для него. И всё ради того, чтобы обогнать жаву, портянка которой в два раза короче. Клиника же.

На шутауте программы, написанные каноническим способом, плетутся в конце. Это не соревнование лаконичного кода.

Кстати, ты ж лисп не осилил? Чего тогда катишь бочку на, что не понимаешь?

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

Я посмотрел в зеркало - вроде не баран. Но ощущение почти такое...

Да нет, тут просто соревнование в том кто самый КО-шный капитан)

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

archimag говорит, что есть макросы которые ожидают чего-то, а есть те что ничего не ожидают а просто вклеивают свои body и подставляют прочее.

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

> Аффинити — не извращение. Извращение — длинная портянка лиспокода для него. И всё ради того, чтобы обогнать жаву, портянка которой в два раза короче. Клиника же.

Смею заметить, что это еще при учете, что «жаба генерирует плохой код».

В два раза длиннее, в три с лишним раза быстрее, всё често :) Сишное решение, при всей многословности лиспа, всего на 80 с копейками байт короче.

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

У хацкеля pidigits не плетётся :)

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

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

На шутауте программы, написанные каноническим способом, плетутся в конце.

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

Это не соревнование лаконичного кода.

А как же пропагандируемое тобой изящество CL'я, особенно на макросах?

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

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

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

А как же пропагандируемое тобой изящество CL'я, особенно на макросах?

А я для шутаута ничего и не пишу.

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

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

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

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

>Мы говорим про семантические правила, а не про поведение.

тогда при чём здесь передача параметров iter-а другим макросам?

Я когда что-то обосновываю стараюсь выстроить логически верную цепочку рассуждений


Я не вижу в том, что некоторые макросы CL обрабатывают свои параметры в большей степени сами, что-либо исключительное - это всё возможности CL. Строить на различиях в обработке параметров систему «детектирования» DSL-ей - ваше право. Но это остаётся вашим ИМХО - не более.

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

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

Я говорю о конпеляторе, а не о стандарте. Чуешь разницу?

mv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.