Arc is released

Это что-то вроде библиотеки для MzScheme? :)

Это не библиотека, это программа написанная на MzScheme и использующая его рантайм.

Кстати, весь исходник занимает 168KiB. Не так уж много для 7 лет разработки ;)

Интересно. Безотносительно самого диалекта, Поль — фигура яркая, а популярность лиспу не помешает.

Всё же лисп — могучий язык. Читаю диссертацию 85 года, в ней написано, лисп — самый старый, после фортрана, язык, использующийся сегодня. 23 года прошло, а ничего не изменилось :-)

>Кстати, весь исходник занимает 168KiB. Не так уж много для 7 лет разработки ;)

Если оценивать прогу по обьему, то сВиста - самая труЪ ОС

> Читаю диссертацию 85 года, в ней написано, лисп — самый старый, после фортрана, язык, использующийся сегодня. 23 года прошло, а ничего не изменилось :-)

Кое что поменялось. Фортран сейчас стал нишевым языком, используемым практически из соображений совместимости. Не настолько как Cobol ещё, плюс имеются хорошие компиляторы для него, но даже в научной среде он уже куда менее популярен как 23 года назад.

А вот lisp развивается и используется.

> Фортран сейчас стал нишевым языком, используемым практически из соображений совместимости

Последний стандарт принят в 2003, разрабатывается следующий.

> А вот lisp развивается и используется.

Да, Лисп давно был известен кучей не очень совместимых диалектов. Вот и еще один появился 8)

А в чем отличия от Schema/CL ?

Пожалуй, самый приличный лисп -- не такой страшный и порядком логичный. Напоминает хаскель местами

http://arclanguage.org/item?id=81

Офигеть, уникода нету. Таки не самый приличный

> Последний стандарт принят в 2003, разрабатывается следующий.

Ну до состояния Cobola фортран ещё не дошёл и дойдёт очень не скоро из-за просто колоссального количества тщательно отлаженных реализаций различных математических методов.

Но неужели он чем-то как язык заметно лучше для создания расчётных программ, чем тот же Си?

> Но неужели он чем-то как язык заметно лучше для создания расчётных программ, чем тот же Си?

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

>Но неужели он чем-то как язык заметно лучше для создания расчётных программ, чем тот же Си?

Научи - как в "Си" получить ГАРАНТИРОВАННЫЙ порядок вычисления выражений?:)

Грэма, бkzlm, Грэ-ма!

> Ну до состояния Cobola фортран ещё не дошёл

> Но неужели он чем-то как язык заметно лучше для создания расчётных программ, чем тот же Си?

В Си нормальная работа с массивами появилась только в 99 году - читай С99

> Но неужели он чем-то как язык заметно лучше для создания расчётных программ, чем тот же Си?

> В Си нормальная работа с массивами появилась только в 99 году - читай С99

Тогда же в Си появилась работа с комплексными числами

> Пол позиционирует Arc в качестве языка для хакеров...

Спсб, посмеялся.

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

Чем таким особенности Си сложнее особенностей фортрана для математика, если он раньше не изучал их и не имеет уже сложившихся предпочтений?

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

> В Си нормальная работа с массивами появилась только в 99 году - читай С99

Да про массивы я как-то забыл, вернее на мой вкус особых сложностей и не было никогда, но в фортране было проще. Ещё помню цикл DO с тройным ветвлением казался удобным.

Я помню, что у нас как раз в конце 90-х годов очень активно стали уходить от фортрана к си, во всяком случае, новые вещи старались делать на Си, причём отнюдь не C99, использовался NDP C уж не помню что он поддерживал из Си.

> Научи - как в "Си" получить ГАРАНТИРОВАННЫЙ порядок вычисления выражений?:)

А что, в выражении типа a = b*(c/d) вдруг может вычислиться сначала b/d и потом умножиться на c?

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

> Я помню, что у нас как раз в конце 90-х годов очень активно стали уходить от фортрана к си,

Вы просто не умеете их готовить :)

A Фортран-90-95 - для расчетов очень неплохая штука. Там с массивами есть прямые операции ( как в том же Matlab). И вообще, современный Фортран сильно не похож на тот Фортран-66, который в школе учили.

Старинный DO теперь не в моде - там теперича DO END, WHILE, IF THEN ...

Даже ООП запихнули...

Ишь ты.. что-то любопытное.. надо бы глянуть.. ;-)

Спасибо, посмеялись от души.

Сам ПЖ:

http://www-jcsu.jesus.cam.ac.uk/~csr21/lolpg.jpg

>А что, в выражении типа a = b*(c/d) вдруг может вычислиться сначала b/d и потом умножиться на c?

Вопросом на вопрос отвечаем?:)

Порядок вычислений выражений в С не гарантируется, остаётся "на усмотрение" компилятора. На таких "сложных" выражениях как "a=b*(c/d)" математические вычисления не заканчиваются:)

> Офигеть, уникода нету. Таки не самый приличный

Там не то что юникода, там нормальной реализации до сих пор нету. Существующую можно назвать не более чем прототипом.

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

http://arclanguage.org/item?id=391

Хотя фиг знает, как он умудрился сломать юникод, который в MzScheme искоробки.

> Читаю диссертацию 85 года, в ней написано, лисп — самый старый, после фортрана, язык, использующийся сегодня. 23 года прошло, а ничего не изменилось :-)

Т.е. даже через 23 года Лисп как был самым старым после Фортрана, так и остался? Поразительно! :)

>Чем таким особенности Си сложнее особенностей фортрана для математика, если он раньше не изучал их и не имеет уже сложившихся предпочтений?

>Хотя, да массивы в фортране были удобнее сишных и комплексные числа есть. Но как язык в целом, на меня фортран производит впечатление нагромождённости.

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

Если бы меня заставили писать на диалекте Лиспа, я бы выбрал Arc, как имеющий наиболее прагматичный синтакс. Но как ни старайся, Arc всё равно останется удобным хаком поверх Лиспа, со всем из этого вытекающим. К счастью, есть динамические языки с намного более прагматичным и читабельным синтаксисом.

>>Хотя, да массивы в фортране были удобнее сишных и комплексные числа есть.

>Еще особенности языка позволяют осуществлять более агрессивную оптимизацию. И есть весьма продвинутые компиляторы, например Compaq. От Интела тоже ничего компилятор. По тестам у нас на кафедре gcc им сильно сливает.

А Фортран от Sun Studio не пробовали на кафедре ?

Вроде бесплатный и 95 стандарт в полный рост.

> Пожалуй, самый приличный лисп -- не такой страшный и порядком логичный.

Логичный ???!!!

Да за такой 'if' убивать надо !

An if with more than three arguments is equivalent to a nested if.

(if a b c d e)

is equivalent to

(if a b (if c d e))

В CLISP точно такой же "if" (по крайней мере в том диалекте, который я лет 15 назад изучал).

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

>> Пожалуй, самый приличный лисп -- не такой страшный и порядком логичный.

>Логичный ???!!!

>Да за такой 'if' убивать надо !

>(if a b c d e)

>is equivalent to

>(if a b (if c d e))

А в чем разница-то вроде оно действительно эквивалентно ...

результат то правильный будет как ни крути

>Порядок вычислений выражений в С не гарантируется, остаётся "на усмотрение" компилятора. На таких "сложных" выражениях как "a=b*(c/d)" математические вычисления не заканчиваются:)

Ну так где же пример этого сложного выражения?

Ну, например, на сколько я знаю, порядок вычисления аргументов в вызове f(a, b, c, d) не определен стандартом. Если вычисление аргументов имеет побочный эффект, то результат в общем не гарантирован.

>> (if a b c d e)

> А в чем разница-то вроде оно действительно эквивалентно ...

У меня глаза отказываются воспринимать 'c' как условие.

>Ну, например, на сколько я знаю, порядок вычисления аргументов в вызове f(a, b, c, d) не определен стандартом. Если вычисление аргументов имеет побочный эффект, то результат в общем не гарантирован.

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

>> (if a b c d e)

> А в чем разница-то вроде оно действительно эквивалентно ...

> У меня глаза отказываются воспринимать 'c' как условие.

так это и не условие - if вставляется между b и с - фактически внутренняя кухня компилятора - единственно при таком раскладе порядок проверки условий неясен

> Да за такой 'if' убивать надо !

Так там в конце даже написано, что это такой cond с меньшим количеством скобок. Хотя может быть с точки зрения любителей лиспа сокращение скобок -- страшный грех :-)

> так это и не условие - if вставляется между b и с

Как это не условие, именно условие которое проверяет второй if:

(if a b (if c d e))

> Так там в конце даже написано, что это такой cond с меньшим количеством скобок.

Лишняя сучность. Там еще и лябда через '[]' идёт. Не Ъ.

Почему это -- лишняя? Не нравится что скобок мало?

> А Фортран от Sun Studio не пробовали на кафедре ?

> Вроде бесплатный и 95 стандарт в полный рост.

Нет. Не пробовали.

У нас большинство на 77 пишут, так что стандарт не критичен. От Intel'а тоже вроде бесплатный.

Я вообще fortran'ом мало занимаюсь. Предпочитаю lapack процедуры из С дергать.

> Порядок вычислений выражений в С не гарантируется, остаётся "на усмотрение" компилятора. На таких "сложных" выражениях как "a=b*(c/d)" математические вычисления не заканчиваются:)

Приоритет вычисления операторов прописан в стандарте и тут никогда проблем не возникает, другоде дело:

foo() + bar()

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

эту особенность надо знать и если порядок имеет значение то код надо переписать так:

foo_ = foo();
bar_ = bar();
foo_ + bar_;

Порядок вычислений выражений в C нарантируется.

> Почему это -- лишняя? Не нравится что скобок мало?

Не нравится implicit progn там где ему не место.

> Спсб, посмеялся.

Именно так. Например "Classic macros are a real hacker's tool-- simple, powerful, and dangerous. It's so easy to understand what they do: you call a function on the macro's arguments, and whatever it returns gets inserted in place of the macro call. Hygienic macros embody the opposite principle. They try to protect you from understanding what they're doing. I have never heard hygienic macros explained in one sentence. And they are a classic example of the dangers of deciding what programmers are allowed to want. Hygienic macros are intended to protect me from variable capture, among other things, but variable capture is exactly what I want in some macros.".

И это касается не только макросов но и многих других моментов в Arc. Этот язык по замыслу должен позволять любые грязные хаки. То есть язык является полной противоположностью например Java, которая ограничивает разработчика, чтобы он не написал слишком мудреного кода, который никто не поймет. ИМХО, здесь Пол слишком перестарался. С таким подходом плюс то, что сейчас язык из себя представляет, Arc не пригоден для реальной разработки ПО. Слишком многого Пол наобещал, а реально за 7 лет разработки (или писания ессе) выкатил какое-то непонятное нечто.

Как вам такое: "and we won't even keep track of the changes"? ;)

Кстати, кому интересно, здесь гораздо более живая по сравнению с LOR дискуссия по этому поводу: http://lambda-the-ultimate.org/node/2643

>тут порядок вычисления операндов стандарт оставил на усотрения >разработчиков компилятора, чтобы дать им больше свободы в оптимизации. >эту особенность надо знать и если порядок имеет значение то код надо >переписать так: >foo_ = foo(); >bar_ = bar(); >foo_ + bar_;

А что помешает компилятору(оптимизатору) переставить местами первую и вторую строчки ? Так что введение временных переменных ничего не гарантирует в данном случае.

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

satanic-mehanic, спасибо за коммент, а то авторы не удосужились написать туториал для лисперов, а написали его только для всех. В итоге, я закрыл этот Arc, не дочитав до конца, и вряд ли когда-то вернусь. Теперь я вижу, что прав был.

Вот вам за это кусочек сахара для CL в подарок (пользуюсь и не сомневаюсь в правильности сделанного выбора).

(defmacro let1 (var init &body body) `(let ((,var ,init)) ,@body))

соответственно, далее вместо (let (a b) ...) пишем (let1 a b ...)

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