LINUX.ORG.RU

Nim 0.10.2  — статически типизированный, императивный язык программирования.

 ,


0

4

Nim (ранее Nimrod) — статически типизированный, императивный язык программирования.
В этом релизе произошла смена названия языка с Nimrod на Nim. Эта версия ломает обратную совместимость с прошлыми версиями, для поиска и обновления проекта предоставлена специальная утилита — nimfix.
Одна из целей Nim это реализация эффективного компилятора: на последних сравнениях скорости, можно увидеть, что код на Nim такой же быстрый как код на C или C++.
Последние введения, как asyncdispatch модуль, позволяет написать эффективные веб-приложения используя неблокирующий код. Также Nim имеет встроенные пул тредов для легковесных потоков с использованием `spawn`.
Удалены непопулярные префиксы для типов — «T» и «P».
Обновлены форум, сайт, и генератор документации.
Важные изменения, которые ломают обратную совместимость

  • комментарии больше не часть AST.
  • рекурсивные кортежи запрещены, вместо этого предлагается использовать object
  • новые ключевые слова — defer, func
  • using нужно включать явно с помощью прагмы {.experimental.}
  • ключевые слова except, finally объявлены устаревшими. Вместо них нужно использовать defer и try.
  • поля в кортежах сейчас игнорируются для сравнения.

Некоторые изменения в языке

  • новая конкурентная модель (lock секции, lock уровни и guards поля)
  • parallel оператор
  • deepCopy
  • встроенный procCall может использоваться для вызова методов родителя
  • прагма {.experimental.} которая добавляет нововведения для модуля, или можно включить это глобально с передачей аргумента --experimental


В компиляторе

  • поддержка смешанного Objective C / C++ / C генерации, модули которые используют importCpp или importObjc компилируются в Objective C или C++, остальные модули компилируются в C.
  • parallel оператор, для fork/join модели выполнения
  • lock и guard прагмы для безопасной конкурентной работы
  • больше методов, которые доступны во время компиляции


В библиотеках

  • fenv модуль для контроля выполнения операций с чисел с плавающей точкой и контроля за исключениями — переполнение, деление на ноль
  • asyncnet добавлена поддержка SSL
  • добавлена osproc.kill

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

anonymous

Проверено: Shaman007 ()

Классы как в паскале. Почему???

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

что в нём сломали после 0.8.8 ?

Версия 0.8.8 успешно компилировалась с помощью tcc, и после этого работала. Нынешний компилируется, но уже не работает.

PS: Генерируемые исходники самого nim не должны включать ничего кроме nimbase.h (никаких string.h и тп.) А то при попытке использовать другой компилятор (отладка) приходится править все сишные исходники.

PPS: скомпилированный с помощью tcc компилятор nim ведёт себя (ход вызовов процедур) не так, как скомпилированный с помощью gcc. Почему — понять не смог. У tcc отладочная информация генерируется плохо; локальные переменные в debug отсутствуют, временами не понятно, какая процедура в данный момент выполняется.

PPPS: пытаюсь довести tcc до возможности скомпилировать linux 2.4.37 (без изменения исходников). Версия 2.4.26 компилируется и работает, но её не могут собрать современные gcc

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

Классы как в паскале

Сначала был написан на FPC (до 0.9). Потом pascal-исходники перестали поддерживать. Поэтому — subj есть неисжитое наследие. Однако для меня классы в нём как в go :-)

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

чувак я не понимаю почему тебя до сих пор не забанили за тупость.

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

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

основные аргументы против лиспа все еще связаны с отсутствием синтаксиса

И не надейся. Синтаксис это самая незначительная из претензий к скобкоте. У скобкоты и кроме отсутствия человеческого синтаксиса полно проблем: дебильная (динамическая, но при этом не утиная) система типов, наличие макросов (привет, грязные хаки, давно забаненные в мире сишечки), отсутствие приличного стандарта (зоопарк из говна), бардак с модулями и неймспейсами, отсутствие приличных IDE, отсутствие библиотек, отсутствие разделения на expressions и statements, бардак с раздельной компиляцией (некоторые схемки в нее умеют, но у них свои закидоны).

Если вдруг завтра появится лишпик с человеческим синтаксисом, например, воскресят R-Lisp или еще что подобное, говном лишпик быть не перестанет ни на секунду.

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

на том основании, что у них синтаксис похож.

Семантика всех Виртовских языков весьма похожа, различия незначительны. А не-Виртовские языки не заслуживают никакого внимания.

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

Не синтаксис, а идеи.

Какие такие идеи?var x : int = 3;Вроде nim а вроде и pascal. Ну да, в паскале нету let, ну так он нахрен не нужен. В паскале нету fallthrough в case, тут его тоже нету. Зато в паскале не нужно писать множество of, одного вполне достаточно. Заменили begin/end отступами, это ужас. Не смог найти аналог absolute (или union в C).

A-234 ★★★★★ ()
Последнее исправление: A-234 (всего исправлений: 1)
Ответ на: комментарий от A-234

Ну да, в паскале нету let, ну так он нахрен не нужен.

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

паскале нету fallthrough в case, тут его тоже нету.

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

Зато в паскале не нужно писать множество of

Не понял, да и не помню я паскаль уже.

Заменили begin/end отступами, это ужас

Согласен, это питон постарался.

Не смог найти аналог absolute (или union в C).

Наверное его и нет.

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

Так его вроде нигде нет кроме сей и плюсов, и он нужен очень редко.

Признаюсь, я дремуч в языках в том смысле что кроме плюсов, паскаля, ассемблеров толком никаких больше языков не знаю. Поэтому возможно вы правы в том, что кроме плюсов и сей этого больше нигде нет, но fallthrough позволяет иногда писать элегантный код. Мне сложно от этого отказаться.

Отсутствие absolute весьма печально. Вроде нет никаких проблем его добавить, непонятно почему разработчики этого не делают.

Я ведь не рассуждаю зачем используется let, я просто хочу сказать что его ценность нулевая. В чем проблема написать const a : int = f(y); От каких ошибок призван защитить этот оператор?

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

const-выражения в ниме, насколько я понял, вычисляются во время компиляции, так что вероятно let тут аналог паскалевого const.

loz ★★★★★ ()
Ответ на: комментарий от A-234

Отсутствие absolute весьма печально. Вроде нет никаких проблем его добавить, непонятно почему разработчики этого не делают.

Стоит спросить на #nim, там разработчики активно общаются и делятся своими мыслями, вероятно причина есть, но мне она неизвестна.

loz ★★★★★ ()

Менюха на сайте напомнила КонтрСтрайк

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

Программирование в машинных кодах даёт абсолютную власть над миром :)

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

Сторонние библиотеки - это, на создание чего в одиночку среднестатистическому программисту понадобилось бы несколько веков усердного труда, а какому-нибудь Яндексу в полном его составе - ну, десяток лет от силы, да :)

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

DRVTiny ★★★★★ ()
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от Deleted

let это присвоение, with - scope visibility. Как вам такая мысль в голову пришла?

A-234 ★★★★★ ()

Вау, новый язык программирования!

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

да. потому, что язык машинных команд — императивен, а всё что далеко ушло от языка машинных команд — не является низким уровнем, по определению.

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

Образец высера тролля. Зачем всякую гадость сюда тащить?

A-234 ★★★★★ ()
Ответ на: комментарий от next_time

Как вы определяете «низкоуровневость»? Понятно что все парадигмы выводимы из императивной, но где критерий что «низкоуровневое» а что нет?

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

Как вы определяете «низкоуровневость»?

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

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

способно очевидным для читателя программы образом в него транслироваться

Ну это зависит от читателя, для некоторых и printf - магия. И потом, обобщенное программирование например относится к классу императивных парадигм, однако никоим образом взглянув на шаблон вы не сможете понять во что это потом скомпилируется.

отсутствие сборщика мусора

Критерий так себе. К парадигме не относится вообще. Существует в куче императивных языков.

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

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

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

Forth

tailgunner ★★★★★ ()
Ответ на: комментарий от A-234

относится к классу императивных парадигм

далеко не всякая императивщина низкоуровнева

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

в С++ это практически очевидно

К парадигме не относится вообще.

низкоуровневость — вопрос реализации, а не парадигмы. для синтаксиса ассемблера x86 можно написать компилятор, который сделает этот синтаксис высокоуровневым языком (например, транслятор асм х86->асм arm). но для некоторых парадигм невозможно в принципе написать низкоуровневый компилятор для любой платформы, использующей микроэлектронные схемы, то есть, для любой реально существующей ЭВМ.

Существует в куче императивных языков.

они все высокоуровневые

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

для форта есть компилятор на форт-машины. на тех платформах — он низкоуровневый. на х86 — это высокоуровневый язык.

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

для форта есть компилятор на форт-машины

Бгг. Какой ты всё-таки упоротый баран.

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

посмотрел. там даже указателей нет => ни о какой низкоуровневости (даже с натяжкой) для распространённых аппаратных платформ речь идти не может.

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

Не видишь противоречия в том, что функциональщиной называют императивный язык?

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

Нет, не вижу. Ибо порядок вычисления функций может также явно указываться. А вот системы Поста - декларативны.

LongLiveUbuntu ★★★★★ ()
Последнее исправление: LongLiveUbuntu (всего исправлений: 1)
Ответ на: комментарий от next_time

указателей нет

Продавай свисток

ATS has a basic pointer type called ptr. This is a non-dependent type and is the equivalent to a void* in the C programming language. It also has a dependently typed pointer type that is indexed over an addr sort (sorts are the types of type indexes) that represents the address of the pointer

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

в С++ это практически очевидно

Очевидно тут только то что вы не понимаете о чем рассуждаете.

низкоуровневость — вопрос реализации, а не парадигмы.

BINGO! Но это вы пытались привязать низкоуровневость к императивщине.

для некоторых парадигм невозможно в принципе написать низкоуровневый компилятор для любой платформы, использующей микроэлектронные схемы, то есть, для любой реально существующей ЭВМ.

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

они все высокоуровневые

Как управление ресурсами относится к уровневости языка? Ничего что для C++ есть библиотеки реализующие GC?

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

Gforth uses GCC to compile a fast direct or indirect threaded Forth.

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

tailgunner ★★★★★ ()
Ответ на: комментарий от A-234

Очевидно тут только то что вы не понимаете о чем рассуждаете.

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

в

template<class T> T func(T a, T b){
  return a*a + b*b;
}

auto x = func<int64_t>(1, 2);

весьма тупо раскроется в:

int64_t func(int64_t a, int64_t b){
  return a*a + b*b;
}

BINGO! Но это вы пытались привязать низкоуровневость к императивщине.

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

Например?

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

Ничего что для C++ есть библиотеки реализующие GC?

С/С++ — это высокоуровневые языки, их только с большой натяжкой можно назвать низкоуровневыми

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

какая разница? указатели — неотъемлемая часть низкоуровневого кода на всех архитектурах, обладающих хоть сколько-нибудь заметным объёмом памяти. отсутствие указателей не делает язык ни плохим, ни хорошим. просто, он становится высокоуровневым.

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

А при чем тут int64? Мы про шаблоны говорим. Я могу записать func<MyClass>(x,y) и ломайте голову во что это превратится.

функциональная парадигма не позволяет писать низкоуровневый код на процессорах или микроконтроллерах массового применения.

GCL позволяет но вы сомневаетесь.

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

CFFI
Пишите сколько угодно. Там сложность в другом, при одинаковых аргументах функция должна возвращать одинаковые значения. Или, другими словами, отсутствие понятия времени.
И чего вы в указатели уперлись? Я вам сейчас страшную тайну открою, в микроконтроллерах с объемом памяти в десятки килобайт код, как правило, пишется так что вся память исключительно статическая, даже стек. Это у вас гигабайты, а когда памяти 16к за malloc руки с корнем отрывают :)

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

А при чем тут int64? Мы про шаблоны говорим.

шаблоны могут с любыми типами работать, и с примитивными тоже.

Я могу записать func<MyClass>(x,y) и ломайте голову во что это превратится.

MyClass func(MyClass a, MyClass b){
  return a*a + b*b;
}

если у класса определены оператор* и оператор+ с правильной сигнатурой, то в тоже и превратится:

int64_t func(int64_t a, int64_t b){
  return a*a + b*b;
}

GCL позволяет но вы сомневаетесь.

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

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

а когда памяти 16к за malloc руки с корнем отрывают

не отрывают. там malloc обычно попросту не работает: для динамической памяти ОС нужна.

CFFI

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

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

А с чего вы взяли что мои * и + умножают и складывают? И зачем вы мне все время ваш int64 подсовываете? Может мой класс - обертка над (char*), и это вам еще крупно повезло если так.

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

Только если писать на ассемблере. Для плюсов достаточно ссылок. Память ведь статическая.

для динамической памяти ОС нужна.

Я тут чаем поперхнулся, нельзя же так. В биосах, по-вашему, malloc'и не работают? Не сомневайтесь, работают еще как.

а там тот же ассемблер, только со скобочками

Да при чем тут ассемблер? pointers in lisp

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