Causality Ltd прекратила свою деятельность

Долой это говно с лора

А какой смысл тащить всюду сишный синтаксис? Просто потому что кому-то там привычно?

Да

ЗЫ если экстраполировать альт, то 9 ветка выйдет тогда, когда вполне себе может идти 2 деятилетие 21 века. Если выйдет

Так оно и так идёт с 1 января 2010 года. Так что выпустим, можете не сомневаться.

Потому что 90% либ, это либо сишные либы, либо биндинги к ним.

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

All local variable names start with a lower case letter. If you want to you can end them with a prime ' (or more than one) which is useful when you need a second variable with almost the same meaning as the first. For example you might have one variable called time and another called time'.

какой приятный сахарок...

Полужив? Или полумёртв?

Полужив? Или полумёртв?

Ни то, ни другое.

какой приятный сахарок...

Это с Хаскеля в народ пошло...

Что только народ не выдумывает, лишь бы язык был не как у моск^w в C++.

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

Они поменьше символ препинания не могли найти, чтоб его еще хуже было видно?

Эта нотация старше C++. А у тебя какая-то плюсовая травма, если тебя почитать.

Ненене. В хаскеле функциональщина. Там без штрихов никуда, ведь переменных по сути нет, одни константы.

А тут обычная императивщина.

Ты же троллишь, да? И вообще, при чем тут сахар?

И вообще, при чем тут сахар?

Вот и выросло поколение, не читавшего Абельсона и Сассмана и не знающего про синтаксический сахар.

А точно-ли переменная-штрих имеет хоть какое-то отношение к синтаксическрму сахару?

«Не было в сишке — значит сахар.»

ведь переменных по сути нет, одни константы

...

The following three rules give an inductive definition that can be applied to build all syntactically valid lambda terms:

a variable, x, is itself a valid lambda term

...

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

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

Ставить едва заметные черточки после имени переменной это видимо такое же наследие.

Мне кажется что под сахаром они имеют ввиду меньшую порцию соли, причем калиевой

Я же говорю, _по сути_.

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

Да нисколько.

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

Тебя ткнули в определение, где чёрным по белому написано «переменная». В математике у функций аргументы тоже почему-то называются переменными, хотя они и иммутабельны.

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

Вот вас уже и двое, видящих связь между правилами построения идентификаторов и синтаксисом.

Я тебе помогу: если нужна производная от x - в любом языке ты сможешь использовать x1, x2,..., и это принципиально не будет отличаться от x', x",...

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

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

Ты реально начинаешь раздражать.

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

В хаскеле константы называют переменными. В итоге у нас теперь есть переменная Pi=3.14

Именно поэтому в Haskell определена переменная под названием pi, которая содержит в себе более дюжины цифр из записи числа pi:

 ghci> pi
 3.141592653589793
 ghci> pi * 5^2
 78.53981633974483

Другими словами, как переменная pi, так и её значение 3.141592653589793 одинаково успешно могут быть использованы в вычисленииях, они взаимозаменяемы.

Переменная Pi. Зашибись... А в pony императивщина в полный рост. Здесь есть как переменные (var) которые можно менять сколько хочешь, так и константы (let), которые не меняются.

Я тебе помогу: если нужна производная от x - в любом языке ты сможешь использовать x1, x2,..., и это принципиально не будет отличаться от x', x",...

X1, X2... принципиально отличаются, поскольку обозначают разные переменные, например, абсциссы в двух точек. А X1' это та же X1 только в другом, производном контексте.

Например, X1, это абсцисса отноcительно центра земли, а X1' - абсцисса этого же объекта, только с центром координат в солнце.

Проще говоря, в программах используется и то и другое.

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

Код на Haskell:

f x = x

Может ли меняться значение x? Если нет (т.е. x — константа), то чему оно равно её значение? В какой области памяти будет находиться x?

Другой код:

pi = 3.1415926

Всё те же вопросы.

Лол, сколько философии можно извлечь из простейшей особенности токенизатора.

Ни при чем. Где то всплыл. Он всегда всплывает в таких темах

Для таких задач Бог дал людям структуры и классы. Но некоторые не приняли Его дары а исповедуют ереси вроде штрихов после имени переменной.

Я конечно не spj, но x, x1 и x' с т. з. языка - это просто три разные переменные. Разница о которой ты говоришь есть только на уровне общепринятых соглашений. Они может быть и удобны, но синтаксическим сахаром точно не являются. Лексический сахар - уже ближе :D Но всё равно не то.

Для таких задач Бог дал людям структуры и классы. Но некоторые не приняли Его дары а исповедуют ереси вроде штрихов после имени переменной.

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

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

Может ли меняться значение x? Если нет (т.е. x — константа), то чему оно равно её значение? В какой области памяти будет находиться x?

Обычное рекурсивное определение. В чем проблема?

Само слово иммутабельно, это значит, неизменное. Неизменная переменная, это константа.

pi = 3.1415926

для pony этот код звучал бы так

let pi = 3.1415926

В обоих случаях если в последующем компилятор увидит

pi = 3

то будет ругаться.

Правда в терминах хаскеля это будет множественное определение ибо нет у функциональщины сначала и потом. А в пони это будет изменение константы ибо императивщина следует за листингом программы, но в целом это одно и тоже.

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

Обычное рекурсивное определение

Начнём с того, что здесь нет никакой рекурсии. Вообще. Ты даже малейшего понятия не имеешь о языке, о котором рассуждаешь. Да и, судя по неспособности распознать identity function, будет безопасно предположить, что и вообще о программировании в целом.

Так что ты идеально сможешь ответить на мой изначальный вопрос: зачем балаболки упорствуют в своём невежестве?

Я конечно не spj, но x, x1 и x' с т. з. языка - это просто три разные переменные. Разница о которой ты говоришь есть только на уровне общепринятых соглашений. Они может быть и удобны, но синтаксическим сахаром точно не являются. Лексический сахар - уже ближе :D Но всё равно не то.

Блин, откуда вы такие пустые формализмы вытаскиваете? Да любой сахар, это уровень общепринятых соглашений! И да, он может быть удобен. Но эти соглашения или принимаются авторами компилятора или нет. Вот пример:

Баш.

[home@tvcomp ~]$ PI=1; echo $PI
1
[home@tvcomp ~]$ PI'=1; echo $PI'
bash: PI=1; echo $PI: команда не найдена

Питон

python
Python 2.7.11 (default, Mar 31 2016, 20:46:51) 
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> PI'=1
  File "<stdin>", line 1
    PI'=1
        ^
SyntaxError: EOL while scanning string literal
>>> 

Типа, среди нас, хьюманов, соглашение есть, а код не работает!

Сахарок бывает разный.

Например, в разделе сахара в пони написано, что если у вас есть класс Myclass и для него определен метод .apply(X) то можно писать

Myclass.apply(x)

а можно писать просто Myclass(x) и это будет тоже самое.

А если определен метод _add(X) то для эксземаляров этого класса можно писать x._add(Y) или просто X + Y

И это тоже сахар, и это тоже всего навсего общепринятые соглашения!

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

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

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

Тебя уже забанили. Даже не удивлен.

Тащем-та у синтаксического сахара есть определение, и понипримеры под него подходят, а штрихи нет. И соглашения к нему также отношения не имеют.

А вообще пофиг, считаешь это пустыми формализмами - предмета спора нет.

Да я просто в упор не вижу разницы. Кстати, из двух пони-примеров, к сахару относят только один. Пример с плюсиком они сахаром не считают, да и ладно.

Синтаксический сахар означает форму, которая синт. преобразованием сводится к другой форме, обычно более общей. Пони не знаю, а например в C++ range-based for превращается в c-style for. Это может сделать парсер. И это тот самый сахар.

Во что превращать x'? Это вообще не синт. форма, разве что вырожденная.

Почитал учебник. Учебник выглядит неплохо.

Попытался построить рпм. При этом выяснил, что «make install» как-то весьма нестандартно интепретирует prefix и destdir. Кое-как поборол это.

Далее оказалось, что «make install» создаёт вот такие каталоги: «/usr/bin», «/usr/lib», «/usr/packages». Первые два — норм, но третий — нонсенс. В /usr/packages лежат, похоже, исходники стандартной библиотеки. Поскольку это исходники, передвинул их в каталог «/usr/share/ponyc/packages», после чего компилятор (ожидаемо) не нашёл их.

Залез в исходники компилятора, чтобы поправить… М-да… Взяли путь к компилятору, отрезали от него имя компилятора, потом дописали туда "../packages"… А кто будет проверять что для этого "../packages" в буфере есть место? Короче, переполнение буфера. Конечно, в обычных условиях нормальные пользователи не используют пути длинной под 4k, но как же быть с принципом «No crashes»? Или к самому компилятору этот принцип не применяется?

А как парни открывают файл с исходником?

  FILE* fp = fopen(file, "rb");

  if(fp == NULL)
  {
    *error_msgp = "can't open file";
    return NULL;
  }

Они выдают по любому случаю «can't open file». А как же принцип «Sensible error messages»? Имхо, без (желательно, расшифрованного) errno сообщение об ошибке не может быть «sensible».

Ладно, собрал, установил. Попробовал скомпилировать первый же пример из учебника:

$ cat hello.pony
actor Main
    new create( env : Env ) =>
        env.out.print( "Hello, world!" )

$ ponyc .
...
Segmentation fault (core dumped)

Упс. С одной стороны это не релиз (который на F24 не собирается) а HEAD из master… Но всё равно упс.

Что-то дальше испытывать поню расхотелось. Им надо было компилятор не на си, а на пони писать…

Так они пони не продадут...

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

Брр… Возьмём forth, язык ещё более «диетический» чем lisp. Без сахара, в смысле — переносимый расширяемый ассемблер as is. Хотя слова с флагом immediate, выполняемые во время компиляции, местный аналог лисп-макросов, и позволяют «сахарок» организавать. Но речь не о них. А о том, что форт-слово может означаться любым идентификатором, не содержащим пробельных символов. С апострофом в том числе. Чем фортеры активно пользуются. «Сладко»?

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

Вот-вот. В Алголе-68, кстати, идея синтаксического сахара уже активно использовалась, хотя, кажется, сам термин в «полуофициальных» и официальных описаниях языка не использовался.

Неа. Ты подменяешь смысл формой.

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

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

Штрих в конце имени переменной, это чистой воды сахарок от математика к вашему столу...

Да, в этой части вполне может быть и сладко.

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

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

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

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

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

Сказал бы сразу, что у тебя собственная терминология. Сберегли бы время.

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