Здравствуйте, PC_2, Вы писали:

KV>>"выглядит примерно вот так, хоть пока и не работает" (с)

PC_>У меня в первом списке список программ. И они прекрасно работают.
PC_>Решения в студию от Немерла для всех их пожалуйста.

Да не вопрос:

PC_>//1. факториал
PC_>E 1..5\*

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

public macro @!(e1)
syntax (e1, "!")
{
    <[
        $[1..$e1].FoldLeft(1,_*_)
    ]>
}

// После чего мы можем использовать вот такую запись

WriteLine(5!);

// В результате будет выведено "120"

Если же имеет место второй случай, то из записи "E 1..5\*" ну никак не следует, что это является именно факториалом, если не поломать голову и, исходя от обратного, не предположить, что "\" означает "применить операцию", а "*" то, какую операцию нужно применить. Я сначала это вообще за оставленный по ошибке комментарий принял. В немерловском варианте, этот алгоритм можно найти в макре между <[ и ]> :

$[1..5].FoldLeft(1,_*_)

причем это, в отличии от вашего варианта, именно алгоритм, а не "так захотелось автору языка" и читается как "взять диапазон от 1 до 5 и применить к нему операцию левой свертки, умножая текущий элемент с аккумулятором, имеющим по умолчанию значение 1".

И правильно ли я понимаю, что выражение "1..5" означает "создать массив из пяти элементов, в котором X[i] = i"? Но ведь тогда, для того, чтобы посчитать факториал 1048576, ваша программа отожрет 1 мегабайт памяти только для формирования индексов, в то время, как в том же немерле можно обойтись по старинке:

def factorial(n){ | 0 | 1 = > 1 | _ => factorial(n — 1)}

и никаких мегабайтов отожрано не будет (к вопросу о вашем замечании по поводу быстрой сортировки).

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

PC_>//2. фибоначчи
PC_>E X:=1..10
PC_>E X.(I+2):=X.I+X.(I+1)
PC_>E X

def f(n) { | 0 | 1 => 1 | _ => f(n-2) + f(n-1) }
def X = $[1..10].Map(f);
WriteLine(X);

PC_>//3. сортировка пузырьком
PC_>E X:=1..10
PC_>E X.I>X.J?X.I:=:X.J
PC_>E X

Здесь среднюю строчку можно было бы и выкинуть, ибо зачем сортировать уже упорядоченную последовательность? Но, ок:

mutable X = $[1..5].ToArray();
_= X.IterI((i, _) => X.IterI((j, _) => when (X[i] < X[j]) X[i] <-> X[j]));
WriteLine(X.ToList())

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

PC_>//4. палиндром
PC_>E X:=1,2,3,2,1
PC_>E B:=True
PC_>E B:=B&(X.(5/2-I)=X.(5/2+I))
PC_>E B

mutable X = array[1, 2, 3, 2, 1];
mutable B = true;
_ = $[0..2].IterI((i, _) => {B = B && (X[i] == X[5-i])});
WriteLine(B);

PC_>//5. revers
PC_>E X:=1..5
PC_>E X.(5/2-I):=:X.(5/2+I))
PC_>E X

def reverse(lst, acc = [])
{
| (head :: tail, _) => reverse(tail, head :: acc)
| ([], _) => acc
}
// А теперь, заодно, проверим список на палиндромность еще раз
def X = [1, 2, 3, 2, 1];
WriteLine(reverse(X) == X);

PC_>//6. проверка на простое число
PC_>E X:=6
PC_>E X%2..(X-1)\<

def X = 6;
def B = $[2..X - 1].Fold(true, (x, a) => a && (X % x != 0));
WriteLine(B);

KV>>Я предлагаю сначала поиграть в другую игру: уберите комментарии, объясняющие предназначение каждого сниппета и опросите местный народ на предмет понимания ими того, что делает каждый из кусков кода. Кстати, а зачем эти комментарии вообще понадобились в черезвычайно легком в понимании языке?

PC_>Немерла хоть комментируй хоть не комментируй, разобраться сложно.

Вы в дискусии на что-то более конструктивное, чем "сам дурак", способны? Или сворачиваем беседу? Я пока еще жду внятного ответа на свой вопрос.

KV>>Все дело в том, что он не только от архитектуры оторван

PC_>А от чего еще ?

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

PC_>А пока Немерла, пускай для меня, пасет задних. Пускай и на том наборе простых типовых программ.

Будете капризничать — вообще Влада позову