Вышел GtkD 1.0

> на Паскале не написано ничего хорошего.

4.2, редкостное. Например, TeX и Metafont - это, по твоему, "ничего хорошего"?

TeX сколько уже десятков лет? Сейчас LaTeX используют.

Человек, ты дурак? Тебя мама головой об стенку била?

LaTeX, детка, написан на TeXе. Полностью.

> 4.2, редкостное. Например, TeX и Metafont - это, по твоему, "ничего хорошего"?

Тех написан на мета-языке, похождем на паскаль, который транслируется в Си: ;)

The original source code for the current TeX software is written in WEB, a mixture of documentation written in TeX and a Pascal subset in order to ensure portability. For example, TeX does all of its dynamic allocation itself from fixed-size arrays and uses only fixed-point arithmetic for its internal calculations. As a result, TeX has been ported to almost all operating systems, usually by using the web2c program to convert the source code into C instead of directly compiling the Pascal code.

Тут хорошо видно, какое же стандартный паскаль говно. Бедный Кнут написал собственный аллокатор, видимо. Мог бы съэкономить себе массу времени, выбрав сразу Си -- но видимо помешало отсутвие аутотулз на тот момент.

Возможно просто потому, что хоть C и близок по быстродействию к асму, но писать большие проги на нем кошмарно. Чего только стоит один gtk, ООП там и не пахнет :D ИМХО потому TeX и написан на мета-языке, чтобы по не пришлось писать все-все-все ручками и макросы видать не спасли бы.

На паскале не пишу:) Давно уже.

Для более точного вывода следует посмотреть на сурсы ТеХа ;) мета в данном случае я неудачно применил, имелось в виду "напрямую не кормпилируется", а не его высокоуровневость.

> Тех написан на мета-языке, похождем на паскаль, который транслируется в Си: ;)

Нет. TeX написан на WEB, то есть, на Паскале с литературными комментариями, и компилируется любым приличным компилятором Паскаля. То, что его собирают традиционно через p2c и аналогичные конвертеры - ещё ничего не значит.

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

На тот момент Си был доступен на ещё меньшем количестве платформ, чем Паскаль.

Кроме того, статический memory management - это весьма правильный подход, и сознательный отказ от динамических аллокаторов для проекта вроде ТеХа имеет смысл.

Ну да, напрямую компилируется оно после удаления комментариев. Очень "мета", ага.

Лучше бы вообще автотулз не было.

оффтоп: кто-нить eiffel пробовал? паскале подобный синтаксис.

erlang, smalltalk, ada?

и scala?

> Касательно сред разработки. ИМХО лучше выбрать либо vim либо descent for eclipse. Ни тот ни другой упомянуты не были. И опять же не упомянут Hybrid в разделе GUI.

Делалось в первую очередь для себя, а так как ни vim ни eclipse не использую, и использовать не собираюсь... то увы :)

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

> Лучше бы вообще автотулз не было.

Ага, лучше править makefile ручками под каждую платформу/используемые блиблиотеки/и т.д.

> Нет. TeX написан на WEB, то есть, на Паскале с литературными комментариями, и компилируется любым приличным компилятором Паскаля.

WEB -- это прежде всего подмножество стандартного паскаля, взято было из-за переносимости, как я понимаю.

> На тот момент Си был доступен на ещё меньшем количестве платформ, чем Паскаль.

А, и то верно, прежде всего не было еще и gcc.

> WEB -- это прежде всего подмножество стандартного паскаля, взято было из-за переносимости, как я понимаю.

Нет, WEB - это две тулзы, tangle и weave. Одна генерит теховую документацию, с подсветкой синтаксиса для Паскаля (и это единственный момент, где WEB вообще как-то с Паскалем контачит), другая генерит очищенный от комментариев исходник (с некоторыми макроподстановками). А выбор подмножества Паскаля - это уже личная самодисциплина Кнута. На WEB можно писать, используя хоть даже и Дельфи, если очень захочется.

> На WEB можно писать, используя хоть даже и Дельфи, если очень захочется.

Ага, только web2c это не осилит, и не ясно что с Техом делать

Ну и на кой тебе обязательно именно web2c? После tangle можно любым компилятором Паскаля воспользоваться.

>>В языке D правильно адресованы проблемы плюсов, но решены они не правильно.

> Почему? Спрашиваю не из любопытства.

А из чего?

Д-шные решения в основном вида "библиотеки не могут это (например слайсы) сделать правильно, поэтому поместим это (слайсы) в компилятор". Тогда (ИМХО) правильное решение -- расширить язык до такой степени, чтобы это (те же слайсы) могли делать не разработчики компилятора, а разработчики библиотек.

Почему так? Рассмотрим сравнение POD-структур (если оно вдруг сделано библиотекой -- поправьте меня). Вдруг мне захочется сделать что-то *похожее* но не совсем такое? Если оно библиотекой, то я могу. Если же вделано в кишки компилятора -- то я бессилен... это недемократичность языка.

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

Ну и наконец -- все эти бантики, вплоть до GC, надо делать, не теряя совместимость с плюсами.

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

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

Интероперабельность с плюсами довольно прикольна -- на сайте D пишут, что она теряется, как только C++ класс оказывается в своем namespace-е -- но ведь это обычная практика :-)

>> У D есть быстрые и качественные программисты, на любой случай.

> Что-то не нашлось быстрых и качественных, чтоб сам D допилить, быстро и качественно.

В этом НЕ программеры виноваты, а архитектура. Если бы все вкусности Д были вынесены из компилятора в либы, то доплили бы намного быстрее и добавили еще вкусностей.

Тебе не надоело ещё козырять тут своей безграмотностью и C++-ной закомплексованностью?

> Тебе не надоело ещё козырять тут своей безграмотностью и C++-ной закомплексованностью?

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

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

> Вдруг мне захочется сделать что-то *похожее* но не совсем такое? Если оно библиотекой, то я могу. Если же вделано в кишки компилятора -- то я бессилен... это недемократичность языка.

если только компилятор не экспортирует AST и API для его обработки. Фронтенд D есть в исходниках, как должен генерироваться AST однозначно понятно. Так что не вижу проблем.

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

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

> Ну и наконец -- все эти бантики, вплоть до GC, надо делать, не теряя совместимость с плюсами.

Не понял. В С++ GC "из коробки" нет, но можно реализовать любой перекрытием аллокаторов класса. В D есть "канонический" GC "из коробки", но тоже можно реализовать любой, хоть в массивах, как в TeX, или вообще отключить. В чём должна проявляться совместимость GC в C++, которого там нет с GC в D, который там есть?

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

а чем текущий результат не устраивает?

> Но решение должно быть не Д-шное "запихать его в кишки компайлеру", а "расширить язык до такой степени, чтобы можно было самому создавать литералы произвольного класса, в т.ч. и String"

mixinы, template, static if?

> если только компилятор не экспортирует AST и API для его обработки. Фронтенд D есть в исходниках, как должен генерироваться AST однозначно понятно. Так что не вижу проблем.

Я что-то пропустил? Где Д-шное АПИ для обработки АСТ?

> можно развернуть тему? поподробнее, с примером.

У меня есть пример dup/idup, но я его не тестил на компиляторе D. Вообще тут я могу быть не прав. Лучше задам-ка я это в виде вопроса.

> Не понял. В С++ GC "из коробки" нет, но можно реализовать любой перекрытием аллокаторов класса. В D есть "канонический" GC "из коробки", но тоже можно реализовать любой, хоть в массивах, как в TeX, или вообще отключить.

> В чём должна проявляться совместимость GC в C++, которого там нет с GC в D, который там есть?

Ммм... может я не совсем прав, указав здесь именно GC... но несовместимость бинарной раскладки классов Д и классов С++ возникает из-за монитора и таблици виртуальных функций, которые оба нам могут быть не нужны -- т.е. нарушается плюсовый принцип "платить только за то, что покупаем". (Обязательно ли для compacting GC имет монитор? мне показалось что да...)

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

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

> а чем текущий результат не устраивает?

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

А. Регулярные выражения, чтобы:

1. Были возможны regex-литералы, символ-ограничитель выбери по вкусу, (но не стринговый, иначе это будет стринговый литерал). Например `[+-]?\d+` и чтобы слэши внутри не требовалось удваивать.

2. Чтобы эти выражения компилились во время компиляции.

Б. Защиту стэка от срыва. Чтобы я мог у каждой функции поставить атрибут smash_safe и тогда

1. при входе адрес возврата клался в отдельный стэк 2. при выходе адрес возврата сравнивался с сохраненным адресом возврата, и в случае разных адресов генерился exception с выходом по правильному адресу

>> Но решение должно быть не Д-шное "запихать его в кишки компайлеру", а "расширить язык до такой степени, чтобы можно было самому создавать литералы произвольного класса, в т.ч. и String"

> mixinы, template, static if?

Ничего из этого не поможет создать свой литерал.

(хотя сами по себе эти фичи шаг вперед от с++)

> Регулярные выражения, чтобы:

> 1. Были возможны regex-литералы, символ-ограничитель выбери по вкусу, (но не стринговый, иначе это будет стринговый литерал). Например `[+-]?\d+` и чтобы слэши внутри не требовалось удваивать.

Именно так и выглядят WYSIWIG строки.

> 2. Чтобы эти выражения компилились во время компиляции.

Реализовано в библиотеке.

import std.stdio;
import regex;

void main()
{
auto exp = &regexMatch!(`[a-z]*\s*\w*`);
writefln("matches: %s", exp("hello world"));
}

regexMatch - шаблон.
Брать здесь: http://www.dsource.org/projects/ddl/browser/trunk/meta/regex.d Правда написали её ещё до DMD 1.000. Сейчас эта штука реализуется намного проще с CTFE. Может кто-то сделал. Лень искать.

> Я что-то пропустил? Где Д-шное АПИ для обработки АСТ?

мда, это я уже немного отсебятину несу. Из коробки пока нет если не считать парсеры EBNF и т.п.
D-шного API для AST нет в составе самого D, но есть
1) в официальной поставке DMD фронтенд в dmd/src/dmd и спецификация языка. Описание в pdf spec_DMD_N.pdf и http://www.digitalmars.com/d/2.0/lex.html , http://www.digitalmars.com/d/2.0/statement.html http://www.digitalmars.com/d/2.0/declaration.html http://www.digitalmars.com/d/2.0/expression.html
2) проекты gdc, llvmdc, dmdfe, DParser, dil, dang -- другие фронтенды (см. также Tioport, molt, nanu и TDC, SableDD)
3) DStress -- юнит тесты к gdc, llvmdc, dmd на соответствие спецификации языка

4) "АPI для обработки AST" есть собственно в LLVM, в который может экспортировать фронтенд llvmdc

парсеры разные на D есть, lex/LL-LALR или EBNF, например Enki (подпроект ddl), который из EBNF в итоге генерирует исходник на D .
Другой интересный проект в ddl meta

> но несовместимость бинарной раскладки классов Д и классов С++ возникает из-за монитора и таблици виртуальных функций, которые оба нам могут быть не нужны

плюс, насколько я понимаю, в D и С++ разный mangling (см. std.demangle в Phobos или D demangle (был какой-то отдельный проект) на тему патчей к gdb)

>GC это один из бантиков, и из-за него нельзя терять совместимость с плюсами

В D GC довольно гибко настраивается (cм.
http://digitalmars.com/d/2.0/phobos/std_gc.html
http://www.dsource.org/projects/tango/wiki/TopicAdvancedConfiguration
http://www.dsource.org/projects/tango/wiki/LibraryIntegrationGuide
http://digitalmars.com/d/2.0/memory.html#newdelete
http://digitalmars.com/d/2.0/garbage.html )

Можно заменить в исходниках Phobos/Tango реализацию GC на заглушки. В коде на D GC используется только в нескольких случаях, если писать на подмножестве D, то GC не вызовется. Получить в итоге D без GC.

>для compacting GC ЕМНИП в плюсах нет достаточной поддержки компилятора

поддержки компилятора нет, а GC в плюсах есть. Также, как и в голом Си -- отдельной реализацией. Скорее речь о стандартном API GC. Стандартный API gc в D есть.

>А. Регулярные выражения, чтобы:
>2. Чтобы эти выражения компилились во время компиляции.

http://dsource.org/projects/scregexp

"The regular expressions are parsed at compile time. "
Исходники есть, можешь переделать по вкусу.

Ещё есть библиотеки: Meta, рейтрейсер на шаблонах во время компиляции, парсер и компилятор EBNF и самого D на шаблонах D, времени компиляции.

> Б. Защиту стэка от срыва. Чтобы я мог у каждой функции поставить атрибут smash_safe и тогда

можно посмотреть в сторону библиотек метапрограммирования, Enki и контрактного программирования в D (не стандартные средства, а отдельным проектом)

Какое-то метапрограммирование кроме Enki и т.п. наворотов на шаблонах можно сделать в 2 подхода: через llvmdc получить AST программы на D, чем-то вроде http://felix-lang.org/ для LLVM полученный AST обработать

>>"расширить язык до такой степени, чтобы можно было самому создавать литералы произвольного класса, в т.ч. и String"
> mixinы, template, static if?

Ничего из этого не поможет создать свой литерал.

я кагбе намекаю на след. схему:
1. компилятор расширенного языка чем-то вроде weave из literate programming (хотя хватит и grep на Template!(..) :) выдирает выражения, транслирует их в AST
2. кодогенератор из этих AST генерирует код на D, который буквально подставляется шаблонами, или байткод LLVM, с которым линкуется скомпилированный llvmdc исходник на D
3. в момент компиляции шаблоны D подставляют реализацию на D ( в чём сложности выполнить замену по таблице символов символ-код, если символы уже заранее сгенерированы?) или просто код на D компилируется через LLVM , AST тоже компилируется LLVM, всё линкуется вместе.

Через Enki или Meta можно написать парсер/компилятор, делать 2 и 3 и простыми шаблонами на D,

http://www.prowiki.org/wiki4d/wiki.cgi?GrammarParsers

http://www.dsource.org/projects/molt/browser/trunk/java-xml-to-d.xslt

O_o

http://codu.org/nestedvm-gdc/

>Я что-то пропустил? Где Д-шное АПИ для обработки АСТ?
:>D-шного API для AST нет в составе самого D

а может быть, и есть:
http://languagemachine.sourceforge.net/d_to_d_translator.html
http://languagemachine.sourceforge.net/d2xfe.html
http://languagemachine.sourceforge.net/documentation.html

> auto exp = &regexMatch!(`[a-z]*\s*\w*`);

да Я ЗНАЮ что шаблоны в Д могут ковырять строки и во время компиляции скомпилировать регекс, но я говорил о regex-ЛИТЕРАЛЕ (посмотри, что такое литерал)

Почему разрабы компилятора и языка за меня решают, где литералы нужны (строки), а где -- якобы не нужны (regex-ы)??? Почему я не могу за них перерешить?

Уж если делаете литералы, так дайте их всем, а не только Элите Имеющей Возможность Менять Стандарт Языка Д.

Я хочу вот так:

auto regex = `[a-z]*\s*\w*`; /// а лишних синтаксисов для строк мне не нужно

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

> Почему разрабы компилятора и языка за меня решают, где литералы нужны (строки), а где -- якобы не нужны (regex-ы)??? Почему я не могу за них перерешить?

есть библиотека http://dsource.org/projects/scregexp http://dsource.org/projects/scregexp/browser/trunk/scregexp.d
там реализуется компилятор регулярного выражения: разбор грамматики, атомов (литералов), реализация (емнип, не через конечные автоматы; но можно и конечные автоматы сгенерировать каким-нибудь Ragel)

Всё это во время компиляции: search!(regex) разберёт regex и подставит через mixin соответствующий ему код.
Не нравится тебе "лишние" литералы в регекспах кроме \s \w -- исправь парсер. Не нужен GC -- отключи либо используй подмножество языка, которое гарантированно не дёргает GC, и линкуй с заглушкой.

Аналогично работают и другие парсеры и компиляторы компиляторов вроде Enki, SableCC, Ragel, languagemachine и т.п.

> я кагбе намекаю на след. схему: компилятор расширенного языка...

Я примерно такие схемы и обдумываю, только другим языком, не поверх Д, а поверх плюсов или даже С. Да и остальные фичи Д таким же образом можно (и нужно) заюзать поверх плюсов, но не юзать Золотую Клетку.

Вообще, кого Золотая Клетка устраивает, я разубеждать не буду -- я примерно объяснил свой подход, если он непонятен/неприемлем -- это меня (пока что) не волнует.

> Всё это во время компиляции: search!(regex) разберёт regex и подставит через mixin соответствующий ему код.

я УЖЕ писал, что я это знаю.

меня интересует только литерал типа строчного, т.е. одно из:

auto regex = `[a-z]*\s*\w*` auto regex = /[a-z]*\s*\w*/ auto regex = @[a-z]*\s*\w*@ auto regex = #[a-z]*\s*\w*#

Такое можно сделать в Д?

> Всё это во время компиляции: search!(regex) разберёт regex и подставит через mixin соответствующий ему код.

я УЖЕ писал, что я это знаю.

меня интересует только литерал типа строчного, т.е. одно из:

auto regex = `[a-z]*\s*\w*`
auto regex = /[a-z]*\s*\w*/
auto regex = @[a-z]*\s*\w*@
auto regex = #[a-z]*\s*\w*#

Такое можно сделать в Д?

> Да и остальные фичи Д таким же образом можно (и нужно) заюзать поверх плюсов, но не юзать Золотую Клетку.

такой проект тоже есть. Компилятор D в D через C : http://dsource.org/projects/tdc/wiki/ExampleConversions

хотя в упор не вижу в чем вот здесь "Золотая Клетка"
http://languagemachine.sourceforge.net/j2d.html

что ты хочешь получить в итоге?
1.Свой синтаксис для идентификаторов D?
2.Свой синтаксис для регулярных выражений?

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

Или трансформировать код в аналогичный на D/Си
http://languagemachine.sourceforge.net/d2xfe.html
http://languagemachine.sourceforge.net/j2d.html
http://dsource.org/projects/tdc/wiki/ExampleConversions

2. Посмотри в том примере scregexp.d юнит-тесты, как разворачивается шаблон. Конкретно, toLiteralString() и parseRegexp()

Похоже, многие не поняли, что меня интересует не только возможность скомпилировать regex во время копиляции, но именно

Л-И-Т-Е-Р-А-Л регулярного выражения, в который НЕ входил бы литерал строки.

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

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

> что ты хочешь получить в итоге? > 1.Свой синтаксис для идентификаторов D? > 2.Свой синтаксис для регулярных выражений?

Свои Л-И-Т-Е-Р-А-Л-Ы.

Например, я хочу кватренионы -- auto x=1+2i+3j+5.5k;

Почему за меня решили, что комплексные числа достойны литерала, а кватернионы -- нет?

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

Чем?

*кватернионы

>Такое можно сделать в Д?

Это интересный вопрос. Я предлагаю вам задать его Уолтеру Брайту напрямую через ньюсгрупсы вот тут (можно прямо через веб-интерфейс), http://www.digitalmars.com/NewsGroup.html полагаю, он *компетентно* пояснит вам причины тех или иных решений и ограничений, допускающихся при разработке языка в настоящий момент.

>Например, я хочу кватерионы -- auto x=1+2i+3j+5.5k;

Писать вида Quaterion x = new Quaterion(1,2,3,5.5) или
auto x=Quaterion!("1+2i+3j+5.5k");
принципиально не хотим? хотим расширяемый синтаксис языка?

берём например D-to-D frontend из languagemachine, пишем ЕБНФ для нового выражения (с однозначной семантикой, чтобы оно не конфликтовало со старыми; например как для комплексных, чисто действительное число = не комплексное), преобразуем этим фронтендом к нужному синтаксису, выдаём бекендом D код, компилируем.
Ну компилировать программу на таком QuaterionD придётся фронтэндом, а не стандартным компилятором, и в два прохода вместо одного с Quaterion!(..), но красота требует жертв :))

да хоть октанионы с седенионами :)

> auto x=Quaterion!("1+2i+3j+5.5k"); принципиально не хотим? хотим расширяемый синтаксис языка?

Принципиально не хочу быть 2-го сорта.

Почему auto y=1+2i;
но auto x=Quaterion!("1+2i+3j+5.5k");