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)
Ответ на: комментарий от archimag

Под это определение cffi:defcstruct, очевидно, не подходит.

Если чё, оператор defcstruct определяет foreign-тип. Это ли не DSL?

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

>язык это тогда: 1) ты ввел операторы 2) их можно комбинировать и в идеале 3) комбинацию операторов можно подставить вместо любого из операторов

Это какой-то не обычный у вас язык. Язык - это цепочка символов какого-то алфавита с назначенной семантикой. Есть ли там операторы и комбинации - дело десятое.

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

>В cffi:defcstruct передаются просто пары - «имя поля»/«тип поля», тупо список пар. Извини, называться языком (тем более метаязыком) это никак не может.

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

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

> Только «свое время» как-то неоправданно затянулось.

Да, это была целая эпоха. Видимо, из-за того, что не было конкуренции. Заметь, что до VC 6.0 был на винде и досе целый зоопарк компиляторов. И где они сейчас? Где теперь некогда великий Watcom? Zortec, Borland и еще N штук?

Я уже порядком отошел от Си/Си++. Кто сейчас генерирует более быстрый код из forte/msvc/icc/gcc?

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

>Кто сейчас генерирует более быстрый код из forte/msvc/icc/gcc?

На числодробилках однозначно icc.

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

> Но имеется еще программист Д, который сравнивал локи не по оффсету в массиве (или разности указателей), а по физическому адресу, скастованному к ЗНАКОВОМУ 32-разрядному целому

В таких случаях нельзя вводить в программу перемещающий GC.

2. Откуда С должен был знать, что перетасовывать нельзя?

Здравый смысл.

если речь идет *вообще* о сборке мусора в с/с++

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

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

> В общем, грань между DSL и API весьма условная.

В результате сам термин «DSL» практически потерял смысл.

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

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

данных в памяти и способа их интерпретации. Этот язык оперирует

«типами», «чужеродными типами», «параметрами типов», «структурами»,


«слотами структур», «расположением слотов» и пр.



Нет, не согласен.

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

Для определения foreign-структуры нам необходимо указать её имя и упорядоченный набор слотов, каждый из которых характеризуется именем и типом. Это нам надо сделать не зависимо от того, каким именно образом мы будет создавать эту структуру. Поскольку для описания имён и типов в CL однозначно будут использоваться символы, то у нас, фактически, есть только один вариант интерфейса. Т.е. cffi:defcstruct это ни какой-то специальный синтаксис, а просто самый прямой и естественный способ решения проблемы в рамках традиционного для CL синтаксиса. А оформление данного решения в виде макроса позволят прозрачно рулить временем выполнения этого кода и избавляет от необходимости квотировать символы.

Ни о каком Domain Specific Language тут говорить нельзя.

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

> Стоит пару вложенных друг в друга let-cond'ов сделать и гемора не разгребешь, особенно, если пишешь макрос.

Слайды!Слайды! хочется видеть живой пример.

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

> defcstruct - это именно язык для задания расположения элементов данных в памяти и способа их интерпретации.

Так получается, что и ctypes в Питоне - это DSL? Ж)

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

> язык это тогда: 1) ты ввел операторы 2) их можно комбинировать и в идеале 3) комбинацию операторов можно подставить вместо любого из операторов

Это какой-то не обычный у вас язык. Язык - это цепочка символов какого-то алфавита с назначенной семантикой. Есть ли там операторы и комбинации - дело десятое.

все таки полезные определения (вернее языки :) полезнее точных (минималистических)

... все мы помним, что в швейцарии есть по крайней мере одна корова у которой по крайней мере один бок чёрный :)

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

> Ты бредишь.

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

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

> balodja пожаловался, что Грэхэм для определения ADT использует списки, так что нужно отдельно заводить селекторы, а если про это забыть и залеть в них «грязным» cdr (чему язык не препятствует), то может случиться беда.

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

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

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

Хорошо. У тебя неправильно сформировавшееся мнение о DSL. Как минимум, два человека, знакомых с лиспом (раз ты полагаешься на авторитетные мнения =), утверждают, что CFFI включает DSL для решения специфичных проблем, связанных со взаимодействием с внешним миром. Ты говоришь, что это никакой не DSL, ибо единственный разумный вариант решения этого вопроса, и вообще, так и принято в лиспе делать. Но разумность и общепринятось варианта не только отменяет того факта, что это DSL, но и утверждает то, что использование DSL разной степени проработанности и насыщенности - это нормальная, общепринятая лисповая практика. CFFI, CL-WHO - это примеры большого DSL, сконцентрированного на решении обширной проблемы. Единственный define-foo-bar в какой-нибудь другой библиотеке (define* в CL-V4L2 :) - маленький DSL, решающий частную микропроблему.

Реально сложно отделить DSL от API, если программы на DSL и на языке с использованием API имеют одинаково выглядящий синтаксис (sexp'ы).

Если ты согласишься с формулировкой, что DSL - это не только «большой DSL», но также и «микро-DSL», то можно считать, что стороны пришли к консенсусу :)

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

Ты OnLisp вообще видел? Если нет, то смотри туда. Если да, то ты явно не дочитал мой пост, который цитируешь.

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

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

> > balodja пожаловался, что Грэхэм для определения ADT использует списки, так что нужно отдельно заводить селекторы, а если про это забыть и залеть в них «грязным» cdr (чему язык не препятствует), то может случиться беда.

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

То есть cons/car/cdr — это твой хрустальный МПХ? Сочувствую. На дворе 21ый век и существует миллиард более выразительных средств для работы с данными, а он все байты счита^W^Wв cons-ячейках ковыряется.

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

> существует миллиард более выразительных средств для работы с данными

Например? Заметь, ты отчего-то постоянно избегаешь конкретики.

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

> Хорошо. У тебя неправильно сформировавшееся мнение о DSL

Моё суждение основано на достаточно известных публикациях на эту тему (начиная с Рэймонда и Фаулера) и на собственном критическом опыте использования. С понятием DSL я познакомился заметно раньше, чем с лисп и не считаю, что в CL должно использоваться какое-то своё понятие о DSL.

Кроме того, я использовал DSL в двух достаточно успешных проектах, а история создания restas это история отказа от DSL в пользу использования более естественного кода на CL.

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

раз ты полагаешься на авторитетные мнения


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

Реально сложно отделить DSL от API


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

Если ты согласишься с формулировкой, что DSL - это не

только «большой DSL», но также и «микро-DSL»



Я не понимаю, что реально означает это утверждение и поэтому не могу с ним согласиться.

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

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

Пожалуй, больше не буду отвечать. Чтобы опять не превращать тред в помойку.

P.S. И да, в моих последних фразах намеков нет. Странно, что ты их там увидел.

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

Ты и до этого не отвечал почти. Только рожи загадочные корчил.

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

Никаких алгебраических типов в треде не было

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

лучше бы Гоголя почитал

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

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

> MHO archimag'а абсолютно непробиваемо... :)

Какое ещё ИМХО? Я всего лишь прошу логических аргументов, а не веры, ибо с последним у меня всегда было плохо.

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

> Нет ничего более сумасбродного в русской литературе 19 века

чем петербургские рассказы.


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

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

> См. аргументацию dmitry_vk выше

Я смотрел. Однако, эта аргументация основывается о понятии о языке и может быть применена в любой осмысленной последовательности символов. У нас же речь идёт о DSL. На что я и обратил внимание в своём ответе.

Я завершаю спор.


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

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

>Я всего лишь прошу логических аргументов...

«Если говорить о eDSL на основе s-выражений, то, лексические и синтаксические правила можно не учитывать.» - это логический аргумент? Или всё-же IMHO? Мне вот ближе, к примеру, «The embedded DSL inherits the generic language constructs of its host language - sequencing, conditionals, iteration, functions, etc. - and adds domain-specific primitives that allow programmers to work at a much higher level of abstraction.» - вот отсюда: http://c2.com/cgi/wiki?EmbeddedDomainSpecificLanguage

Заметь - ни слова о трансформации, только «примитивы»

Ну и, как обычно, всё свелось к «терминологическому срачу». «Скучно, господа...»

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

Очень многие макросы в CL используют параметр &body, в котором типично передаётся код, но он практически никогда специальным образом не обрабатывается, а вставляется как есть, его окружают плюшками разными, но никакой стадии трансформации нет.

Ну а многие макросы наоборот - разбирают свои аргументы, в том числе при &body. Например в cffi (define-foreign-type, defcstruct, defcfun содержат обработу арументов в том числе при &body - содержат ,(loop от body) или вызывают функцию которая содержит) есть такой DSL - {(имя тип)}*. В asdf defsytem тоже разбирает options. Макросы в sbcl/src/code/compiler/macros.lisp, meta-vmdef.lisp содержат ,(parse-что-то от body) - начиная от типичных parse-body и parse-defmacro до parse-deftransform и parse-define-vop.

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

У лиспа с DSL'ами одна, маленькая, крохотная проблемка. Представим себе простенький DSL (dsl (dsl-compose (foo ...) (bar ...))), где foo и bar *любые* допустимые S-выражения, dsl-compose - операция композиции

А теперь программист написал (dsl (dsl-compose (bar ...) (foo ...))) Интересный вопрос, а *что* будет? Как проверить, желательно хотя бы на уровне макроразвертывания, что программист перепутал порядок аргументов? И начинается... Про проверку того, что foo сможет принять результаты из bar я вообще молчу.

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

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

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

Я всегда думал что синтаксис не играет роли - ну какая разница на чём написан алгоритм на Python или на CL (при условии не использования в CL фич которых нет в Python). А вот семантика - да, играет большую роль. Т.е. DSL это средство определения семантики:

(defcstruct foo
  (a :int)
  (b :int))

Пока мы не привязали семантические атрибуты к телу defcstruct, представляющему AST (т.е. вообще-то по барабану - что там за синтаксис), выражение (a :int) вообще будет выглядить (в семантике CL) как вызов функции a, но а в контексте семантики макроса defcstruct - это описание поля структуры.

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

Вот вот - так и с DSL, domain specific они не потому что как-то странно выглядят (не так как CL) в синтаксисе, а из-за смысловой нагрузки/семантики которую к ним привязали и которой в базовом CL нет.

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

> «Если говорить о eDSL на основе s-выражений, то, лексические и

синтаксические правила можно не учитывать.» - это логический

аргумент? Или всё-же IMHO?



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

and adds domain-specific primitives that allow programmers to work

at a much higher level of abstraction



Отлично, но что такое «domain-specific primitives»? Работая над любой задачей мы пишем функции и структуры данных, позволяющие работать с понятиями предметной области на более высоком уровне. Очевидно, однако, что это не те примитивы. Так чем же отличаются эти «domain-specific primitives»? Что бы можно было говорить о eDSL отличия должны заключаться в лексических, синтаксических или семантических правилах. Что, как я указал выше, в CL не возможно без стадии трансформации кода.

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

А что будет если сишный программист перепутал местами поля при объявлении структуры, а поля одного типа. Просто названия перепутал. Баг будет, наверное :)

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

> выражение (a :int) вообще будет выглядить (в семантике CL)

как вызов функции


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

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

Кстати, если ошибиться и написать

(destruct foo ;; f забыли
  (a 3)
  (b 4))

То получим сообщения - «foo неопределённая переменная», «a и b - неопределённые функции». Это в семантие CL, стоит поставить `f' на место и будет уже семантика, задаваемая макросом destruct, т.е. всё будет валидно.

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

В начала 2000-ых (кажется в 2002) на comp.lang.lisp был эпический срач «Как я потерял веру»

Вот это откуда пошло :) Я отсюда - reddit.com Interviews Peter Norvig - это услышал.

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

>А что будет если сишный программист

А причем тут сишные программисты?

А ведь это только грамматический уровень. А есть еще и семантический...

Вот поэтому и нужно на лиспе писать на уровне «это еще не DSL (т.к. не оперирует объектами предметной области), но уже и не API (т.к. уделяет больше внимания семантике)».

Я еще раз приведу язык 1C. Он позволяет оперировать объектами предметной области, но средства определения этих объектов в нем отсутствуют напрочь. В нем вообще непримитивные типы отсутствуют напрочь!!! Что не мешает описывать бизнес-логику очень нетривиальных ERP систем.

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

А причем тут сишные программисты?

Ну у сишных программистов бага не будет пока кто-нибудь не полезет по оффсету (аналог «лесть в список с помощью cadar»). Также и в CL - элементы макросов претендующих на роль представлять ДСЛ это всё суть списки или символы - без типового разделения семантического элементов моделируемого AST. Так что претензия к макросам CL понятна. А как вы относитесь к макросам PLT scheme?

Кстати, ваша гипотетическая проблема с foo и bar, это то же самое что перепутать местами поля в defstruct - не проблема макросов. Может быть есть какой-нибудь более реальный пример такой ошибки? Отсутствие системы типов не позволяет выловить некоторые сложные ошибки в отношениях типов в формах - это да, но к микросистеме это мало относится (в том смысле что у всех всё работает - по части маросов, хотя на сложные ошибки типизации (из-за отсутствия type cheker-а) тоже можно напороться - но это не по части макросистемы).

quasimoto ★★★★
()

13 страниц, а кто-то уже хоронил лисперов. Нет, лисп все еще главная тема для срачей.

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

>Так получается, что и ctypes в Питоне - это DSL? Ж)

А разве нет?

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

>то у нас, фактически, есть только один вариант интерфейса.

Могу по своему опыту сказать, что это не так.

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

> лучше бы Гоголя почитал

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

"...с криками Гоголя не любишь? дали ему в рыло... хорошо повесилились --- день прошёл не зря." (С)

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

> Оставим в стороне смысловую нагрузку его творчества. Гоголь это непревзойдённый эталон правильной русской речи, безупречно логически связанной и обладающей выдающейся эстетической ценностью.

это всё «устаревшая техника» рускага язЫка :(

вот вспомнилось на тему беседы :) как выразительна техника романса :)

Мой ангел, не читайте Кастанеду,
А почитайте что-нибудь еще.

Не трогайте спокойствия души,
Не трогайте прозрачность этих стекол.
Желаете - послушайте Deep Purple
Не хочется - покушайте лапши.

Не умствуйте. Возьмите. Это вам.
Вот светится вино почти без света.
Ужель еще вам хочется в беседу
Вставлять иноязычные слова?

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

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