Имбирная Ведьмочка
> но можно сделать и наоборот — писануть hiding и список после него
Не очень хорошо. Не должно быть возможности экспортировать то, что спрятано. Но (возможно) имеет смысл экспортировать только часть публичных имён.
> сначала идёт раздел interface, и все объявления в нём экспортируются, а затем —
> implementation, и там всё локально в модуле.
Ну это по сути как разделение на hpp/cpp, только лучше.
Panzerschrek[CN]
> Не очень хорошо. Не должно быть возможности экспортировать то, что спрятано.
Не понял проблему. Если это объявление самого модуля — то ты сам этим хайдингом и решаешь, что спрятано, а что — нет. Если это импорт из другого модуля — хайдинг вычитает из списка экспорта этого модуля, ты не можешь "расхайдить" что-то, о чём компилятор даже не знает (списки экспорта сохраняются в отдельных билд-артефактах).
Panzerschrek[CN]
> О, оказывается в llvm есть какая-то поддержка корутин.
Да, что-то там есть. Но главного для меня не нашёл - как сделать так, чтобы состояние в какую-то структуру складывалось. Для меня по сути сейчас это главная трудность, ибо чтобы создавать объекты состояния корутин, надо по сути все аллокации и всякие временные значения в эту структуру сохранять, а это требует существенной доработки всех мест компилятора.
По идее помог бы какой-нибудь готовый проход, который бы автоматически выяснял, в том числе основываясь на lifetime подсказках, что и как надо между resume сохранять и автоматически бы это делал.
Добавил в компилятор опции internalize и internalize-preserve. Суть следующая - когда эта опция указана, все функции будут сделаны internal, кроме перечисленных в опции internalize-preserve. Нужно это в случае, когда собирается результирующий исполняемый файл или результирующая библиотека. Тогда можно указать только те символы (входные точки), которые напрямую и используются. Остальные публичные символы можно выкинуть совсем или встроить, что оптимизатор компилятора и может сделать. По сути это примерно то, что происходит при LTO в крестах.
На примере кода Компилятора1 valgind показывает небольшой, но прирост производительности от этого. Но в других случаях профит может быть большим. В особых случаях почти вся программа может быть соптимизирована в одну функцию - почти все вызовы будут встроены.
Подумываю внедрить в язык регулярные выражения.
Я почти два года назад написал библиотеку (статья), которая компилирует регулярные выражения в llvm код. Логично было бы её заиспользовать.
Вижу я это следующим образом: в язык добавляется оператор, с именем вроде regex_match и двумя аргументами - строкой регулярного выражения и строкой, в которой осуществляется поиск. Важный момент - строка с регулярным выражением должна быть константной, чтобы её можно было скомпилировать во время компиляции самой программы. Выражение это возвращало бы пару индексов символов первого найденного элемента. Дополнительно можно реализовать какой-нибудь regex_match_groups, чтобы можно было подгруппы выражения вытаскивать.
Поиска, думаю, вполне достаточно. Поиск с заменой можно будет поверх просто поиска реализовать уже силами программиста, ибо замена уже требует аллокаций памяти а это не очень хорошо доверять компилятору.
Ложка дёгтя - таким образом будут работать только заранее известные регулярные выражения. Для заранее неизвестных регулярных выражений придётся использовать отдельную библиотеку.
Что скажете, как вам такая идея? И вообще, есть ли языки (в том числе компилируемые), в которых регулярные в сам язык встроены?
Panzerschrek[CN]
> И вообще, есть ли языки (в том числе компилируемые), в которых регулярные в сам
> язык встроены?
пых, перл
1 frag / 2 deaths
> пых, перл
Ну то скриптушня. Хотя, регулярки может и компилируются.
PCRE, например, умеет в их компиляцию, так что даже иногда мою библиотеку уделывает.
На уровне стандартных библиотек есть много где. Петон, рубе, жаба, ну и всё такое. А больше, чем это, и не надо. Тем более в конпелируемом языке. Конпелируемый язык - не того уровня и назначения язык, чтоб впечатлять публику поносной быстротой регекспов.
Sbtrn. Devil
> не того уровня и назначения язык, чтоб впечатлять публику поносной быстротой регекспов
Наоборот же. В скриптушне компилировать регулярки не имеет особого смысла, ибо скиптушня и так тормозит. А в компилируемых языках компиляция в том числе регулярок - сам бог велел.
На мой взгляд, это не регулярные выражения должны быть встроены в язык, это средства метапрограммирования языка должны быть достаточно мощными, чтобы на них можно было реализовать, в том числе, компайлтайм регулярные выражения. Дальше регулярные выражения, что статические, что динамические, встраиваются на уровне стандартной библиотеки.
}:+()___ [Smile]
> это средства метапрограммирования языка должны быть достаточно мощными, чтобы на них можно было реализовать, в том числе, компайлтайм регулярные выражения
Ну да, на шаблоноте любую дичь можно реализовать. И есть даже для крестов одна такая библиотека. Но зачем так извращаться, если можно сделать нормальную поддержку со стороны компилятора?
Panzerschrek[CN]
> Ну да, на шаблоноте любую дичь можно реализовать. И есть даже для крестов одна
> такая библиотека. Но зачем так извращаться, если можно сделать нормальную
> поддержку со стороны компилятора?
Грубо говоря, чтобы не получился Гудлиферовский Васик — язык, который решает только одну задачу, и совершенно бесполезен для всего остального.
Имбирная Ведьмочка
> язык, который решает только одну задачу, и совершенно бесполезен для всего остального
Таковым язык может получиться, если у него весьма ограничены конструкции общего назначения, но есть при этом весьма специфические конструкции. Это как если бы у меня в языке шаблонов не было, а регулярки были.
В D были compile-time регексы на меcтных шаблонах
Panzerschrek[CN]
> А в компилируемых языках компиляция в том числе регулярок - сам бог велел.
В задачах, решаемых компилируемыми языками, регекспы нужны раз через 10 на 11-й. Попросту нет смысла заморачиваться. Хотя, если чисто ради искусства...
Тема в архиве.