язык Pony Существуют ли аналоги в более актуальном состоянии?

по первым пунктам - clojure. По третьему, непонятно что ты вообще имел в виду. По четвертому - посмотрел хэлловорлд на пони, какой же это Си? Это скорей CoffeeScript какой-то

3)гарантированным отсутствием любых ошибок в рантайме

на таких языках писать невозможно

Я думаю Erlang и Go (с его routines) сюда можно, за исключением последних пунктов, конечно.

По третьему, непонятно что ты вообще имел в виду

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

больше всего именно эти пункты интересны, без них не нужно

какой же это Си? Это скорей CoffeeScript какой-то

«Pony programs can natively call C libraries. Our compiler is able to generate a C-header file for Pony libraries. Consequently, C/C++ programs can natively call Pony programs!» — вот такое я имел в виду под 4-м пунктом

с чего бы?

Нет ошибки деления на ноль, т.к. нет ноля, ну и так далее.

Haskell.

1) Никаких проблем с много поточностью. Очень лёгкие зелёные треды.

2) Компилируется. Работает быстро.

3) Ну, любых — это ты загнул, такого нет вообще нигде; но типизация спасает от многого.

4) Отличный FFI, нет проблем импортировать C-функцию из библиотеки или экспортировать свою функцию для вызова из C.

возможную ошибку деления на ноль он в компилтайме ловит, если я правильно понял

Ну, любых — это ты загнул, такого нет вообще нигде

сабж это умеет

Никаких проблем с много поточностью. Очень лёгкие зелёные треды.

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

Ну вот введёт тебе юзер 0, как это при компиляции ловить?

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

сабж это умеет

Этого не бывает.

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

Что значит «на уровне ядра языка»? Компилятор поддерживает зелёные треды (ОЧЕНЬ лёгкие), а интерфейс к ним есть в стандартной библиотеке.

элементарно: во время компиляции пометить этим данные как вероятно содержащие 0, а потом проверять операции на допустимость. и то оно не всегда надо:

float g = 10;
g = g/0;
cout<<"Вывод: "<<g;

Вывод: inf

По третьему пункту подходит BASIC при использовании оператора ON ERROR RESUME NEXT.

Что значит «на уровне ядра языка»?

actor как ключевое слово, соответствующий синтаксис, например,

String iso // An isolated string
String trn // A transition string
String ref // A string reference
String val // A string value
String box // A string box
String tag // A string tag

как в сабже

Этого не бывает.

Вы про сабж читали? Там есть. Но речь, конечно о рантайм еррорах, а не вообще.

When we say Pony is capabilities-secure, we mean a few things:

    It's type safe. Really type safe. There's a mathematical proof and everything.
    It's memory safe. Ok, this comes with type safe, but it's still interesting. There are no dangling pointers, no buffer overruns, heck, the language doesn't even have the concept of null!
    It's exception safe. There are no runtime exceptions. All exceptions have defined semantics, and they are always caught.
    It's data-race free. Pony doesn't have locks or atomic operations or anything like that. Instead, the type system ensures at compile time that your concurrent program can never have data races. So you can write highly concurrent code and never get it wrong.
    It's deadlock free. This one is easy, because Pony has no locks at all! So they definitely don't deadlock, because they don't exist.

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

Я планирую сделать что-то подобное. Но пока хронически не хватает времени. Если хочешь, можем делать вместе.

В него в гите комитят довольно активно. А доков печально что нет.

actor как ключевое слово, соответствующий синтаксис, например,

В Haskell очень мало подобных adhoc-конструкций. Зато они отлично вписываются в общий синтаксис.

Там есть.

Нет, конечно.

When we say Pony is capabilities-secure, we mean a few things:

И где здесь «отсутствие любых ошибок»?

Неправильно понял. Во Float-ах деление на 0 просто даёт inf. В Int-ах ещё веселее, там результат деления на 0 равен 0.

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

деление на 0 просто даёт inf.

это не ошибка в рантайме, а валидная операция

В Int-ах ещё веселее, там результат деления на 0 равен 0.

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

capabilities-secure

а также:

It's exception safe. There are no runtime exceptions. All exceptions have defined semantics, and they are always caught.

соответственно, и такие вещи как деление на ноль должны ловиться в компилтайме

Вывод: inf

Это не доказывает корректность результата. Это хорошо что программа не упала, но, возможно, теперь она работает некорректно т.к. дальше код не ожидает что g == inf .

Это называется «PHP-подход»: вместо того, чтобы сказать об ошибке, сделаем что-нибудь не то.

Это хорошо что программа не упала

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

т.к. дальше код не ожидает что g == inf .

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

это не PHP подход. у вас же не вызывает удивления, что для однобайтового числа 255+1 = 0? так и 5/0 = inf и даже 5/0 = 0 не должно вызывать удивления. то, что + в ассемблере может внешне напоминать + из школьной арифметики ровно ни о чём не говорит

это и называется отсутствие рантайм-ошибки

Тут я, пожалуй, скорее соглашусь с Miguel: это больше похоже на сокрытие ошибки. Как в php оператор @. Т.е. я не говорю что ponylang это плохо итп, но конкретно с inf/nan мне не нравится. Хотелось бы как минимум видеть ворнинг при сборке. Ну или какую-либо опцию регулирующую это поведение.

для однобайтового числа 255+1 = 0?

Это так работает железо. А ЯП может, например, сделать int резиновым и тогда можно избежать целый класс ошибок называемых integer overflow. По мне так безопасный ЯП это тот который предотвращает появление ошибок.

5/0 = inf и даже 5/0 = 0 не должно вызывать удивления

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

это проблема кода и программиста

Это можно сказать про любой код. Но ведь ponylang как бы и задумывался чтобы попытаться нивелировать проблемы программиста и кода, не?

Мы про ассемблер или про что-то более высокоуровневое?

Т.е. я не говорю что ponylang это плохо итп, но конкретно с inf/nan мне не нравится

мне неизвестно, как поведёт себя он в этом случае: в туториале не описаны ф-ции ввода, поэтому проверить не могу, там только env.out.print есть. однако, догадываюсь, что поведёт себя он так: «во время компиляции пометить этим данные как вероятно содержащие 0, а потом проверять операции на допустимость.»

мне неизвестно, как поведёт себя он в этом случае

Я тебе уже сказал, как он себя ведёт. Даже когда число прописано в коде как константа.

введёт тебе юзер 0, как это при компиляции ловить?

Теоретически - можно.

При каждом ветвлении добавляем условие ветвления к набору переменных. И при делении сравниваем предикат «знаменатель != 0» с тем что у знаменателя на самом деле. Если знаменатель может быть 0, кидаем предупреждение (или ошибку). Например:

a = user_input();
b = user_input();

if ((b * b + a) != a) {
    c = a / b;
    /*
      Проверяем условие ((b * b + a) != a) && (b != 0):
      (b * b != a - a) && (b != 0)
      (b * b != 0) && (b != 0)
      (b != 0) && (b != 0)
      true, все нормально
    */
} else {
    c = a / (b + 1);
    /* тоже нормально */
}

d = a / sqrt(b); /* две потенциальных ошибки */

Но это очень простой случай, на чем-то сложном, наверное, так с наскока не получится

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

если говорить о принципиальной возможности ловли операций /0 в компилтайме, то я, в своём язычке(не сабже) эту задачу решил совершенно дубовым образом: у меня там в компилтайме каждая операция проверяется валидность, в том числе и на вероятный выброс ошибки деления на ноль. если вероятность возникновения таких ошибок существует, значит выбросится экзепшн в компилтайме. соответственно, в рантайме ошибок такого рода железно не возникнет.

если говорить про конкретно Pony, то мне неизвестно, как они эту задачу решили, причину см. выше

в своём язычке

можно ссылочку на гитхаб?

infinity является корректным значением

Да. К Float у меня претензий особых нет. А вот в Int 1/0=0 — это некорректный ответ.

если говорить о принципиальной возможности ловли операций /0 в компилтайме

то это, разумеется, вполне возможно. А вот «отсутсвие любых ошибок» невозможно гарантировать в принципе, потому что «любых» — это и алгоритмических в том числе.

если говорить про конкретно Pony, то мне неизвестно, как они эту задачу решили, причину см. выше

Я тебе уже сказал, как они её решили.

я пока не собираюсь выкладывать его в общий доступ, по причине того что 1) он не допилен, там куча багов 2) там говнокод в кишках, ибо писал на плюсах с подходом «лишь бы работало, всё равно буду переписывать на нём самом». 3)если я его открою, то в лицензии укажу свои реальные имя и фамилию, а на ЛОРе я их открывать не хочу в целях приватности

так что, извиняйте

это и алгоритмических в том числе.

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

Я тебе уже сказал, как они её решили.

Вам, действительно, известно, как они её решили?

Я протестировал простейшее 1/0, так что, да.

алгоритмические ошибки к ошибкам рантайма не относятся

Они проявляются в рантайме, так что...

теряюсь в догадках, как вам удалось. у меня он на простейшее c = 1/0 пишет: «/ponyc/webcontainer/main.pony:9:12: constant divide or mod by zero» а более сложное проверить не могу, ибо пример с их же туториала не работает:

while count <= 10 do
  env.out.print(count)
  count = count + 1
end

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

Ну, я что-то вроде такого написал:

var a: U32
var b: U32
a = 0
b = 1/a
env.out.print(b.string())

Кстати, только что проверил — counter из их example-ов вполне работает