using System.Console;
WriteLine(0);

	crash
	./ncc.exe a8.n * Assertion at sre-encode.c:290, condition `count > 0' not met ================================================================= Native Crash Reporting ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. =================================================================

	Linux
	noname@linux:~/Nemerle$ uname -a Linux linux 5.0.0-29-generic #31~18.04.1-Ubuntu SMP Thu Sep 12 18:29:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

	Mono
	noname@linux:~/Nemerle$ mono --version Mono JIT compiler version 6.4.0.198 (tarball Tue Sep 24 01:21:28 UTC 2019) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug Interpreter: yes LLVM: yes(610) Suspend: hybrid GC: sgen (concurrent by default)

И в тоже время:
Racket

#lang racket

(define (fact ac n)
  (if (= n 1) ac
  (fact (* ac n) (- n 1))))

(fact 1 100)

	Result
	Добро пожаловать в DrRacket, версия 6.11 [3m]. Язык: racket, with debugging; memory limit: 128 MB. 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

В статье четко оформлена мысль которая витала у меня в голове
последнии дни и оформилась когда я увидел анонс C# 8.

Боже как убого смотрится паттернматчинг( символ => стыдливо скрывает под собой банальный statement(инструкция) return).
Они не осилили блок конструкций в матчинге! И даже нельзя более одного условия использовать в обработчике.
В противовес этому такие языки как Nemerle или Racket представляют собой живое существо построенное из выражений(expression).
Вот чего фатально не хватает C# — выражений! Отсюда и необходимость натирать мозоли на пальцах.
И ожидание в течении нескольких лет такой простой вещи как записи.
Ну почему люди цепляются за старое? Ведь эволюция это единственный путь к улучшению.

Every expression is either a single value or a list.
PS Печально, что поддержка Nemerle так слаба несмотря на такие крутые вещи как Nitra или http://www.ammyui.com/.
При том что в репозитории встречаются документы с грифом права MS. Вероятно у кого-то была мысль заменить C# Nemerle, такая замена прошла бы очень гладко, но кто-то испугался перемен...

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

AA>В противовес этому такие языки как Nemerle или Racket представляют собой живое существо построенное из выражений(expression).
AA>Вот чего фатально не хватает C# — выражений! Отсюда и необходимость натирать мозоли на пальцах.

Фатально не хватает, да.

https://github.com/trending/nemerle

It looks like we don’t have any trending repositories for Nemerle.

https://github.com/trending/racket

It looks like we don’t have any trending repositories for Racket.

https://github.com/trending/c%23

...куча репозиториев...

Берегись, сишарп! Скоро тебе конец. Ведь у тебя нет выражений, а это фатально.

AA>Ну почему люди цепляются за старое? Ведь эволюция это единственный путь к улучшению.

Действительно, почему люди цепляются за такое старье, как лисп? Уже давно пора эволюционировать.

AA>Every expression is either a single value or a list.

В императивном языке ВСЕ делать выражениями не нужно. Иногда бессмысленно, а иногда и вообще вредно. Присваивание не должно возвращать ничего, равно как и операторы, влияющие на поток управления (return, break, continue, yield, throw, etc.). Да и многие другие вещи тоже — циклы, объявления типов и т.д. Собственно, выражений не так уж и много на самом деле.

AA>Вероятно у кого-то была мысль заменить C# Nemerle, такая замена прошла бы очень гладко, но кто-то испугался перемен...

Если такое и произойдет, то точно не в обозримом будущем. В C# вложены огромные ресурсы и просто так заменять его не будут.

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

ARK>Берегись, сишарп! Скоро тебе конец. Ведь у тебя нет выражений, а это фатально.

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

ARK>Действительно, почему люди цепляются за такое старье, как лисп? Уже давно пора эволюционировать.

Лисп отличает от C# в первую очередь открытость к изменениям, поэтому он жив(не благодаря финансовой поддержке). И да, он постоянно эволюционирует.
Причем, гораздо раньше большинства других языков. А вот "промышленные" языки плетуться в хвосте.
Кстати, интересный факт, Пол Грэм создал свой вариант лиспа на ракете, который в свою очередь лиспо-схема.

ARK>В императивном языке ВСЕ делать выражениями не нужно. Иногда бессмысленно, а иногда и вообще вредно. Присваивание не должно возвращать ничего, равно как и операторы, влияющие на поток управления (return, break, continue, yield, throw, etc.). Да и многие другие вещи тоже — циклы, объявления типов и т.д. Собственно, выражений не так уж и много на самом деле.

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

ARK>Если такое и произойдет, то точно не в обозримом будущем. В C# вложены огромные ресурсы и просто так заменять его не будут.

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

Но важнее другое:

Парадокс Блаба

Что же в Lisp'е такого прекрасного?
Если он такой замечательный, почему его не используют все?
Казалось бы, риторические вопросы, но на самом деле на них есть прямые ответы.
Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих.
И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии,
но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений.

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

AA>>Every expression is either a single value or a list.

ARK>В императивном языке ВСЕ делать выражениями не нужно. Иногда бессмысленно, а иногда и вообще вредно. Присваивание не должно возвращать ничего, равно как и операторы, влияющие на поток управления (return, break, continue, yield, throw, etc.). Да и многие другие вещи тоже — циклы, объявления типов и т.д. Собственно, выражений не так уж и много на самом деле.

В функциональщине давно придумали специальный тип (например в OCaml тип unit имеющий только одно значение ()) чтобы возвращать ничего.
Императивный rust вполне перенял и этот тип и "все есть выражение" из OCaml'а и нормально с этим существует.

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

FR>В функциональщине давно придумали специальный тип (например в OCaml тип unit имеющий только одно значение ()) чтобы возвращать ничего.

Я в курсе.

FR>Императивный rust вполне перенял и этот тип и "все есть выражение" из OCaml'а и нормально с этим существует.

В rust не всё есть выражение.

fn main() {
    let a = fn Test () {
        println!("Hello, world!");
    }
    Test();
}

2 | let a = fn () {
| ^^ expected expression

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

AA>Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих.
AA>И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии,
AA>но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений.

Тем не менее, язык Ц появился через 15 лет после появления лиспа, и мир завоевал именно он и его потомки.

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

AA>Парадокс Блаба

Гораздо интереснее парадокс парадокса Блаба — люди, который согласны с парадоксом Блаба не понимают социальных и экономических причин, стоящих за популярностью языков программирования.

Например, уверовавшему в парадокс Блаба нет смысла приводить аргументы про рынок труда. Последние лет 50 сложность задач в мейнстриме постояно снижается, а соответственно снижается и сложность языков программирования.
Еще 20 лет назад в норме для какой нибудь софтины надо было пилить механизмы по сложности сравнимые с компонентами операционки. Сейчас же основной код, который пишется, это тривиальная логика обработки юзер-инпута и натягивания стилей.
Соответсвенно востребован CSS, а в качестве ЯП общего назначения сгодится любой язык, который под силу людям без образования. Исторически сложилось, что такой язык уже есть в браузере искаропки. А вот другие языки, которые были в браузере — vbscript, Perl, Python, Rexx не прижились. Ха-ха.

С другой стороны, часть задач вне мейнстрима довольно сложные и становятся все сложнее. Но вот парадокс, здесь то работают матёрые разработчики, которые новый язык учат за день.
Какая здесь реальность ? Дома спецы балуются с Хаскелем, а на работе пилят числодробилки на С++, ML на питоне, тренируют сети или колупают клауд на джаве, от силы — на скале.

ARK>>Берегись, сишарп! Скоро тебе конец. Ведь у тебя нет выражений, а это фатально.
AA>Я и не жду что ему конец, инерция мышления заставляет человечество топтаться на месте.

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

В действительно используемых языках (те же Java/C#) приходится считаться с наследием: от дизайнов VM/байткода/JIT'а/да чего угодно, на что может быть завязано очень многое, до каких-нибудь вполне прагматичных вещей типа «да нахер никому не сдались ваши liquid types и lenses в реальном мире».

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

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


FR>>Императивный rust вполне перенял и этот тип и "все есть выражение" из OCaml'а и нормально с этим существует.

ARK>В rust не всё есть выражение.

Все с небольшими исключениями (например циклы кроме loop и тот же fn или let) и синтаксическими
заморочками. Это и в функциональщине также, в том же OCaml это

let f = let f x =  x + 1;;

тоже будет ошибкой.
Ну и в том же rust функция вполне значение:

fn main() {
    let a = {
        fn test() {
            println!("Hello, world!");
        };
        test
    };
    a();
}

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

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


FR>>>Императивный rust вполне перенял и этот тип и "все есть выражение" из OCaml'а и нормально с этим существует.

ARK>>В rust не всё есть выражение.

FR>Все с небольшими исключениями (например циклы кроме loop и тот же fn или let) и синтаксическими
FR>заморочками. Это и в функциональщине также, в том же OCaml это
FR>

FR>let f = let f x =  x + 1;;
FR>

FR>тоже будет ошибкой.
FR>Ну и в том же rust функция вполне значение:
FR>

FR>fn main() {
FR>    let a = {
FR>        fn test() {
FR>            println!("Hello, world!");
FR>        };
FR>        test
FR>    };
FR>    a();
FR>} 
FR>

Непривычно, а так можно:

(fun x -> printfn "%s" x) "hello"

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

FR>Все с небольшими исключениями (например циклы кроме loop и тот же fn или let) и синтаксическими
FR>заморочками.

А также объявлений типов, модулей и много чего еще. В общем, "всё есть выражение" это преувеличение, ИМХО.

FR>Ну и в том же rust функция вполне значение:

А как выразить тип "функция с любым входом и/или любым выходом"?

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

AA>Непривычно, а так можно:
AA>

AA>(fun x -> printfn "%s" x) "hello"
AA>

Это уже лямбда, для rust будет так же:

(|s| println!("{}", s))("hello");

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

ARK>А также объявлений типов, модулей и много чего еще. В общем, "всё есть выражение" это преувеличение, ИМХО.

Ну это же для блоков кода имеется в виду. "Все есть объект" тоже даже для Smalltalk не верно
если так рассматривать.
Хотя модули в том же OCaml (и других ML) тоже первоклассные сущности, их можно например
параметризовать https://dev.realworldocaml.org/first-class-modules.html
rust это не перенял, но некоторые забавные вещи оттуда все-равно перешли, например
модуль вложенный в функцию :

 
fn tst() -> i32 {
    mod tst {
        pub fn id() -> i32 {123}
    };
    tst::id()
}    

fn main() {   
    println!("{}", tst());
}

FR>>Ну и в том же rust функция вполне значение:

ARK>А как выразить тип "функция с любым входом и/или любым выходом"?

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

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

ARK>>А также объявлений типов, модулей и много чего еще. В общем, "всё есть выражение" это преувеличение, ИМХО.
FR>Ну это же для блоков кода имеется в виду. "Все есть объект" тоже даже для Smalltalk не верно
FR>если так рассматривать.

Ну а почему собственно, скажем, объявление типа не может быть блоком кода? Вопрос риторический. Вполне даже может. Просто в rust это не так.

FR>rust это не перенял, но некоторые забавные вещи оттуда все-равно перешли, например
FR>модуль вложенный в функцию

Маразм, ИМХО.

ARK>>А как выразить тип "функция с любым входом и/или любым выходом"?
FR>А такое выражается хоть в каком-то строго статически типизированном языке,
FR>без применения средств макропрограммирования, только типами?

Хрен знает, может в Scala есть, хотя не уверен.

FR>Хотелось бы посмотреть пример, и как можно использовать.

Даже если использовать никак нельзя, возможность такая должна быть. Должны быть top type и bottom type для функций. Иначе функция не будет полноценным значением (и в rust это именно так).

Хотя и использовать можно — в качестве генерик констраинтов. "Любая функция, возвращающая целое число и принимающая некое T, где T — генерик-параметр типа кортеж".

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

FR>А такое выражается хоть в каком-то строго статически типизированном языке,
FR>без применения средств макропрограммирования, только типами?
FR>Хотелось бы посмотреть пример, и как можно использовать.

const f:(a:any)=>any = (a:string) => 5

Используй как хочешь

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

I>

I>const f:(a:any)=>any = (a:string) => 5
I>

Увы, это не "любая функция". У "любой функции" (top) вход должен быть максимально узким, а выход — максимально широким. А у "никакой функции" (bottom) наоборот — вход самый широкий, а выход самый узкий. Кроме того, количество аргументов должно быть произвольным, как минимум на входе (а если язык поддерживает множественные выходные аргументы — то и на выходе тоже).

UPD. Ах да, изначально я сказал не про "любую функцию", а про "функцию с любым входом и/или выходом", что, конечно, не одно и то же (хотя в голове я имел в виду именно первый вариант). Но возражение про количество аргументов все равно остается в силе.

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

I>>

I>>const f:(a:any)=>any = (a:string) => 5
I>>

ARK>Увы, это не "любая функция".

Разумеется. Это, как и запрашивалось, "функция с любым входом и/или любым выходом". Туда можно передать хоть что угодно, хоть ничего, и получить хоть что угодно, хоть ничего.

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

ARK>>Увы, это не "любая функция".

I>Разумеется. Это, как и запрашивалось, "функция с любым входом и/или любым выходом". Туда можно передать хоть что угодно, хоть ничего, и получить хоть что угодно, хоть ничего.

Да, я сам уже заметил свою ошибку и поправился (см. апдейт поста). Но здесь таки не любой вход — здесь ровно один аргумент. Я не прав?

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

ARK>Да, я сам уже заметил свою ошибку и поправился (см. апдейт поста). Но здесь таки не любой вход — здесь ровно один аргумент. Я не прав?

const f:(...a:any[])=>any = (a:string) => 5

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

I>

I>const f:(...a:any[])=>any = (a:string) => 5
I>

Да, так лучше. А "любую функцию" можно?