Было где-то в районе

Время вызова FFI функций из различных ЯП

и

Вышел GNU Guile 2.0.7 (комментарий)

Может мне нужно было поиск описывать в виде S-выражения?

Ты почти угадал. Подробно описано http://lisper.ru/articles/quicklisp

А если вкратце, то поиск надо делать не на сайте, а из установленного Quicklisp (так же как и скачивание и установку)

CL-USER> (quicklisp:system-apropos "trie")
#<SYSTEM btrie / btrie-20120909-git / quicklisp 2013-11-11>
#<SYSTEM btrie-tests / btrie-20120909-git / quicklisp 2013-11-11>
#<SYSTEM darts.lib.hashtrie / dartsclhashtree-20131003-git / quicklisp 2013-11-11>
CL-USER> (quicklisp:system-apropos "hashmap")
; No value
CL-USER> (quicklisp:system-apropos "hash")
#<SYSTEM city-hash / city-hash-20131003-git / quicklisp 2013-11-11>
#<SYSTEM city-hash-test / city-hash-20131003-git / quicklisp 2013-11-11>
#<SYSTEM cl-custom-hash-table / cl-custom-hash-table-20110219-git / quicklisp 2013-11-11>
#<SYSTEM cl-murmurhash / cl-murmurhash-20130720-git / quicklisp 2013-11-11>
#<SYSTEM darts.lib.hashtree / dartsclhashtree-20131003-git / quicklisp 2013-11-11>
#<SYSTEM darts.lib.hashtree-test / dartsclhashtree-20131003-git / quicklisp 2013-11-11>
#<SYSTEM darts.lib.hashtrie / dartsclhashtree-20131003-git / quicklisp 2013-11-11>
#<SYSTEM darts.lib.ptree / dartsclhashtree-20131003-git / quicklisp 2013-11-11>
#<SYSTEM darts.lib.wbtree / dartsclhashtree-20131003-git / quicklisp 2013-11-11>
#<SYSTEM make-hash / make-hash-20130615-git / quicklisp 2013-11-11>
#<SYSTEM make-hash-tests / make-hash-20130615-git / quicklisp 2013-11-11>
#<SYSTEM sip-hash / sip-hash-20131003-git / quicklisp 2013-11-11>
#<SYSTEM sip-hash-test / sip-hash-20131003-git / quicklisp 2013-11-11>

Дело в том, что в Racket число типов несчётно (в математичексом смысле), а в С++ конечно.

Ну да, «несчетное количество типов» - это удобно.

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

(define: test-index : Positive-Index 10)
(define: test-byte : Byte (cast test-index Byte))

Только не надо опять про Any - если общий тип только такой получается, а функция ожидает что-то другое, то будет ошибка и всё.

Собственно, твой вариант шаблона так и пишется:

Нет. Идея «того» шаблона была именно в том чтобы иметь обобшённый код, который не надо модифицировать при появлении новых типов, которые (логически) туда можно передать. Другое дело, что я знал, что функции в ракете перегружать нельзя, так что это просто теряет смысл.

Лучше расскажи мне как/почему без перегрузки обходятся в ракете.

Можно уточнить?

#include <iostream>
#include <vector>

class Int { /// тут можно (или даже нужно) зафрендить Array чтобы менять value
public:
  operator int () { return value; }
  Int(int value): value(value) {}
private:
  int value;
};

Int n(3);
Int m(3);

template<Int& dimension, class Element> class Array
{
public:
  Element& operator[] (int i)  { if( i<0 || i=>dimension) throw "bounds"; return array[i]; }
  Array(): array(dimension) {}
private:
  std::vector<Element> array;
};

int main()
{
  Array<m,double> a;
  Array<n,double> b; /// a другого типа, чем b, хотя и m=n=3
  a[2]=2.5;
  std::cout << a[0] << " " << a[1] << " " << a[2] << "\n";
  return 0;
}

а вот это:

int n;
int main()
{
   n = ...;
   int y[n];
}

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

Тут важнее что движения вокруг языка не останавливаются и продолжаются, чтобы не говорили тут на Лоре.

На моей памяти движение вокруг языка не останавливается с 2001-го года. Хотя, если бы движение остановилось года на три-четыре в районе начала 2007-го, когда был выпущен D 1.000, а затем в него добавили поддержку текстовых mixin-ов, то это было бы языку только на пользу.

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

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

Либо пробуют исключительно с целью доказать, что язык - говно.

Молодой человек, в 2006-2007 я так же увлеченно агитировал за D (и здесь, и на RSDN-е). Только вовремя понял, что у авторов языка нет цели сделать готовый продукт. И дальнейшее развитие событий это подтвердило. После меня здесь было еще несколько человек, которые проделывали то же самое. И с таким же результатом. Так что ваша попытка лежит в том же русле и подтверждает репутацию D, как долгостроя, от которого кто-то все время чего-то ждет, а потом куда-то исчезает. А вместо него появляется еще кто-то, кто что-то от D ждет.

Это не работает.

Если хотите популяризировать D и верите в то, что на нем можно делать серьезные разработки, то перестаньте постить на профильных ресурсах подобные анонсы. Школоту, вы может на какое-то время и привлечете. А более опытных людей, у которых перед глазами сменилось несколько потенциальных «серебрянных пуль», нет.

Лучше расскажите о том, что делается на D прикладного. Или близкого к этому. О реальных разработках, не имеющих отношения к компилятору D или его стандартной библиотеке. Покажите, как делать обработку больших объемов данных, как работать с различными типами СУБД, как строить распределенные приложения и т.д. и т.п. И не на игрушечных примерах, а из реальной жизни. Раз вы верите в применение D в продакшене, так покажите это миру. Расскажите, как это происходит, какие задачи решаются, с какими затратами, сложностями или преимуществами по сравнению с другими языками/платформами.

Так вы больше пользы D принесете.

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

Да идею я, в принципе, уловил.

По этой же причине отказ в расте от tail call optimization расстроил, в своё время. Хотя в С++ этого тоже нет.

Может у Вас одного так? В моем браузере моя же ссылка отображается за милую душу.

Нет, в теме кто-то ещё жаловался.

Как раз наоборот, очевидно принимала бы Any. Так как на стадии компиляции определить классы, которые будут реализованы невозможно.

Которые будут реализованы и не надо. Достаточно те, которые «видны» в данный момент. Именно как в С++ шаблонах.

Я посмотрел, чего они стоят. 1. Нельзя объявить нестатический член класса с шаблонным типом. 2. Нельзя использовать шаблонные типы в объявлении виртуальных функций. Интересно, откуда такие серьезные ограничения?

Что до SBCL declare type, то где я могу почитать про нынешнее состояние дел с ним? И в частности, про поддерживаемые типы.

http://sbcl.org/manual/index.html#Handling-of-Types

Там написано, что не работает только с satisfies. И поля в объектах CLOS тоже не умеет.

На Racket я недавно смотрел и забил. Это - не production ready язык. И никогда им не станет.

Очень надеюсь, что всё-таки станет. И вообще, по скорости он не медленнее того же Питона. Который вполне production ready (или нет?).

про typed racket что скажешь?

Страшен как борода Столлмана

Так же я бы хотел лучшего статического контроля, какой-то практичной разновидности зависимых типов(причем мутабельных тоже), активного использования таких техник, как shape analysis, механизм вывода регионов, но без отказа от кастомных распределителей, опционального(полностью, а не как в D) сборщика мусора и пр. и пр.

Посмотри на Mercury

По факту нет.

Ясно, жаль.

везде.

Грамотный распил, весь тред подобного поста ждал!

На данный момент размер вознаграждения за исправление багов в общей сложности насчитывает 1500$. Со слов Александреску, они будут внимательно смотреть, как это скажется на сообществе.

Ахах...Никак

Если хотите популяризировать D и верите в то, что на нем можно делать серьезные разработки, то перестаньте постить на профильных ресурсах подобные анонсы.

Смысл анонса был в том, что язык продолжает двигаться. Ситуация с переходом на D2, которая вас оттолкнула, безусловно имеет негативные последствия, но люди научились многому и теперь даже речи не идет о D3, об этом даже не принято заикаться. Но у меня цели не было сказать всем, что дрожите, идет убийца плюсов - на убийцу плюсов он не тянет в моих глазах, по крайней мере пока. Это интересный и перспективный язык, который может круто взлететь, а может и запылиться на полках. И для языка важен рост коммьюнити - в первую очередь на это направлен анонс. Вы вот 7 лет назад бросили его, а язык за это время не только не умер, но стал еще намного лучше - это уже далеко не D1. Да, вас оттолкнул переход на D2, но других это не оттолкнет, потому что переходов больше не будет. И чем больше людей узнают, что есть такой язык и что язык развивается, тем потенциально больше будет общество. В свое время, кстати, в вину языку ставили то, что за ним нет корпорации, дескать не взлетит.

Из реальных проектов посмотрите vibe.d - более чем реальный. И тот же sociomantic в продакшене использует D1.

как/почему без перегрузки обходятся в ракете

Потому же, почему и в Haskell'e. И в Си.

На самом деле есть Swindle: библиотека для Racket с полным CLOS. Соответственно defgeneric и всё такое.

Хотя на вопрос «почему» мне на ЛОРе отвечали. Чтобы не было как в C++, где «s << 2» может пишет в строку, а может умножает на 4. Или фееричное

string s = "Hello" + 2; // работает
string s2 = "Hello";
s2 = s2 + 2; // не работает

Дело в том, что в Scheme есть возможность локального переопределения функций. Поэтому если мне надо работать с матрицами, я лучше напишу with-matrix, который будет разворачиваться в (let ([+ matrix+] [* matrix*]) ...) чем буду глобально переопределять операции суммирования и умножения.

Более того, в своём модуле я могу даже написать (define (+ a b) ...) и пользователь моего модуля сможет использовать мой +. Но он будет делать это осознанно.

Даже твой пример с test (a,b) = a+b. В C++ я не могу получить гарантию, что + вернёт тот же тип, что и аргумент и что + является чистой функцией. И если пользователь моего test не знает, что внутри +, то могут быть неожиданные результаты.

Хорошо сказано

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

Которые будут реализованы и не надо.

То есть

(define-gen foo (a b))
(define+ (foo (a : Int) (b : Int)) ...)

(define: (test a b) (foo a b)) ;; ужимает до (Int Int)

(define+ (foo (a : String) (b : String)) ...)

(test "a" "b") ;; ошибка, ожидается Int Int

Именно как в С++ шаблонах.

В них типизация происходит в момент инстанцирования. И работает только за счёт жёстких типов у всех переменных и значений. Можно написать такую штуку на макросах, но тогда получится С++ по возможностям (гетерогенный вектор уже никак), но без его скорости (так как внизу всё равно Racket+JIT). Никому не надо.

А подробнее с кодом можете показать, что у вас не получилось?

Facebook платит за устранение багов в реализации языка программирования D

Ну они не первый раз хней страдают...

Сразу вспоминается это

Фейсбук легок на кидалово http://www.cnews.ru/news/top/index.shtml?2013/08/19/539654

Хотя на вопрос «почему» мне на ЛОРе отвечали. Чтобы не было как в C++, где «s << 2» может пишет в строку, а может умножает на 4.

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

A.f(2);
B.f(2);

Или фееричное

Это тоже немного не то. Первое уж лучше бы не работало. И не вижу ничего странного, что для разных сущностей разные операции разрешены.

чем буду глобально переопределять операции суммирования и умножения.

Так в С++ это не «переопределение». От того, что я добавлю своему классу оператор + остальное сложение не поломается.

Даже твой пример с test (a,b) = a+b. В C++ я не могу получить гарантию, что + вернёт тот же тип, что и аргумент и что + является чистой функцией

Гарантий чистоты С++ не предоставляет, это да. Но если для какого-то типа плюс возвращает нечто другое, то при передаче аргументов этого типа в функцию test произойдёт ошибка компиляции, то есть всё хорошо.

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

И если пользователь моего test не знает, что внутри +, то могут быть неожиданные результаты.

Например?

На реальном компьютере с конечной памятью тип с несчётным множеством существовать не может.

Но сначала ты сказал про несчетное количество типов, а не про тип с несчетным множеством значений.

С++ по возможностям (гетерогенный вектор уже никак)

Да ладно?

std::vector<boost::any> v;

typedef boost::variant<int, my_class, std::string> types;
std::vector<types> v;

Не спорю с тем, что куча языков без перегрузки и обобщённых функций живёт. Просто, по моему, это удобно.

о без его скорости (так как внизу всё равно Racket+JIT)

Я просто не понимаю какие преимущества дают такие полиморфные функции.

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

Я бы хотел посмотреть как он за $100 пофиксит баг "[CTFE] copy-on-write is slow and causes huge memory usage", который висит 2 года. Видимо, такого уровня спец должен с ним разделаться минут за 15.

Не получится. Разделение обязанностей же. Кто-то за большие деньги пишет умные книжки и код, рассчитанный исключительно на «fast copy-on-write». А кто-то за 100$ реализует этот самый «fast copy-on-write», имея на руках лишь наколеночный набросок реализации компилятора языка, т.к. на нормальную реализацию у авторов языка времени не хватило - дедлайн на основной работе приближался.

в общей сложности

лол, и правда.

четыре копирования списка, зато выразительно и функционально

Хорошая реализация языка должна поощрять выразительный, идиоматический код.

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

Нет, я код на нем не писал. Почитал документацию. Навскидку не получится параметризовать класс каким-нибудь объектом-политикой, типа:

template <typename Policy> class Storage { Policy policy;

... }

Там написано, что не работает только с satisfies. И поля в объектах CLOS тоже не умеет.

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

А еще, можно ли в Common LISP сделать так:

data Tree a = Leaf { value :: a } | Node { left :: Tree a, right :: Tree a }

case value of
  Leaf { value } -> ....
  Node { left, right } -> ...

Спрашиваю не просто так. Мне часто нужно нечто подобное.

Причём было бы неплохо доступ к полям записей просходил через dot notation, а не через функции, замусоривающие пространство имён, как это происходит в Haskell.

Очень надеюсь, что всё-таки станет. И вообще, по скорости он не медленнее того же Питона. Который вполне production ready (или нет?).

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

В результате, повседневные программы - однодневки пишутся на python без проблем, а на racket - нет.

Крупный софт на них обоих писать - самоубийство. Хотя фанатики пишут (на python, конечно).

Что до скорости исполнения, то для некоторых задач её хватает. А для некоторых и нет. Так зачем же тратить время на что-то не особо быстрое (и без перспектив в этом плане), со слабыми библиотеками, и сообществом, оторванным от реалий промышленной разработки.

Ну и как понять, например, что за чёрт такой «darts.lib.hashtrie»?

А также то, кто его пишет, нормально ли оно оттестировано, не закинут ли проект разработчиком, какие версии были выпущены в production и были бы ли c ними известные проблемы, примеры использования, неочевидные особенности, и т.д.?

Так зачем же тратить время на что-то не особо быстрое (и без перспектив в этом плане), со слабыми библиотеками, и сообществом, оторванным от реалий промышленной разработки.

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

А эти пару лет пройдут ооочень быстро, уж поверьте.

Но сначала ты сказал про несчетное количество типов, а не про тип с несчетным множеством значений.

В Racket любое значение порождает тип (из одного значения). Также любое множество значений. Но так как общее множество всех значений счётно, то и количество всех подмножеств счётно

Что-то активный пиар D и Go пошел в последнее время. Эдак Rust все полимеры про...спит.

Например?

Например переопределит + на сложение по модулю, а от test будет ожидать нормальную сумму. Пример утрирован, сходу придумать не могу. Ну представь себе strlen реализованный в виде

<template T>
int tstrlen(T s)
{
   int i = 0;
   while(*(s+i) <> 0) i++;
   return i;
}

В предположении семантики char*. И какой-нибудь PString с переопределённым operator+(int second) как строковое сложение. Типа PString(«abc»)+2 = «abc2». Как в Perl.

А теперь что будет при tstrlen(PString(«abc»)) ? Ошибки не будет, но будет вечный цикл. Внезапно?

Если А и Б объекты разных классов.

В Racket, если функция зависит от класса, то это очевидно. Так как она при этом метод и вызывается как (send A f 2) (send B f 2), а не (f 2)

какие преимущества дают такие полиморфные функции

такие — это как в Typed Racket ? Исключительно возможность описать тип контейнера без указания типа элемента. Ну или в самом извращённом случае может быть такой тип:

(: fold-left
   (All (C A B ...)
        ((C A B ... B -> C) C (Listof A) (Listof B) ... B
         ->
         C)))

Вы вот 7 лет назад бросили его, а язык за это время не только не умер, но стал еще намного лучше - это уже далеко не D1.

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

Итак, в середине 2006 года пошли серьезные разговоры о том, что D1 готов к релизу и пора этот релиз делать, а все дальнейшие улучшения оставить на потом. На тот момент ситуация с C++ была аховая. Не так давно был зафиксирован стандарт C++03, но компиляторов, его полностью поддерживающих не было (возможно, таковым был comeau c++, но это был редкий зверь, которого живьем мало кто видел). Работы над C++0x шли не ахти, остряки даже шутили, что x — это шестнадцатирична цифра, не десятичная, и оказались правы. В этот момент D1 был однозначно намного-намного лучше C++. Да еще был представлен в виде единственного компилятора на всех платформах, а не как в C++, где у каждого компилятора (или его версии) были свои заморочки. Да и с либами у C++ было не так уж и хорошо. Qt была всего под двумя лицензиями (коммерческой и GPL), Boost был еще не таким большим (того же Asio, по-моему, в нем не было тогда). Из бесплатных больших библиотек были разве что ACE и wxWindows.

А что было вокруг? Вокруг была Java, которая уже забрала на себя весь server-side, а так же отжирала кросс-платформенные вещи у C/C++. Популярность получал Python, начинался феномен Ruby-On-Rails, заговорили об Erlang-е, зарождался hype вокруг функциональщины. Microsoft активно двигала .Net, пыталась всех на него пересадить и говорила об умирании native-разработки под Windows. Что будет с мобильными платформами после смерти PalmOS, непонятным состоянием WinCE и феноменальным успехом iOS на iPhone мало кто понимал.

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

Но даже при этом всем было понятно, что сам по себе язык D не так уж и полезен. К нему нужен стабильный качественный компилятор, отлаженная run-time библиотека с быстрым и надежным сборщиком мусора, нужны хорошие инструменты (IDE, профайлеры, отладчики, статические и динамические анализаторы) + большие околосистемные и околоприкладные библиотеки. Ничего этого тогда не было. Можно было бы рискнуть вложиться в язык в надежде, что все это появится. А для этого следовало разработку языка заморозить на несколько лет, переключившись на разработку всего вышеперечисленного.

Что же сейчас?

C++11 давно принят, реализован в GCC и clang, более-менее нормальная его поддержка есть даже в MSVC++. Более того, C++14 не только на грани принятия, но и вполне себе поддержан в тех же GCC и clang. При этом C++11 делает даже D2 не таким привлекательным, как это было c C++03 и D1 в 2006-м. При этом тот же Boost очень серьезно разросся, Qt есть под LGPL. Microsoft опять заговорила о важности native-кода и активно развивает MSVC++. Мобильные платформы стали серьезной нишей, в которой C++ может использоваться для кросс-платформенной разработки как ресурсоемких частей приложений, так и всего приложения целиком, включая GUI (не случайно Qt сейчас активно портируют под Android и iOS). При этом для C++ есть и IDE, и отладчики, и профайлеры, и статические анализаторы, и куча библиотек, и толпы разработчиков, и огромное количество литературы/ресурсов. Google вон Go выкатил, который так же нативный, со сборкой мусора и очень быстрой компиляцией. Причем Go зафиксирован и совместимость с Go 1.0 ломать не спешат.

Что-то из этого появилось у D за прошедшие 7 лет? Нет. Сам язык куда-то продвинулся, возможно. Но начинать на нем что-то серьезное, зная текущую ситуацию с инструментарием и прошлое этого языка? Может для каких-то задач это и оправдано. Например, для чисто вычислительных. Помнится, в списках рассылок D был некто Don Clugston, который рассказывал как он такими вещами занимался. Тут да, тут кроме языка и эффективного кодогенератора особо ничего не нужно. Но как только появится что-то вроде работы с СУБД, с криптографией, с какими-нибудь сторонними библиотеками (плюсовыми, например), со стандартами вроде CORBA или SOAP, тогда что делать?

И, прошу заметить, я пока противопоставлял D только C++. Если противопоставить его той же Java (или платформе JVM для которой кроме Java есть Scala, Ceylon, Clojure и скоро появится Kotlin), то получится не менее печально для D, т.к. его инфраструктура и комьюнити не идет ни в какое сравнение с миром JVM.

Из реальных проектов посмотрите vibe.d - более чем реальный. И тот же sociomantic в продакшене использует D1.

И опять неправильный посыл. Что толку мне на них смотреть? Для продвижения языка нужны материалы вроде хорошо написанных success stories. Вроде того, что была вот такая проблема, мы пытались ее решить так и так, в итоге решили на D вот так вот. И это хорошо потому что бла-бла-бла, но есть некоторые вещи вроде бла-бла-бла и т.д. и т.п.

Если тот же vibe.d настолько хорош, то пусть кто-то из D-комьюнити возьмет на себя труд показать, чем он лучше, скажем Wt. Или Boost.Asio. Или HttpServer из POCO. Или HTTP-сервер из примеров ACE. А то ведь можно подумать, что vibe.d хорош потому, что это единственный web-фреймворк для D.

Теперь согласен

Я три года назад уже слышал что-то подобное о D.

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

Конечно. API делаешь через (declare (ftype ...)) (defun ...) и получаешь полную гарантию.

А еще, можно ли в Common LISP сделать так:

(defclass tree ())
(defclass leaf (tree) 
  ((value :accessor value-of)))
(defclass node (tree) 
  ((left :accessor left-of) 
   (right :accessor right-of)))

(typecase val
  (leaf (value-of val) ...)
  (node (left-of val) (right-of val) ...))

Если нужен жёсткий контроль типа, то

(declare (ftype (function (leaf) tree) leaf-value))
(defun (leaf-value leaf)
  (value-of leaf))

Причём было бы неплохо доступ к полям записей просходил через dot notation

Есть slot-value: (slot-value my-var 'value) == (value-of my-var). Тогда можно просто :accessor не делать и всё.

Если хочется красиво, то есть https://github.com/Kalimehtar/message-oo

Потому же, почему и в Haskell'e.

Там, вроде как, можно что-то на тайпклассах сделать.

И в Си.

Ну в С обобщённость реализуют через войд (типа как в qsort).

Еще пара лет и на D будут писать успешный коммерческий софт, а плюсисты будут курить бамбук
А эти пару лет пройдут ооочень быстро, уж поверьте.

Я бы поспорил, жаль через «пару лет» это забудется.

В Racket любое значение порождает тип (из одного значения).

Где это видно?

> 10
- : Integer [generalized from Positive-Byte]

Крупный софт на них обоих писать - самоубийство. Хотя фанатики пишут (на python, конечно).

И на Racket пишут (две штуки попадалось). Хотя, конечно, тоже фанатики.

Так зачем же тратить время на что-то не особо быстрое (и без перспектив в этом плане), со слабыми библиотеками, и сообществом, оторванным от реалий промышленной разработки.

Затем, что многие вещи на нём решаются реально быстрее. Например, понадобилось мне сделать программу для чтения WMI под оффтопик, так на C++ только бойлерплейта две страницы. Или COM-объект подключить — аналогично.

Парсинг HTML: код получился не длинней аналогичного на XMLPath. GUI строится в 3 строки, веб-сервер в 4. При этом нормальная многопоточность, возможность использовать замыкания и продолжения, вложенные функции, макросы.

Фактически, ниша Racket где-то между скриптовыми языками и Java. Он быстрее скриптовых и на нём проще писать, чем на Java.

Активно использую для программ, для которых скорость неважна (фактически скриптовые), но которые не являются одноразовыми (там действительно проще bash или python). Дописывать программу на Racket гораздо проще, так как система модулей почти заставляет сразу делать более-менее нормальный API (а не пачку глобальных переменных).

Пример утрирован, сходу придумать не могу.

Вот и я о том же. Понятное дело, что можно любой бред написать и поиметь «проблемы». Но это же не значит, что надо как можно сильнее ограничивать возможности.

И какой-нибудь PString с переопределённым operator+(int second) как строковое сложение. Типа PString(«abc»)+2 = «abc2».

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

Ошибки не будет, но будет вечный цикл. Внезапно?

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