LINUX.ORG.RU

Arc is released

 , , ,


0

0

Arc - новый диалект Lisp от небезызвестного на ЛОР Пола Грехема. Заявил Пол о нем еще в далеком 2001 году и с тех пор регулярно писал об этом языке на своем сайте: http://paulgraham.com/

И теперь этот язык доступен для общественности. Язык сейчас реализован поверх MzScheme. Пол позиционирует Arc в качестве языка для хакеров и не обещает обратной совместимости в будущем ;)

Веб-страница языка: http://arclanguage.org/

Скачать можно по ссылке: http://ycombinator.com/arc/arc0.tar

>>> Подробности

Ответ на: комментарий от anonymous

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

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

satanic-mechanic
() автор топика

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

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

Legioner ★★★★★
()
Ответ на: комментарий от satanic-mechanic

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

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

warkot
()
Ответ на: комментарий от Legioner

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

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

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

anonymous_incognito ★★★★★
()
Ответ на: комментарий от anonymous_incognito

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

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

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

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

tailgunner ★★★★★
()

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

pierre
()
Ответ на: комментарий от tailgunner

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

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

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

anonymous_incognito ★★★★★
()
Ответ на: комментарий от anonymous_incognito

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

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

Legioner ★★★★★
()
Ответ на: комментарий от anonymous_incognito

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

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

Led ★★★☆☆
()

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

anonymous
()
Ответ на: комментарий от anonymous_incognito

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

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

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

AlexLorovitch
()
Ответ на: комментарий от AlexLorovitch

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

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

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

AlexLorovitch
()
Ответ на: комментарий от Legioner

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

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

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

anonymous_incognito ★★★★★
()
Ответ на: комментарий от AlexLorovitch

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

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

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

anonymous_incognito ★★★★★
()
Ответ на: комментарий от Led

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

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

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

anonymous_incognito ★★★★★
()
Ответ на: комментарий от anonymous_incognito

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

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

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

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

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

AlexLorovitch
()

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

MiracleMan ★★★★★
()

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

stassats ★★★★
()
Ответ на: комментарий от anonymous_incognito

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

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

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

Led ★★★☆☆
()
Ответ на: комментарий от pierre

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

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

Burbaka ★★
()

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

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

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

ero-sennin ★★
()
Ответ на: комментарий от Legioner

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

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

Relan ★★★★★
()
Ответ на: комментарий от anonymous_incognito

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

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

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

rlz
()

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

mihalych ★★★
()
Ответ на: комментарий от rlz

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

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

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

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

AlexLorovitch
()
Ответ на: комментарий от pierre

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

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

Да за такой '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))

Darkman ★★★
()
Ответ на: комментарий от Darkman

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

mihalych ★★★
()
Ответ на: комментарий от anonymous

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

satanic-mechanic
() автор топика
Ответ на: комментарий от Darkman

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

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

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

>(if a b c d e)

>is equivalent to

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

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

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

AlexLorovitch
()
Ответ на: комментарий от Led

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

satanic-mechanic
() автор топика
Ответ на: комментарий от AlexLorovitch

>> (if a b c d e)

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

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

Darkman ★★★
()
Ответ на: комментарий от satanic-mechanic

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

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

anonymous
()
Ответ на: комментарий от Darkman

>> (if a b c d e)

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

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

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

AlexLorovitch
()
Ответ на: комментарий от Darkman

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

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

pierre
()
Ответ на: комментарий от AlexLorovitch

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

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

(if a b (if c d e))

Darkman ★★★
()
Ответ на: комментарий от pierre

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

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

Darkman ★★★
()
Ответ на: комментарий от AlexLorovitch

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

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

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

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

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

rlz
()
Ответ на: комментарий от Led

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

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

foo() + bar()

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

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

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

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

aton
()
Ответ на: комментарий от pierre

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

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

Darkman ★★★
()
Ответ на: комментарий от unisky

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

Именно так. Например "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"? ;)

satanic-mechanic
() автор топика
Ответ на: комментарий от aton

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.