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

Я не понимаю, почему не использовать просто компиляцию через Си или Си++. Оптимизации сделает компилятор Си. Семантика у LLVM всё равно совпадает с Си, по объёму кода компилятора тоже выигрыша практически нет. Зато если использовать Си, можно использовать любой из компиляторов Си и компилировать для платформ, для которых нет реализации LLVM.

Kris Jusiak создал проект Qlibs++ с header-only библиотеками для С++20, без сторонних зависимостей. Часть из них – облегчённые версии библиотек из boost-ext.

На данный момент есть:

• di – внедрение зависимостей;
• jmp – статический jump;
• mem – аллокаторы;
• mp – мета-программирование;
• mph – статические (минимальные) идеальные хеш-функции;
• prof – профайлинг;
• reflect – статическая рефлексия;
• sml – конечные автоматы;
• swar – SWAR;
• ut – юнит-тесты, упрощённая μt -- C++20 библиотека модульного тестирования.

Приятного чтения! :)

Дополнение от 26.11.2024: Автор создал ещё два репозитория, пока пустые:

https://github.com/qlibs/uefi – C++ UEFI library.

Привет, ЛОР!

Если кому-то нужно шкворца, пилите новость.

Подробности тут: https://downloads.haskell.org/~ghc/9.10.1/docs/users_guide/9.10.1-notes.html

Люди, это конец человечества.

Эта штука имеет НАСТОЯЩИЙ РАЗУМ на уровне среднего студента.

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

Я в реальном шоке. Тут вот на Хабре один человек написал:

===

ДлчНикакой «войны с ИИ» не может быть. Сейчас мы прошли этап искуственного идиота, и создали искуственного умника. Просто брутфорсом, больше связей и больше размеченных данных. Нейросетка все также не обучается в процессе разговора, все также не моделирует реальность. Или я упустил, и ей задавали вопросы типа «нарисуем круг желтого цвета диаметром 1, через центр круга проведем 4 отрезка желтого цвета длинной 2, середина каждого отрезка пусть совпадет с центром круга, угол пересечения отрезков пусть будет 45 градусов. Какой обьект нарисован, выдай все варианты.»

===

Прикол в том, что я задал ИИ именно этот вопрос и он легко справился. У меня нет доступа к Хабру, чтобы там ответить, но это просто жесть полная. Настала новая эпоха.

Или например, «напиши код, который рисует машину на языке Wolfram Mathematica». Написал код, который рисует микроавтобус.

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

Из того, что я мог вспомнить:

• Nim
• Zig
• Seed7
• VLang
• Crystal
• OOC

Вобщем, причесал тут свои конфиги Емакса, и выложил на гитхаб.

https://github.com/Lovesan/.emacs.d

Для работы потребуется более-менее новый Emacs, такой как 29.1

Ну и SBCL (но в init.el можно раскомментить строчку и прописать свою реализацию, типа ecl). Если еще этого не сделали, также рекомендую загрузить в SBCL quicklisp чтобы библиотеки можно было вообще в пару кликов ставить.

Как только Emacs с такой конфигурацией запускается, он открывает:

• REPL
• scratch.lisp файл (какой это файл и где он лежит, можно поменять в init.el)
• и открывает боковую панельку с tree-view директории scratch.lisp файла.

Дальше можно писать код, или нажать например в REPL запятую(,), и вводить команды SLIME-repl(для начала можно набрать help). inb4 побочные окошки, типа хелпа, закрываются кнопкой q на клавиатуре.

Вощем, включены SLIME, Magit(это интерфейс для гита в емаксе) и всякая мелочь для удобства. Тулбар выключен, менюха оставлена.

Для структурного редактирования кода на лиспе(включая Emacs Lisp), установлен пакет Lispy. Я раньше пользовался parinfer, но он меня окончательно достал. Lispy удобнее и к тому же легче конфигурируется.

SLIME там уже в принципе прилично настроенный, в частности даже есть немного подсветки синтаксиса для моей библиотеки bike

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

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

Итак, что я сделал, это я с помощью библиотеки rebinder.el, перенаправил префикс-сочетания C-x и C-c на C-e и C-d соответственно.

Это позволило сделать из емакса нормальный редактор кода. Да, в принципе, не хватало бы еще табов и прочих GUI-плюшек, но зато зацените, без всяких кривых CUA-mode, им наконец-то можно пользоваться.

Биндинги такие:

• Ctrl+Q - выход из Емакса.

• Меню/Apps (это такая кнопка рядом с правым контролом) - вызов расширенной команды по имени(типа то что в емаксе называют M-x)

Редактирование:

• Ctrl+X - вырезать
• Ctrl+C - копировать
• Ctrl+V - вставка
• Ctrl+Z - отмена
• Ctrl+Y - вернуть
• Ctrl+A - выделить весь текст

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

Управление буферами(такое обобщение понятия файла в емаксе):

• Ctrl+O - открыть файл
• Ctrl+S - сохранить буфер
• Ctrl+W - закрыть текущий буфер
• Alt+влево - предыдущий буфер
• Alt+вправо - следующий буфер
• F2 - открыть список буферов
• Ctrl+PageDown - включает оверлей ace-window, который позволяет быстро переключаться между тайлами емакса(называемыми window). Он над каждым тайлом показывает цифру, которую надо нажать чтобы на него перейти.
• F8 - показать/скрыть Neotree (это панелька с деревом файлов слева). Кстати в neotree теперь по Ctrl+клик мышью можно менять корень дерева файлов.

Поиск:

• Ctrl+F - поиск вперед по тексту
• Ctrl+Shift+F - поиск взад по тексту

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

Мышку кстати тоже в некоторой степени перебиндил, в частности доп. кнопки mouse-4 и mouse-5 (их обычно в современных ОС вешают на вперед/назад) управляют навигацией по буферам. В принципе, они позволяют выбирать следующий/предыдущий буфер, как Alt+влево/вправо, но с некоторыми нюансами, описанными ниже.

Кейбиндинги для Emacs Lisp и для SLIME:

• F12 - Перейти к определению. Также, это можно сделать, клинкув на символ мышью, при этом зажимая Control(как во всех современных IDE).
• F11 - Вернуться назад в стеке определений. Также это делается mouse-4, т.е. мышевой кнопкой «назад».
• mouse-5 - Кнопка мыши «вперед» работает как своего рода «Redo» по отношению к предыдущей команду, т.е. она опять ныряет в стек определений, если перед этим из него был выход предыдущей командой.
• F5 - Вычисляет выражение стоящее прямо перед курсором. Т.е. если есть форма (+ 1 2 3), курсор нужно ставить сразу после закрывающей скобки.
• Alt-вверх - интеллектуальный переход наверх по S-выражению, с использованием Lispy.
• Alt-вниз - интеллектуальный переход к следующему S-выражению, с использованием Lispy.

Кейбиндинги специально для SLIME:

• F1 - информация о символе. Если вызывать на пустом месте, в командной строке нужно будет ввести имя символа. Если нажать над символом, то опишут его.
• F3 - поиск по символам. Выведет список символов и краткое описание. Ищет только по тем символам, которые связаны с функциями, переменными, классами, итд.
• F4 - Скрыть/показать REPL в текущем тайловом окне.
• F6 - Скомпилировать и загрузить текущий файл

Пока что больше кастомных кейбиндингов нет, и все остальные на своих местах, но еще раз, надо помнить, что префикс-сочетание С-x перевешано на С-e, а С-c на С-d, так что меняйте это в уме, если где-то в документации по тому же Magit это видите. Но кстати с такими префиксами, работать со всем дефолтом даже удобнее, не так устают пальцы. А, еще в Lispy отрубил клавишу e, чтобы не мешалась, и еще там несколько мелочей в нем отрубил или поправил.

Ксатит вот где можно еще почитать по SLIME, Lispy и Magit:

• https://slime.common-lisp.dev/
• https://github.com/abo-abo/lispy
• https://magit.vc/

9 февраля вышел последний релиз IRC-клиента HexChat. HexChat является форком некогда популярного XChat и до недавнего времени развивался одним-единственным разработчиком. В версию 2.16.2 вошли незначительные изменения, накопившиеся за прошедшие два года.

Среди причин прекращения поддержки заявлены отсутствие активности со стороны сообщества, устаревший код, проблемы с миграцией с GTK2 на более новые версии и в целом упадочное состояние IRC как средства обмена сообщениями. Вместе с тем, разработчик заявил о надежде, что кто-то создаст форк и продолжит развитие проекта.

>>> Подробности

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

Я бы, наверное, интуитивно определил это так. Не-синтаксис — это только лишь вражения языка. Сюда не входят любые макроопределения, спецформы, statements, операторы и так далее. В таком случае синтаксиса нет в том смысле, что нет такого синтаксиса, который бы нельзя было изменить средствами самого языка. Грамматика при этом, конечно, никуда не денется.

Опять же, тут есть тонкая грань. Если каждому оператору соответствует какое-либо выражение языка, то все еще можно считать, что в языке все есть выражение. В таком случае, это можно считать легкой косметикой. Например, оператору := в Io соответствует выражение setSlot. Спецформе define в Scheme не соответствует никакое выражение. Соответственно, на Io можно писать используя одни только выражения, на scheme — нет.

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

Наверное, tcl сюда входит, picolisp, возможно смоллток(поправьте, если я ошибаюсь). А еще есть?

UPD точней будет, наверное, не «без синтаксиса», а «независим от синтаксиса»

Всем привет,

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

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

Материалы | Записи занятий

Предупрежу, что в схемах и лиспах я нуб. Решил ради интереса порешать задачки на ракете. Задача заключается в том, чтобы перебрать строку и посчитать очки за каждую букву, разные буквы стоят разное количество очков. Накидал вот такое решение:

#lang racket

(define (score word)
  (for/sum ([i (string->list word)])
    (case i
      [('A 'E 'I 'O 'U 'L 'N 'R 'S 'T) 1]
      [('D 'G) 2]
      [('B 'C 'M 'P) 3]
      [('F 'H 'V 'W 'Y) 4]
      [('K) 5]
      [('J 'X) 8]
      [('Q 'Z) 10])))

Но столкнулся с тем, что case возращает #<void>, Переписал на cond, но он тоже возвращает #<void>. Неужели без дополнительной переменной sum не обойтись?

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

Во-первых, сценарий. У меня есть пару идей, но мне кажется эти идеи надо подкрепить профессиональной литературой, для лучшего эффекта. Посоветуйте легкую книгу в этом направлении.

Во-вторых, картинка. В плане пискельности, пропорций должно выглядеть как Dead cells, так же вид сбоку, но проходить должно в антураже условной хрущевки. И так как рисовать я не умею и друзей художников у меня нет, придется какую то часть ассетов накалякать самому, для другой части искать бесплатные ассеты. Порекомендуйте сайтик где есть большой выбор.

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

В-четвертых, геймплей, жанр и механики. Пока это мое слабое место, я еще не придумал как в мир без магии, фентези и прочего добавить каких-то геймплейных механик. Днем герой мог бы ходить по общежитию, взаимодействовать с объектами и изучать их, выполнять задания, но потом я задумался:«А как еще можно разнообразить геймплей». Вспомнил, что была такая игра Catherine. Подумал, что тоже можно добавить некую мини-игру, которая бы происходила в конце игрового дня и влияла на героя в его реальности. Но, мне кажется что, эта мини-игра должна быть драйвовая, динамичная, чтобы щекотать игроку нервы, чтобы он понимал, что если он тут провалится, то это повлияет на персонажа.

В-пятых, яп. У меня есть пара требований к языку:

• Без GC, чтобы картинка не лагала. Хотя, у меня есть ощущение, что у меня картинка будет не сильно сложная.
• Удобная поддержка юникода и в Linux и в Windows. Все таки сценарий будет написан на русском.

И что у нас остается:

• С. SDL2. (скорее всего придется крутить велосипед для юникода(?))

• C++. SDL2, SFML.

• Rust. биндинги к sdl2, sfml или же чисто растовсикй piston.

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

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

Предистория такова, мы обрабатываем изображения с телескопов, там счёт идёт на сотни мегапикселей, и глубина пикселя 32 бита. Так что типичное изображение ~ два с половиной гигабайта, для этих целей специально собраны счётные узлы с 4 Гб RAM. Это чтобы изображение поместилось целиком в память, и оставалось на промежуточные буферы для накопления результатов. Естественно, все рассчёты написаны на Си и С++, работает быстро, памети хватает. Но код некрасивый, много повторяющихся конструкций и т.п. Народ в основном закостенелый из старшего поколения, ничего кроме Си и фортрана не знают, а я хочу попробывать более современные языки.

Так что буду благодарен за примеры чтения массивов для Haskell и особенно Scheme. И чтобы можно было посмотреть, сколько памяти реально израсходовано. Спасибо!

Вышла в свет платформа Ceramic — инструментарий для создания кроссплатформенных приложений с помощью веб-технологий.

Ceramic написан поверх Electron, аналогично текстовому редактору Atom от Github. Примечательным моментом является использование Common Lisp в качестве языка разработки. По словам авторов, Lisp обспечивает быстрый старт и высокую скорость разработки в сочетании с высокой производительностью и зарекомендовавшей себя промышленной надежностью.

>>> Подробности

Я тут упоролся и подумал, а что если бы у нас был ЯП уровня Си с гомоиконным синтаксисом в стиле Io или Julia. То есть — у нас есть интерпретатор гомоиконного языка, который работает как макропроцессор, и результат трансформаций исходного кода скармливается затем компилятору языка с Си-подобной семантикой. И у нас будет нормальный тьюринг-полный макроязык, который позволит бескостыльно расширять возможности ЯП неограниченно. Компилирующаяя же часть будет по сути обычным компилятором Си (просто читающим входные данные в неСишном синтаксисе).

Это ж кайф. Выражения типа regexp(«^[a-z][a-z0-9]») или format(«%s - %s (%d)», bla1, bla2, i) можно будет автоматически обрабатывать макропроцессором и отправлять компилятору оптимизированный вариант. Это значит, регулярка, например, будет скопилирована в конечный автомат при компиляции программы, а не при выполнении.

Вот эта вот странная задачка, на которой dr_jumba проверял лаконичность языков, записывалась бы как-то вот так:

sample_function := fn(a(iterable(T))) to(T) {
    a select(match(regexp(/^J[a-z]+/))) each_chunk(3) map(format_with("~1 and ~2 follow ~3")) join("\n")
}

Дискас.

Привет. У меня есть файл. Он имеет такой вид и подключается из asd-файла:

#+cool-feature
(toplevel-form)

#+cool-feature
(another-toplevel-form)

#+cool-feature
(declaim ...)

#+cool-feature
(declaim ...)

#+cool-feature
(yet-another-toplevel-form)

Фича :cool-feature добавляется в процессе компиляции до компиляции этого файла. А вот вопрос: как бы мне написать «#+cool-feature» всего лишь один раз в начале файла и охватить все эти формы разом? Т.е. что-то вроде

#+cool-feature
(block nil
  (form-1)
  (form-2)
  (declaration-1)
  ...)

Кстати, если фича не добавляется, можно вообще не компилять файл. Важное замечание: объявления должны быть в силе в compile-time.

Да, зачем мне это надо? У меня в одном файле список фич, с которыми прожект будет собран, но которые необязательны для работы и которые её тормозят (например, всякие проверки)

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

Однако в индустрии данный подход применяется нечасто.

К примеру в С используется отдельный язык, генерирующий текст (препроцессор).

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

В Scheme тоже изобрели отдельный язык.

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

Если говорить про не-лисповые языки, то естественным кажется ввести официальный API для AST (по сути там ерунда) и разрешить писать функции, возвращающие этот самый AST. Это будет всё же лучше, чем текст и концептуально более похоже на лисп. Но я такого не видел. Разве что в Java есть annotation processor-ы, но и там такой подход это на уровне хаков скорей.

Можно сказать, что достаточно популярен подход, при котором генерируется исходный код перед компиляцией, к примеру из openapi спецификации. Это близко к постановке задачи, но всё же не совсем то.

Мне кажется идея генерировать код тем же языком, которым он пишется, на 100% естественной и удачной. Единственное, что я бы тут дополнил - сохранять весь этот сгенерированный код в хорошо отформатированном виде где-то в каталоге с остальными артефактами сборки и предоставлять простую навигацию, чтобы не нужно было гадать, что же там эти макросы нагенерировали. Но это уже мелочи и вопрос инструментария, а не что-то фундаментальное.

Почему же так не делают? Зачем почти в каждом языке изобретают какие-то особые пути для метапрограммирования?

В теме "Питонячьи радости " на последних страницах между мной и rtxtxtrx внезапно разгорелся спор, из которого я понял, что есть еще люди, которые не считают динамическую типизацию (в том виде, в котором она представлена в Питоне, а именно строгая динамическая типизация) серьезным недостатком при работе с большим объемом кода, особенно при рефакторинге. Вообще изначально разговор завязался вокруг назначения type hints введенных в Питон 3: я утверждал, что они нужны для создания семантических связей в коде, которые будут препятствовать внесению деструктивных изменений в код в результате опечатки или иной ошибки кодера (изменил код, в результате которого какое-либо выражение получило некорректное значение, которое тем не менее обладает схожим с корректным значением типовым контрактом, поэтому при запуске код не «упадет» сразу, указав на проблему); оппонент заявил, что они нужны для (само)документации и не более того.
Но потом выяснилось, что и царь-то ненастоящий (читай, статическая типизация). Не нужна она, просто именуй сущности понятно и уповай на строгую типизацию. А если типизация не строгая, то сами виноваты, у нас в Питоне всё ОК.
Поскольку тема большая и вкусная, я предлагаю всем обсудить этот очень важный вопрос в меру скромных сил и познаний каждого желающего. Обсуждение вторичных вопросов, как-то «статическая типизация нужна для генерации эффективного кода», «при динамической типизации тип только один, object» etc. не предусмотрено — спорим только о том, дает ли статическая типизация выигрыш, если надо перекраивать несметные тыщи kloc. Если есть вообще о чем спорить 😅.

(defn castSatan [x]
  (defmacro killGod []
    x)
  (killGod)
)
(castSatan 666)

Подскажите ошибку в коде.

Сабж. Есть идеи, хочу их попробовать. Если ли, скажем, какие-то тулкиты для эээ автоматизации этого? Ну, например, набор примитивов (структуры, списки, массивы ...), плюс какие-нить парсеры итд итп. Я не про yacc/bison+llvm, а про что-нить более высокоуровневое и лузер-френдли.

Существует 3 листа

A (1 2 3 4 5)
B (6 7 8 9 10)
C (11 -12 13 -14 -15)

D (1 7 3 9 10)

перекрутил в голове nth, elt, do. Подкиньте идею с кодом.