Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

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

KK>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

Нельзя макросы использовать в своей сборке.

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

KK>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

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

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

KK>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

А меня раздражает когда код без отбивок пишут.

Что касается самого языка, то больше всего раздражает тормоза компилятора.

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

KK>>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

C>Нельзя макросы использовать в своей сборке.

Ну, дык не лисп. Статическая типизация диктует свои условия.

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

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

KK>>>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

C>>Нельзя макросы использовать в своей сборке.

VD>Ну, дык не лисп. Статическая типизация диктует свои условия.

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

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

KK>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1
Супер! И это язык программирования, претендующий на убийцу всех других языков вместе взятых?

Я в свое время с удовольствием прочитал все статьи Влада, они помогли мне "въехать" в ФП. В Nemerle не нравится несколько "неупорядоченный" синтаксис (или отсутствие документации по синтаксису?).
Нет единого списка ключевых слов, операторов и т.д.
К примеру, в выражениях nemerle часто используется символ подчеркивания. А формально это что? Оператор, ключевое слово?
Не нравится отход от стандартного си-подобного синтаксиса во многих местах. Все то же самое можно было сделать более "си-подобным" чисто внешне. В частности, использование оператора "|" в match.
Возможно, пишу глупость, но вот такие мелочи почему-то портят впечатление.

Здравствуйте, Аноним, Вы писали:

А>Я в свое время с удовольствием прочитал все статьи Влада, они помогли мне "въехать" в ФП. В Nemerle не нравится несколько "неупорядоченный" синтаксис (или отсутствие документации по синтаксису?).
А>Нет единого списка ключевых слов, операторов и т.д.

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

А>К примеру, в выражениях nemerle часто используется символ подчеркивания. А формально это что? Оператор, ключевое слово?

Это скорее слово ключевое нежели идентификатор, как правило, оно символизирует используется как "универсальный шаблон" (т.е. совместимый с любым другим — else, иначе говоря) либо "пропущенный идентификатор".

А>Не нравится отход от стандартного си-подобного синтаксиса во многих местах. Все то же самое можно было сделать более "си-подобным" чисто внешне. В частности, использование оператора "|" в match.

И как же можно сделать вхождение match Си-подобным, учитывая тот факт, что в Си аналогичной конструкции нет от рождения?

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

Взгляни на match в Scala или F#.

Здравствуйте, Аноним, Вы писали:

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

KK>>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1
А>Супер! И это язык программирования, претендующий на убийцу всех других языков вместе взятых?

Недостаток неприятный, но не смертельный. Было бы неплохо выводить более врзаумительное сообщение об ошибке: оператор не найден — возможно вы забыли поставить прбел между = и -.

Здравствуйте, Аноним, Вы писали:

Во-первый, чего шифруешся. Здесь за критику (если она не переходит в разряд срача) не банят и на критикующих не обижаются.

А>Я в свое время с удовольствием прочитал все статьи Влада, они помогли мне "въехать" в ФП. В Nemerle не нравится несколько "неупорядоченный" синтаксис (или отсутствие документации по синтаксису?).

Как-то странно. С одной стороны статьи помогли разобраться аж ФП, а не только языке. Но с другой недостаточно документации. Я вот C# изучал вообще на практике (ничего не читал), С++ по книжке. Спецификации увидел только потом. Та же спецификация C# мне понадобилась только когда я собрался писать его парсер.

А>Нет единого списка ключевых слов, операторов и т.д.

http://nemerle.org/Reference_Manual
далее по ссылкам.

Проблема (проблема ли?) в том, что операторов и ключевых слов в самом языке очень мало.
Большая их часть вводится макросами, которые (не полностью, но все же) описаны в разделе Macro packages.

А>К примеру, в выражениях nemerle часто используется символ подчеркивания. А формально это что? Оператор, ключевое слово?

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

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

А>Не нравится отход от стандартного си-подобного синтаксиса во многих местах.

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

А>Все то же самое можно было сделать более "си-подобным" чисто внешне. В частности, использование оператора "|" в match.

Сам match — это конструкция из ML-подобных языков. В ML-подобных языках он зародился и сформировался. Удобство его использования обуславливается рядом факторов, одним из которых является краткость синтаксиса. Если бы нам пришлось в каждом вхождении писать case ... breack, то код стал бы сильно грязнее.

Опять же опыт использования match более трех месяцев обычно меняет отношение к нему.

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

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

Лично я, всзглянув на язык могу сказать, что не по делу пожалу только [] в синтаксисе параметров типов. В принципе можно было бы отставить и <>. Возможно во второй версии мы сделаем возможность использования <> вместо [] при описании типов. Но пока что это плата за гибкость.

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

Парсер следующей версии немерла будет основан на PEG, который (потенциально) позволит отличать операторы и без пробелов. Но не уверен, что мы будем изменять традициям, так как это совершенно надуманная проблема.

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

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

H>Взгляни на match в Scala или F#.

В Скале используется ключевое слово case, правда без Сишного синтаксиса (с совсем другим синтаксисом).

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

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

H>>Взгляни на match в Scala или F#.

VD>В Скале используется ключевое слово case, правда без Сишного синтаксиса (с совсем другим синтаксисом).

О чем и речь. Это же охренеть можно, от частоты его использования.

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

VD>Парсер следующей версии немерла будет основан на PEG, который (потенциально) позволит отличать операторы и без пробелов. Но не уверен, что мы будем изменять традициям, так как это совершенно надуманная проблема.

VD>Если главной проблемой немерла является невозможность слитного написания унарного минуса с бинарными операторами, то Немерл и правда идельный язык .

Согласен, что проблема незначительная. Это как if(x=0) в С++. Один(несколько) раз споткнувшись, дальше не попадаешься. Можно только сделать сообщение об ошибке более "релевантным": а не забыли ли вы пробел поставить?

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

KK>Недостаток неприятный, но не смертельный. Было бы неплохо выводить более врзаумительное сообщение об ошибке: оператор не найден — возможно вы забыли поставить прбел между = и -.

Так надо было сказать о том, что что-то не так.

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

Если бы был соотвествющий баг-репорт, то давно бы поправили. Там делов то на 10 минут.

PS

Как сказать "отбить оператор пробелом"? Т.е. как правильно перевести слово "отбить"?

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

VD>PS

VD>Как сказать "отбить оператор пробелом"? Т.е. как правильно перевести слово "отбить"?

surround with spaces

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

KK>Недостаток неприятный, но не смертельный. Было бы неплохо выводить более врзаумительное сообщение об ошибке: оператор не найден — возможно вы забыли поставить прбел между = и -.

Нет, я все понимаю, но вот такое... Лексический анализатор, который сканирует входной поток и выдает "лексемы", выкидывая при этом пробелы, комментарии и переносы строк, пишется студентом 1 курса за один вечер (а профессиональным программистом — за пару часов со всей отладкой и тестированием) на любом языке прогораммирования. Никаких специальных знаний для этого не нужно вообще...
Nemerle особенный?
Это даже несерьезно, язык-то действительно интересный. Даже обидно стало за Nemerle, несмотря на то что я к нему никакого отношения не имею

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

KK>Согласен, что проблема незначительная. Это как if(x=0) в С++.

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

KK>Один(несколько) раз споткнувшись, дальше не попадаешься. Можно только сделать сообщение об ошибке более "релевантным": а не забыли ли вы пробел поставить?

Надо было баг-репорт добавить, и сделали бы.

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

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

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

KK>>Недостаток неприятный, но не смертельный. Было бы неплохо выводить более врзаумительное сообщение об ошибке: оператор не найден — возможно вы забыли поставить прбел между = и -.

VD>Так надо было сказать о том, что что-то не так.

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

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

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

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

KK>>Недостаток неприятный, но не смертельный. Было бы неплохо выводить более врзаумительное сообщение об ошибке: оператор не найден — возможно вы забыли поставить прбел между = и -.

XC>Нет, я все понимаю, но вот такое... Лексический анализатор, который сканирует входной поток и выдает "лексемы", выкидывая при этом пробелы, комментарии и переносы строк, пишется студентом 1 курса за один вечер (а профессиональным программистом — за пару часов со всей отладкой и тестированием) на любом языке прогораммирования. Никаких специальных знаний для этого не нужно вообще...
XC>Nemerle особенный?

Угу. В нем можно ввести произвольную операторную абракадабру. Посему все операторные нецифробуквенные символы (кроме скобок) склеиваются в один токен, для которого Немерл пытается найти обработчик. В принципе добавить интеллекту поисковику можно, да только никому в голову не приходило — постоянные пользователи языка этой проблемы просто не замечают.

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

XC>Нет, я все понимаю, но вот такое...

Видимо не совсем все.

XC> Лексический анализатор, который сканирует входной поток и выдает "лексемы", выкидывая при этом пробелы, комментарии и переносы строк, пишется студентом 1 курса за один вечер (а профессиональным программистом — за пару часов со всей отладкой и тестированием) на любом языке прогораммирования. Никаких специальных знаний для этого не нужно вообще...

Извиняюсь за уход от темы, но наболело.
Я бы этих студентов (в простонародье — мудаков) на пушочный выстрел не подпускал бы к написание лексических анализаторов, потому как выкидывание комментариев и т.п. — это форменное вредительство! Благодаря польским студентам выкинувшим все что можно, рабта над интеграцией была сильно осложнена.

XC>Nemerle особенный?

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

Посему его лексический анализатор (который, правда, сильно сложнее чем те что пишут студенты) распознает операторы по следующему паттерну.
1. Если символ принадлежит к числу операторных, то начать его распознавание.
2. Продолжать распознавание оператора до окончания последовательно идущих операторных символов.

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

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

XC>Это даже несерьезно, язык-то действительно интересный. Даже обидно стало за Nemerle, несмотря на то что я к нему никакого отношения не имею

Несерьезно — это высказывать мнение не разобравшись в сути дела.

XC>Нет, я все понимаю, но вот такое... Лексический анализатор, который сканирует входной поток и выдает "лексемы", выкидывая при этом пробелы, комментарии и переносы строк, пишется студентом 1 курса за один вечер (а профессиональным программистом — за пару часов со всей отладкой и тестированием) на любом языке прогораммирования. Никаких специальных знаний для этого не нужно вообще...
XC>Nemerle особенный?
XC>Это даже несерьезно, язык-то действительно интересный. Даже обидно стало за Nemerle, несмотря на то что я к нему никакого отношения не имею

Слышал звон..

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

KK>Неужели я один не отбиваю операторы пробелами.

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

KK>Просто так код компактнее получается.

А кому нужна такая компактность? Все нужна читаемость. Если код компактен, но на его чтение нужно тратить больше времени и сил, то такая компактность не нужна, точнее вредна.

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

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

В математике список операторов жестко ограничен. Там нет составных операторов. И то что они не отделяются — это не совсем так. Пакеты верстки формул вроде эквэйшона делают отступы автоматически (только не такими большими как пробелы).
А то можно пойти и дальше. Сделать все переменные однобуквенными и писать их при умножении без отступов. А что? Ведь можно же их отделить если как-следует приглядеться.

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

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

KK>Неужели я один не отбиваю операторы пробелами. Просто так код компактнее получается. В математической верстке, например, операторы пробелами не отбиваются, и ничего вроде все понимают. Там есть промежуток конечно, но назвать это полноценным пробелом язык не поворачивается.

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

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

KK>>Просто так код компактнее получается.
VD>А кому нужна такая компактность? Все нужна читаемость. Если код компактен, но на его чтение нужно тратить больше времени и сил, то такая компактность не нужна, точнее вредна.

Интересно, куда бы ты послал Хейльсберга, если бы он начал учить тебя жить?

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

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

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

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

Собственно разнесение макросов и прикладного кода в разные сборки и решает озвученную выше проблему.

H>Например введя некоторую директиву в файле, где он объявлен. Файлы с такой директивой компилировать во временную сборку и потом использовать при билде остальных исходников.

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

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

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

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

IT>Интересно, куда бы ты послал Хейльсберга, если бы он начал учить тебя жить?

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

В общем, лучшее соглашение — это стандарт языка.

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

IT>>Интересно, куда бы ты послал Хейльсберга, если бы он начал учить тебя жить?
VD>Он и так учит. И надо признать чрезмерно. Только его учения они в другой сфере.

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

VD>Я был бы только "за", если бы язык оределял не только необходимость задания отступов между операторами, но и даже если бы он заставлял отбивать код и расставлять скобки в одном ключе.

Я был бы только "против".

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

Это не должно быть заботой разработчика инструмента.

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

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

1. Делегаты.
2. Отсутсвие member_of().
3. Кривая перегрузка.

Короче, если постараться, можно пунктов 20 составить. И на все был отбрех (от писем в Сан и МС, до блогов).

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

VD>>Я был бы только "за", если бы язык оределял не только необходимость задания отступов между операторами, но и даже если бы он заставлял отбивать код и расставлять скобки в одном ключе.

IT>Я был бы только "против".

Мне по барабану.

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

IT>Это не должно быть заботой разработчика инструмента.

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

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

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

Считаешь текущее поведение компилятор косяком?

Логин в репозиторий у тебя есть.
Займись, устрани этот "косяк". Покажи всем как надо работать!

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

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

IT>>Не припомню, чтобы он косяки компилятора сопровождал разглагольствованиями о правильном стиле программирования.
VD>Считаешь текущее поведение компилятор косяком?

Считаю.

VD>Логин в репозиторий у тебя есть.
VD>Займись, устрани этот "косяк". Покажи всем как надо работать!

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

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

T>Ну так это совсем другой разговор. Так и скажи: косяк, возьми и исправь сам.

Нет никакого косяка. Просто кому-то хочется языком почесать.

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

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

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

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

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

Все кому не нравится эта фича могут продолжать использовать язык без этого "косяка" — C# и тешить свое самолюбие тем, что хотя они и используют значительно менее мощный язык, но зато в нем можно писать a=-1.
В немерле же так писать нельзя просто потому, что завтра кто-то может ввести оператор "=-".

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

KK>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

Это так во всех языках в которых можно определять пользовательские нестандартные операторы:

Ocaml:

# let a=-1;;
Characters 5-7:
  let a=-1;;
       ^^
Error: Parse error: [fun_binding] expected after [ipatt] (in [let_binding])

F#:

> let a=-1;;

  let a=-1;;
  -----^^

stdin(1,6): error FS0010: Unexpected infix operator in pattern

Haskell:

Prelude> let a=-1

<interactive>:1:8: parse error (possibly incorrect indentation)

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

KK>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

Что касается сообщений об ошибках.

На такую конструкцию выдается сообщение об ошибке следующего вида:

Error: typing fails on finding the operator =-(?, int)

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

На такой код:

def s=-1;

Выдается следующее сообщение:

Error: parse error near operator '=-': expecting 'def x = expr' or 'def f () { .. }'

Что так же, на мой взгляд весьма информативно.

Единственная проблема была на код:

mutable s=-1;

Исправил это дело. Теперь будет сообщать:

Error: Unexpected operator or function call. '=-'. Maybe you forgot to separate the operator by space?

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

FR>Это так во всех языках в которых можно определять пользовательские нестандартные операторы:

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

Ну пробелы меня точно не напрягают
Не особо нравилось что в некоторых местах Tab делал отступ 2 а в некоторых 4, но сейчас не замечаю.
Впринципе есть более серьёзные огорчения как
* тормоза при работе в больших функциях
* поддержка web site , wpf ну и 2010 студии
Но огорчает не столько их отсутствие, сколько ощущение того, что это явно будет не скоро.

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

Э> * тормоза при работе в больших функциях
Ну тут либо вывод типов отключить либо тормоза интелисенса в больших функциях.
Есть еще варинт полностью переписать алгоритм вывода типов но для этого нужен настоящий герой.

Э> * поддержка web site , wpf ну и 2010 студии
Э>Но огорчает не столько их отсутствие, сколько ощущение того, что это явно будет не скоро.
Критичность поддержки 2010 студии лично для меня весьма сомнительна. Ибо и 2008 не плохо работает. Но когда разгребем более приоритетные задачи это конечно будет.
А что касается остального то единственный способ ускорить появление это сделать самому.

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

Э>> * тормоза при работе в больших функциях
WH>Ну тут либо вывод типов отключить либо тормоза интелисенса в больших функциях.

В мелких работает более чем приемлемо. В приципе это даже полезно. Останавливает от создания монстров.

WH>Есть еще варинт полностью переписать алгоритм вывода типов но для этого нужен настоящий герой.

Это по любому нужно начинать с того, чтобы рефакторить компилятора, переписывать компилятора на работу с CCI и т.п.

WH>Критичность поддержки 2010 студии лично для меня весьма сомнительна. Ибо и 2008 не плохо работает. Но когда разгребем более приоритетные задачи это конечно будет.

На 2010 переходить конечно надо. Просто такой переход или будет означат полный отказ от 2.0-3.5 фрэймворков, так как на SRE их тянуть параллельно будет очень трудно, или надо все же перевести компилятор на CCI и тогда это уже будут его проблемы.

WH>А что касается остального то единственный способ ускорить появление это сделать самому.

Ну, или подождать когда кто-то сделает .

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

VD>На 2010 переходить конечно надо. Просто такой переход или будет означат полный отказ от 2.0-3.5 фрэймворков, так как на SRE их тянуть параллельно

А зачем они могут быть нужны ?

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

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

VD>>На 2010 переходить конечно надо. Просто такой переход или будет означат полный отказ от 2.0-3.5 фрэймворков, так как на SRE их тянуть параллельно

Э>А зачем они могут быть нужны ?

Иногда они возвращаются (тот должен быть какойнить демотиватор), в смысле приходится писать под старые платформы.

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

VD>Тут же банальный дизайнерский выбор. Опереторы определяются последоватльностью символов, но при этом можно определить любой новый оператор. Никаких косяков тут нет и в помине.

Ну так вот и говори про банальный дизайнерский выбор. Мне в твоей речи не понравилось вот это:

А кому нужна такая компактность? Все нужна читаемость. Если код компактен, но на его чтение нужно тратить больше времени и сил, то такая компактность не нужна, точнее вредна.

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

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

Это не твоя забота как разработчика языка.

IT>>Это не должно быть заботой разработчика инструмента.
VD>Я бы желал иметь единый стиль и полный запрет всех остальных. Объяснять каждому, что не нужно придерживаться каки-то соглашений, лично меня, уже достало.

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

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

VD>>На 2010 переходить конечно надо. Просто такой переход или будет означат полный отказ от 2.0-3.5 фрэймворков, так как на SRE их тянуть параллельно

Э>А зачем они могут быть нужны ?

Многие задаются вопросом зачем нужен дотнет 4.0 и 2010 студия (которая сильно медленнее чем 2008-я).

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

VD>Многие задаются вопросом зачем нужен дотнет 4.0 и 2010 студия (которая сильно медленнее чем 2008-я).

В v4.0 x64 более честная оптимизация хвостовой рекурсии. Чем не повод для перехода?

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

D>В v4.0 x64 более честная оптимизация хвостовой рекурсии. Чем не повод для перехода?
Всеравно тормозит так что раскручивать и дальше придется компилчтором.

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

IT>Ну так вот и говори про банальный дизайнерский выбор.

Я про это сразу и говорил. А ты заладил "косяк", "косяк".

IT>Мне в твоей речи не понравилось вот это:

IT>

IT>А кому нужна такая компактность? Все нужна читаемость. Если код компактен, но на его чтение нужно тратить больше времени и сил, то такая компактность не нужна, точнее вредна.

Это мое личное мнение. Уж извини, что оно не совпадает с твоим.

IT>И это всё ради обоснования того, что код пробелами не отбивать вредно, поэтому это никакой не косяк и не дизайнерский выбор, а вы все сами мудаки.

Это все чтобы объяснить, что выбор совершенно нормальный.

IT>И ещё раз.

Пожалуй не стоит. То что ты со мной не согласен я уже понял.

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

D>В v4.0 x64 более честная оптимизация хвостовой рекурсии. Чем не повод для перехода?

Нужна не "более", а полноценная.

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

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

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

D>>В v4.0 x64 более честная оптимизация хвостовой рекурсии. Чем не повод для перехода?
WH>Всеравно тормозит так что раскручивать и дальше придется компилчтором.

Он говорит про четвертый фрэймворк. Возможно там они что-то улучшили.

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

D>>В v4.0 x64 более честная оптимизация хвостовой рекурсии. Чем не повод для перехода?

VD>Нужна не "более", а полноценная.

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

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

D>>>В v4.0 x64 более честная оптимизация хвостовой рекурсии. Чем не повод для перехода?

VD>>Нужна не "более", а полноценная.

D>Разработчики уверяют, что сейчас оптимизация на уровне виртуальной машины срабатывает гораздо чаще (трамплин??), но цена вопроса — падение скорости. В более ранних версиях оптимизация срабатывала реже, но и была быстрее, как пишут они.

Тут имеет место одно из трех явлений:
1. Ты что-то напутал.
2. Разработчики бредят.
3. Разработчики лохи.

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

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

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

Оптимизация хвостовой рекурсии нужна исключительно для реализации алгоритмов в функциональном стиле. А реализация спокойно может быть и скрытой (private). Так что достаточно реализовать оптимизация хвостовой рекурсии внутри функции и для private-функций которые ее вызывают.


ЗЫ

Моя просьба о тестировании хвостовой рекурсии в 4-е остается в силе .

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

VD>С рядом зависимых функций сложнее.

То-то и оно. Взаимная хвостовая рекурсия.

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

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

VD>>С рядом зависимых функций сложнее.
D>То-то и оно. Взаимная хвостовая рекурсия.
Да нет ничего сложного в хвостовой рекурсии.
Все что нужно это правильные соглашения о вызовах.
Агрументы в функцию нужно просто передавать через регистры или через стек но они должны идти после адреса возврата и чистить их должна соответственно вызываемая функция.
Вызов функции выглядит так
начальное состояние
1)ret >arg arg loc loc
кладем в стек аргументы
2)ret >arg arg loc loc reserved arg arg
смещаем указатель стека
3)ret arg arg loc loc >reserved arg arg
вызываем
4)ret arg arg loc loc ret >arg arg

Хвостовой вызов
Удаляем свои аргументы
1)ret arg arg loc loc ret >
Кладем новые
2)ret arg arg loc loc ret >arg arg arg arg
goto в начало вызываемой функции
3)ret arg arg loc loc ret >arg arg arg arg

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

Правда при такой схеме CAS пролетает как фанера над Парижем...
Но CAS не нужен.

D>Еще void на конце должен теперь нормально обрабатываться, а то смешно было, другие значения обрабатывались, а void почему-то нет...
Я на мелкософт за то как они сделали виртуальную машину могу очень долго ругаться матом...

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

D>То-то и оно. Взаимная хвостовая рекурсия.

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

Еще раз (надеясь последний).

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

Я внятно изложил совою мысль?

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

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

KK>>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

FR>Это так во всех языках в которых можно определять пользовательские нестандартные операторы:

Я не хочу придираться, но насчет _всех_ вы погорячились

Мне в Hyperlua пришлось напрячься, чтобы сохранить 100% обратную совместимость с lua, в результате:

local x=-1
local (===) = fn (l,r) => l == r end

без проблем компилируется в

local x = -1;
local _op_eq_eq_eq = function(l, r) return l==r end

А попытка объявить оператор =-

local (=-) = fn (l,r) => l - r end

выдаст ошибку

xxx.hlua:3:8: error: (=-) would be parsed as lua-op (=) and prefix-op (-):

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

VD>Еще раз (надеясь последний).

VD>Я внятно изложил совою мысль?

А разве мы с тобой о чем-то спорили?! Пятница... понимаю

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

D>А разве мы с тобой о чем-то спорили?! Пятница... понимаю

Просто ты так настойчиво рекламируешь концевую рекурсию в четвертом фрэймворке...

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

VD>Просто ты так настойчиво рекламируешь концевую рекурсию в четвертом фрэймворке...

А что тут такого? Меня эта штука очень радует И меня очень сильно огорчает, что нет ничего подобного в JVM (а то бы перенес туда одну свою поделку). Как я понимаю, даже у микрософтовцев получилось добиться определенных успехов далеко не сразу. Видать, что-то там не срастается (да с тем же стеком вызовов или с ложными хвостовыми вызовами — хз). Причем, TCO реализован по-разному на x64 и x86. Опять вопросы...

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

D>А что тут такого? Меня эта штука очень радует И меня очень сильно огорчает, что нет ничего подобного в JVM (а то бы перенес туда одну свою поделку). Как я понимаю, даже у микрософтовцев получилось добиться определенных успехов далеко не сразу. Видать, что-то там не срастается (да с тем же стеком вызовов или с ложными хвостовыми вызовами — хз). Причем, TCO реализован по-разному на x64 и x86. Опять вопросы...
Не срастается там драйвер hands.sys

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

D>Причем, TCO реализован по-разному на x64 и x86. Опять вопросы...

Подозреваю что на x64 банально регистров больше.

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

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

KK>>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

H>Это кстати спорный момент. Найди хотябы один гайдлайн, где дозволяется не отбивать пробелами сишный оператор присваивания.

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

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

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

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

KK>>>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

H>>Это кстати спорный момент. Найди хотябы один гайдлайн, где дозволяется не отбивать пробелами сишный оператор присваивания.

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

Ок.
Следующий код некорректный

d=-1;

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

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

H>Это свойство языка — его придется запомнить, чтобы присать корректный код.

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

Хотя, запомнить, конечно, придётся.

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

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

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

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

H>Следующий код некорректный
H>

H>d=-1;
H>

H>потому что в Nemerle (а также в некоторых других языках) дозволяется создавать произвольные пользовательские операторы.
H>Это свойство языка — его придется запомнить, чтобы присать корректный код.

Его даже запоминать не надо. Компилятор сообщит об ошибке объяснив, что оператора "=-" не существует. Так что разговор просто не о чем. Ни какой порог тут не причем. Ошибка контролируется компилятором, а значит будет выявлена сразу же и не приведет к проблемам.

Единственное, что — это может раздражать тех кто привык склеивать операторы в выражениях. Им придется подумать о том что им важнее, расширяемость или привычка.

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

IT>Это "свойство" выправляется правкой лексера,

IT люди лепящие свое мнение даже не задумывась над ней выглядят глупо. Не уподобляйся им.

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

Список операторов заранее не определен. Единственное правило работающие для их выявления — "Оператор — это непрерывная последовательность операторных символов.".

IT>Хотя, запомнить, конечно, придётся.

Придется. Все кому гонокод ближе расширяемости, идут программировать на замечательные языки вроде C#, С++ или Java. Менять ради них правила никто не будет. На то нет никаких разумных оснований.

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

VD>Список операторов заранее не определен.

Неопределён заранее чего?

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

VD>>Список операторов заранее не определен.

IT>Неопределён заранее чего?

Сформулируй, плиз, мысль так чтобы ее можно было понять.

Список не определен заранее. Он расширяем. Причем кем угодно. Что тут не понятного?

ЗЫ

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

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

VD>>>Список операторов заранее не определен.
IT>>Неопределён заранее чего?
VD>Сформулируй, плиз, мысль так чтобы ее можно было понять.

Насколько мне известно, оператор в Немерле — это макрос, т.е. должен быть определён во внешней сборке. Т.е. "расширение списка опрераторов" штука, которая на компиляцию никак не влияет. Так же я подозреваю, что где-то в компиляторе должна читаться информация из внешних сборок, чтобы резолвить в конце концов те же операторы. Если чтение этой информации перенести до вызова лексера, то он сможет сверяться со списком операторов при веделении Token.Operator. При знании потрохов компилятора как у тебя и при отсутствии мистической херни, пофиксить обсуждаемый косяк дело техники, желания и пары часов с перекурами.

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

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

VD>>>>Список операторов заранее не определен.
IT>>>Неопределён заранее чего?
VD>>Сформулируй, плиз, мысль так чтобы ее можно было понять.

IT>Насколько мне известно, оператор в Немерле — это макрос

Макрос может обрабатывать код с целью поиска некоторых волшебных конструкций типа a <<< b и заменять их на нечто исполнябельное.

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

IT>>Насколько мне известно, оператор в Немерле — это макрос
H>Макрос может обрабатывать код с целью поиска некоторых волшебных конструкций типа a <<< b и заменять их на нечто исполнябельное.

Т.е. дело уже вовсе не в расширямости списка операторов
В принципе, если есть такой макрос, то рядом с ним всегда можно объявить заглушку такого оператора. Так даже правильнее будет.

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

IT>Насколько мне известно, оператор в Немерле — это макрос, т.е. должен быть определён во внешней сборке.

Не совсем так. Операторы могут вводиться как макросами, так и статическими методами (почти как в C#, только с синтаксисом который можно запомнить).

IT>Т.е. "расширение списка опрераторов" штука, которая на компиляцию никак не влияет.

Это утверждение не верно.

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

Естественно.

IT> Если чтение этой информации перенести до вызова лексера, то он сможет сверяться со списком операторов при веделении Token.Operator.

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

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

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

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

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

H>Здравствуйте, Aleх, Вы писали:

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

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

KK>>>>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

H>>>Это кстати спорный момент. Найди хотябы один гайдлайн, где дозволяется не отбивать пробелами сишный оператор присваивания.

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

H>Ок.
H>Следующий код некорректный
H>

H>d=-1;
H>

H>потому что в Nemerle (а также в некоторых других языках) дозволяется создавать произвольные пользовательские операторы.
H>Это свойство языка — его придется запомнить, чтобы присать корректный код.
Понятно. Я это узнал, дочитав тему до конца.
Но у меня возник следующий вопрос. А на сколько ли это полезная фича? Я не представляю себе, того чтобы перегруженная абракадабра из символов в качестве оператора была красивым решением. Количество операторов, которые имеет смысл перегружать конечно и оно не является слишком уж большим, чтобы его не зафиксировать в языке. Так вот, почему бы это не сделать?

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

A>Но у меня возник следующий вопрос. А на сколько ли это полезная фича? Я не представляю себе, того чтобы перегруженная абракадабра из символов в качестве оператора была красивым решением.

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


A>Количество операторов, которые имеет смысл перегружать конечно и оно не является слишком уж большим, чтобы его не зафиксировать в языке. Так вот, почему бы это не сделать?

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

Скажем когда-то C#-программисту было не ясно зачем может понадобиться оператор "=>". Сегодня C#-программисту не ясно зачем нужны операторы :: и многие другие. Но это же не значит, что они не нужны кому-то другому?

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

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

IT>>Насколько мне известно, оператор в Немерле — это макрос, т.е. должен быть определён во внешней сборке.
VD>Не совсем так. Операторы могут вводиться как макросами, так и статическими методами (почти как в C#, только с синтаксисом который можно запомнить).

А статическими методами вводятся новые операторы или перекрываются стандартные?

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

IT>А статическими методами вводятся новые операторы или перекрываются стандартные?

И то, и другое.

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

VD>Здравствуйте, Aleх, Вы писали:

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

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

Если nemerle пытается быть похожем на C#, то и работать он должен как C#, в том числе в случае x=-1.
Это haskell и f# могут себе позволить ругаться в таких случаях.

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

G>Если nemerle пытается быть похожем на C#, то и работать он должен как C#, в том числе в случае x=-1.

Совершенно не верный логический вывод. Быть походим на что-то, не означает копировать это что-то на 100%. У немерла есть куда более серьезных различий с C#. Скажем то как указываются типы или то что в немерле нет стэйтментов.

Немерле — это не копия C#. Немерл просто позволяет C#-программисту быстро адаптироваться к языку. Но в базе это очень разные языки. Особенно если смотреть на уровне выражений.

G>Это haskell и f# могут себе позволить ругаться в таких случаях.

Я вообще не вижу здесь проблемы. Проблема возникла ровно у одного человека. Причем сам он не расценивает ее как критическую и был удовлетворен улучшенной диагностикой ошибок такого рода.

К чему это упорство?

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

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

G>>Если nemerle пытается быть похожем на C#, то и работать он должен как C#, в том числе в случае x=-1.

VD>Совершенно не верный логический вывод.
Ну конечно.

VD>Быть походим на что-то, не означает копировать это что-то на 100%.
Тем не менее существует эта тема, где человек, использовавший в C# выражение a=-1 недумевает почему в nemerle он не может сделать того же самого, несмотря на похожесть на C#.

VD>У немерла есть куда более серьезных различий с C#. Скажем то как указываются типы или то что в немерле нет стэйтментов.
И это тоже напрягает, я бы типы вообще не указывал (как в haskell).

VD>Немерле — это не копия C#. Немерл просто позволяет C#-программисту быстро адаптироваться к языку. Но в базе это очень разные языки. Особенно если смотреть на уровне выражений.
По факту — не позволяет, потому что люди используют C#_овые инстинкты. Примерно такая же проблема с переходом с C++ на C#. Языки похожи и люди начинают писать на C#, как на С++.

В детстве я писал на языке названия которого даже не помню где отрицательные числла обязательно брать в скобки.
i=(-1);

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

G>>>Если nemerle пытается быть похожем на C#, то и работать он должен как C#, в том числе в случае x=-1.

VD>>Совершенно не верный логический вывод.
G>Ну конечно.

Ага. Из похожести А на Б никак не вытекает одинаковость А и Б.

VD>>У немерла есть куда более серьезных различий с C#. Скажем то как указываются типы или то что в немерле нет стэйтментов.
G>И это тоже напрягает, я бы типы вообще не указывал

Ну, это вообще из разряда "Коллеги улыбнитесь". С одной стороны напрягает отличие в выражении типов, но с другой предлагается сделать эти отличия еще больше.

G>(как в haskell).

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

G>По факту — не позволяет, потому что люди используют C#_овые инстинкты. Примерно такая же проблема с переходом с C++ на C#. Языки похожи и люди начинают писать на C#, как на С++.

Различия конечно есть. Иначе вообще не ясно зачем нужен другой язык, если он полностью копирует исходный. Но тем не менее C#-программисту не составит труда за день освоить базовые различия и начать писать на Nemerle в стиле C#. Что совершенно не так при переходе с С++ или другого языка. Вот это факт проверенный множеством людей.

И уж точно работа с операторами — это не та черта языка которая останавливает массы от перехода на Nemerle. Большинство и так использует различные соглашения по форматированию кода в которых всегда требуется отбивать операторы пробелами. Так что для большинства такой проблемы не существует вовсе.

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

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

G>>>>Если nemerle пытается быть похожем на C#, то и работать он должен как C#, в том числе в случае x=-1.

VD>>>Совершенно не верный логический вывод.
G>>Ну конечно.
VD>Ага. Из похожести А на Б никак не вытекает одинаковость А и Б.
Это ты всем пользователям объясни.

VD>>>У немерла есть куда более серьезных различий с C#. Скажем то как указываются типы или то что в немерле нет стэйтментов.
G>>И это тоже напрягает, я бы типы вообще не указывал
VD>Ну, это вообще из разряда "Коллеги улыбнитесь". С одной стороны напрягает отличие в выражении типов, но с другой предлагается сделать эти отличия еще больше.
Конечно, чем меньше синтаксической схожести языков, тем меньше используется привычек из одного в другом.

VD>И уж точно работа с операторами — это не та черта языка которая останавливает массы от перехода на Nemerle. Большинство и так использует различные соглашения по форматированию кода в которых всегда требуется отбивать операторы пробелами. Так что для большинства такой проблемы не существует вовсе.
Каждый найдет такую маленькую проблему. Отмахиваться от всех этих проблем разом не стоит.

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

VD>>Ага. Из похожести А на Б никак не вытекает одинаковость А и Б.
G>Это ты всем пользователям объясни.

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

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

Ну, так чего добиваться то? Схожести или различий?
При проектировании языка постоянно приходится делать выбор между разными альтернативами. Похожесть на Шарп не должна при этом снижать возможности языка.
В данном случае (случае с операторами) мы имеем два "зла". С одной стороны ограничение на расширяемость операторов, с другой точность копирования C#. В данном случае выбор был сделать в пользу расширяемости.
К тому родителями Nemerle являются не только C#, но и OCaml. Данная возможность позаимствована из OCaml. Тоже самое можно сказать об указании типов и некоторых других вещах (алгебраические типы, паттерн-матчинг).

G>Каждый найдет такую маленькую проблему. Отмахиваться от всех этих проблем разом не стоит.

Никто и не отмахивается. Но на всех не угодишь.

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

G>Это ты всем пользователям объясни.

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

G>Каждый найдет такую маленькую проблему. Отмахиваться от всех этих проблем разом не стоит.

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

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

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

G>>Это ты всем пользователям объясни.

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

G>>Каждый найдет такую маленькую проблему. Отмахиваться от всех этих проблем разом не стоит.

C>Факты против Вас, уважаемый . Только одного человека из отписавшихся в этой теме что-то раздражает в синтаксисе Немерле (конечно, по закону Паркинсона, дискуссия разгорелась просто жаркая). Все остальные проблемы из указанных намного серьезнее этой, и вот на них-то разработчики языка и стараются фокусироваться.

Ну меня например тоже раздражает невозможности писать без пробелов, поэтому страшно бесит синтаксис частичного применения в nemerle. Имхо лучше как в caml\f#\haskell с использованием карринга.

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

G>Ну меня например тоже раздражает невозможности писать без пробелов, поэтому страшно бесит синтаксис частичного применения в nemerle. Имхо лучше как в caml\f#\haskell с использованием карринга.

Ужасно раздражает невозможность писать программы в стиле Brainfuck: ">[-]>[-]<<[->+>+<<]>>[-<<+>>]<<". Давайте поменяем синтаксис.

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

IT>>А статическими методами вводятся новые операторы или перекрываются стандартные?
VD>И то, и другое.

Не мог бы показать хотя бы один такой нестандартный оператор? В компиляторе одни макросы.

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

VD>>Быть походим на что-то, не означает копировать это что-то на 100%.
G>Тем не менее существует эта тема, где человек, использовавший в C# выражение a=-1 недумевает почему в nemerle он не может сделать того же самого, несмотря на похожесть на C#.

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

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

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

VD>>>Быть походим на что-то, не означает копировать это что-то на 100%.
G>>Тем не менее существует эта тема, где человек, использовавший в C# выражение a=-1 недумевает почему в nemerle он не может сделать того же самого, несмотря на похожесть на C#.

IT>Не трать патроны. Похоже тут пока не научились всё называть своими именами. Так что косяк — он вовсе не косяк, а грамотное дизайнерское решение.

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

http://ru.wikipedia.org/wiki/J_(%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

J — функциональный векторный язык программирования (Массивное программирование). Диалект АПЛ. В отличие от АПЛ не требует специальной раскладки клавиатуры для ввода математических символов, поскольку использует символы ASCII.

А вы все "неудобно пробел ставить, инстинкты С#..."

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

IT>Не трать патроны. Похоже тут пока не научились всё называть своими именами. Так что косяк — он вовсе не косяк, а грамотное дизайнерское решение.

Опишите, пожалуйста, ваш вариант решения этой проблемы. Ограничения: нельзя ломать существующий код; нельзя сильно замедлять работу компилятора. Желательно также указать достоинства и недостатки (в сравнении со статусом кво) вашего решения.

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

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

G>Ну меня например тоже раздражает невозможности писать без пробелов, поэтому страшно бесит синтаксис частичного применения в nemerle. Имхо лучше как в caml\f#\haskell с использованием карринга.

Еще интереснее. Данный алгоритм выделения операторов при лексическом разборе взята как раз и языков группы ML. Так что в Haskell или F# точно так же нельзя писать операторы слитно. И никакой каринг тут не поможет.

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

def inc =1+_;
WriteLine(inc(2));

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

В данной жаркой (и совершенно бесполезной) дискуссии речь идет о сочетании бинарных и унарных операторов, или о сочетании унарных операторов и конструкций вроде присвоения значения переменной "x=-1". Эти случаи довольно редки, так что на них не так то легко нарваться. И если все же нарвешься, то компилятор выдаст сообщение о том, что оператор =- не найден.

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

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

VD> И почему эта мелочь вызвала столь бурное обсуждение, я совершенно не понимаю!

Наверное, впитанное с молоком Паскаля и С убеждение, что программа должна компилироваться или не компилироваться независимо от табов, пробелов и ентеров

За похожие вещи достается и Питону, и Хаскеллу, и Бейсику, и тому же indent-режиму Немерле.

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

IT>Не мог бы показать хотя бы один такой нестандартный оператор? В компиляторе одни макросы.

http://code.google.com/p/nemerle/source/browse/nemerle/trunk/lib/internal-numbered.n

Сразу идут операторы |> и >>

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

IT>Не мог бы показать хотя бы один такой нестандартный оператор? В компиляторе одни макросы.

Например, операторы работы с функциями:
http://code.google.com/p/nemerle/source/browse/nemerle/trunk/lib/internal-numbered.n#53

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

C>Опишите, пожалуйста, ваш вариант решения этой проблемы. Ограничения: нельзя ломать существующий код; нельзя сильно замедлять работу компилятора. Желательно также указать достоинства и недостатки (в сравнении со статусом кво) вашего решения.

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

Нет никакого решения и не будет. Есть только общие рассуждения, что можно было бы сделать по другому (с блэкджеком и шлюхами).

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

C>Наверное, впитанное с молоком Паскаля и С убеждение, что программа должна компилироваться или не компилироваться независимо от табов, пробелов и ентеров

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

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

C>Опишите, пожалуйста, ваш вариант решения этой проблемы. Ограничения: нельзя ломать существующий код; нельзя сильно замедлять работу компилятора. Желательно также указать достоинства и недостатки (в сравнении со статусом кво) вашего решения.

Решение простое (могло бы оказаться). Всего лишь навсего в лексере нужно сверяться со списком операторов, которые нам известны на момент компиляции. Этому решению препятствует тот факт, что нестандартные операторы можно объявлять в компилируемом коде в виде статических методов. Правда я не нашёл ни одного такого оператора в коде компилятора, все они объявлены как макросы, но Влад утверждает, что можно. Но даже в этом случае это решение вполне могло бы решить часть проблем. Предлагать отказаться от использования статических методов для объявления операторов не буду, иначе меня тут растерзают. Хотя тоже вариант.

Можно решить проблему и другим способом в момент, когда резолвятся операторы. Где-то примерно в этом месте Влад недавно сделал выдачу более вменяемого сообщения об ошибке. Дело в том, что когда мы начинаем компилировать методы, то список всех операторов нам уже известен. Теперь нужно только подумать как правильно изменить AST, чтобы вместо одного неразрешённого оператора в нём оказалось два разрешённых. Код ломаться не будет. Работу компилятора это не замедлит никак, если конфликтной ситуации не возникнет, то этот код даже выполняться не будет.

Могу предложить ещё одно решение этой проблемы конкретно в этом топике — начать назвать вещи своими именами. Лично мне больше всего не нравится одно — то, что косяк назвают дизайнерским решением. Я согласен с тем, что это дизайнерское решение, но давайти говорить, что прежде всего — это косяк, а уже потом дизайнерское решение. Т.е. косяк, вызванный дизайнерским решением. После этого разговоры о том у кого какие предпочтения в оформлении кода автоматически заканчиваются и либо начинается позитивный разговор о возможном фиксе, либо все соглашаются, что с этим косяком можно жить и его фикс невозможен или нецелесообразен.

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

IT>>Не мог бы показать хотя бы один такой нестандартный оператор? В компиляторе одни макросы.
C>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/lib/internal-numbered.n
C>Сразу идут операторы |> и >>

О! Спасибо.

Вообще-то, >> вполне себе стандартный оператор сдвига, если не ошибаюсь. Т.е. получается, что во всём компиляторе есть только один такой оператор — |>.

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

IT>Решение простое (могло бы оказаться). Всего лишь навсего в лексере нужно сверяться со списком операторов, которые нам известны на момент компиляции. Этому решению препятствует тот факт, что нестандартные операторы можно объявлять в компилируемом коде в виде статических методов.

Не только. Препятсвует еще и неоднозначность которая может возникнуть. Примеры я тебе уже приводил.
Если появится оператор === (а это весьма возможно, во многих языках он используется), то код вроде:

a=====b

будет не ясно как разбирать. Это может быть как:

a=== ==b

так и:

a== ===b

Конечно и тут можно ввести эвристики вроде побеждает самое длинное вхождение, но зачем?
Есть более простое и однозначное решение. Оператор — это последовательность операторных символов.

IT>Правда я не нашёл ни одного такого оператора в коде компилятора, все они объявлены как макросы, но Влад утверждает, что можно.

Плохо искал. Тебе уже давали ссылку на оператор |> в функциях.

IT>Но даже в этом случае это решение вполне могло бы решить часть проблем.

Дык мы уже имеем полное решение проблемы. Зачем нам частичное то?

IT>Предлагать отказаться от использования статических методов для объявления операторов не буду, иначе меня тут растерзают. Хотя тоже вариант.

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

IT>Можно решить проблему и другим способом в момент, когда резолвятся операторы. Где-то примерно в этом месте Влад недавно сделал выдачу более вменяемого сообщения об ошибке.

Влад доработал парсер в месте где он парсит mutable-переменную. Операторы там не "резолвятся". Там просто упускался тот факт, что в коде, вместо "expr" за которым идет "=" может быть "expr =- expr". Я просто добавил анализ этой ситуации и соответствующее сообщение об ошибке. А логика выявления операторов я не трогал.

Вот все это изменение.

IT>Дело в том, что когда мы начинаем компилировать методы, то список всех операторов нам уже известен.

Вот только лексер работает сильно раньше и не знает обо всем об этом.

IT>Теперь нужно только подумать как правильно изменить AST, чтобы вместо одного неразрешённого оператора в нём оказалось два разрешённых. Код ломаться не будет. Работу компилятора это не замедлит никак, если конфликтной ситуации не возникнет, то этот код даже выполняться не будет.

А если возникнет? И ведь точно возникнет. Закон подлости еще никто не отменял.

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

IT>Могу предложить ещё одно решение этой проблемы

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

IT> конкретно в этом топике — начать назвать вещи своими именами.

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

IT> Лично мне больше всего не нравится одно — то, что косяк назвают дизайнерским решением.

А мне больше всего не нравится, то что ты откровенно уперся рогом в несуществующую проблему, тратишь свое и чужое время. Лучше бы потратил его на что-то полезное. Помог бы нам, или баг какой в БУлките поправил.

Так же мне не нравится когда кто-то наклеивает ярлыки "косяк" и т.п., но при этом предложить другого решения не приводящего к большим проблемам не может.

IT>Я согласен с тем, что это дизайнерское решение,

О как? И что же тогда ярлык "косяк" клеишь. Можно просто сойтись на том, что ты с ним не согласен.
Ну, так не согласен и отлично. Другие, те кто готов менять что-то в языке если это что-то с их точки зрения полезно, считают такое решение хорошим.

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

IT>но давайти говорить, что прежде всего — это косяк,

Даже если ты 100 скажешь "сахар" слаще не станет. Лично я не буду говорить, что это кося просто потому, что так не считаю. Это такое же решение, как например, решение использовать фигурные скобки для блоков, или спаренные символы для операторов. Очень редко когда у какого-то решения есть только положительные стороны. Почти всегда у решений есть и отрицательные моменты. Скажем то, что в немерле выбрана скобочная нотация вызова функций (как в С) приводит к тому, что некоторые вкусности из ML-я не работают. Для некоторых товарищей это огромная проблема. Как и ты они с радостью навешивают ярлык "косяк" (или ему подобный) на подобные решения. И им плевать на любые аргументы (что есть частичное применение, которое круче каринга, и что скобочный синтаксис привычнее сишникам).

IT> а уже потом дизайнерское решение.

Плюрализм страшная вещь. Ну не хотят все принимать твою точку зрения. Что поделать? Давай лучше назовем косяком твою точку зрения. ОК?

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

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

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

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

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

IT>>>Не мог бы показать хотя бы один такой нестандартный оператор? В компиляторе одни макросы.
C>>http://code.google.com/p/nemerle/source/browse/nemerle/trunk/lib/internal-numbered.n
C>>Сразу идут операторы |> и >>

IT>О! Спасибо.

IT>Вообще-то, >> вполне себе стандартный оператор сдвига, если не ошибаюсь. Т.е. получается, что во всём компиляторе есть только один такой оператор — |>.

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

Самому то не смешно?

ЗЫ

Кончай толлить.

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

C>>Наверное, впитанное с молоком Паскаля и С убеждение, что программа должна компилироваться или не компилироваться независимо от табов, пробелов и ентеров
VD>Самое смешное, что тот же IT порвет по полам если в коде который он будет читать операторы будут слитно писаться. Так что с его стороны разговор чисто за демократию и либеральность.

В данном случае во мне борятся два чувства прекрасного: прекрасного кода и прекрасного компилятора. Второе побеждает

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

IT>В данном случае во мне борятся два чувства прекрасного: прекрасного кода и прекрасного компилятора. Второе побеждает

Мне кажется, что тут еще есть чувство прекрасного троля которые побеждает все .

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

VD>Конечно и тут можно ввести эвристики вроде побеждает самое длинное вхождение, но зачем?

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

VD>Влад доработал парсер в месте где он парсит mutable-переменную. Операторы там не "резолвятся".

Понятно, ещё одна заклёпка.

IT>>Дело в том, что когда мы начинаем компилировать методы, то список всех операторов нам уже известен.
VD>Вот только лексер работает сильно раньше и не знает обо всем об этом.

Здесь про лексер никто и не говорит. Это можно сделать на этапе, когда компилятор разбирает последовательность токенов и преобразует его в AST метода. Либо ещё позже.

IT>>Теперь нужно только подумать как правильно изменить AST, чтобы вместо одного неразрешённого оператора в нём оказалось два разрешённых. Код ломаться не будет. Работу компилятора это не замедлит никак, если конфликтной ситуации не возникнет, то этот код даже выполняться не будет.

VD>А если возникнет? И ведь точно возникнет. Закон подлости еще никто не отменял.
VD>Кроме того, получается мы заранее вынуждены запретить вводить операторы имеющие префикс "=". Ведь они никогда в жизни не смогут использоваться, так как в синтаксисе языка "=" уже используется для присвоения.

С какого бодуна? Ты же сам только что говорил о правильном соглашении, что побеждает тот, кто длиннее.

IT>> Лично мне больше всего не нравится одно — то, что косяк назвают дизайнерским решением.
VD>А мне больше всего не нравится, то что ты откровенно уперся рогом в несуществующую проблему, тратишь свое и чужое время. Лучше бы потратил его на что-то полезное. Помог бы нам, или баг какой в БУлките поправил.

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

VD>Так же мне не нравится когда кто-то наклеивает ярлыки "косяк" и т.п., но при этом предложить другого решения не приводящего к большим проблемам не может.

Я хотя бы пытаюсь.

VD>Но и про фикс отсутствующей проблемы с тобой никто говорить не намерен.

Вот это меня больше всего и беспокоит. Сегодня у нас явный косяк объявляется отсутсвующей проблемой. Завтра мы объявляем идиотами всех тех, кто создаёт файлы больше 100 килобайт, не имеет при этом core 2 duo и жалуется на долгий Intellisense, а после завтра мы купим себе 6 core и объявим пидарасами вообще всех.

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

А я и предлагаю. Только твоё внимание сейчас обращено исключительно к моей персоне. Перечитай внимательно и главное без эмоций мой предыдущий пост.

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

VD>>Конечно и тут можно ввести эвристики вроде побеждает самое длинное вхождение, но зачем?

IT>Затем, что Nemerle, точнее его авторы пытаются декларировать его как язык будущего, а от таких дестких болячек избавиться не могут. Я бы ещё поляков понял, для них была важна прежде всего проверка концепта.

Задолбал.

VD>>Влад доработал парсер в месте где он парсит mutable-переменную. Операторы там не "резолвятся".

IT>Понятно, ещё одна заклёпка.

Еще одна обработка ошибочной ситуации.

IT>>>Дело в том, что когда мы начинаем компилировать методы, то список всех операторов нам уже известен.
VD>>Вот только лексер работает сильно раньше и не знает обо всем об этом.

IT>Здесь про лексер никто и не говорит. Это можно сделать на этапе, когда компилятор разбирает последовательность токенов и преобразует его в AST метода. Либо ещё позже.

Нельзя. Операторы разбираются именно лексером. А дальше уже только производится проверка есть распознанный оператор или нет.

VD>>Кроме того, получается мы заранее вынуждены запретить вводить операторы имеющие префикс "=". Ведь они никогда в жизни не смогут использоваться, так как в синтаксисе языка "=" уже используется для присвоения.

IT>С какого бодуна? Ты же сам только что говорил о правильном соглашении, что побеждает тот, кто длиннее.

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

IT>Думаю, ты слишком увлёкся моей персоной. Лучше бы обратил эту энергию на поиск решения,

Я лучше просто перестану читать эту ветку.

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

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

C>>Опишите, пожалуйста, ваш вариант решения этой проблемы. Ограничения: нельзя ломать существующий код; нельзя сильно замедлять работу компилятора. Желательно также указать достоинства и недостатки (в сравнении со статусом кво) вашего решения.

IT>Решение простое (могло бы оказаться). Всего лишь навсего в лексере нужно сверяться со списком операторов, которые нам известны на момент компиляции. Этому решению препятствует тот факт, что нестандартные операторы можно объявлять в компилируемом коде в виде статических методов.

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

IT>Можно решить проблему и другим способом в момент, когда резолвятся операторы. Где-то примерно в этом месте Влад недавно сделал выдачу более вменяемого сообщения об ошибке. Дело в том, что когда мы начинаем компилировать методы, то список всех операторов нам уже известен. Теперь нужно только подумать как правильно изменить AST, чтобы вместо одного неразрешённого оператора в нём оказалось два разрешённых. Код ломаться не будет. Работу компилятора это не замедлит никак, если конфликтной ситуации не возникнет, то этот код даже выполняться не будет.

Ну почему же только два? В общем случае это задача непростая. Хоть и разрешимая.
Если возникнет конфликт, придется менять тело метода, потому что оно иммутабельное. Или организовывать зипперы всякие и другие способы убить лишнюю память. Но это конечно не проблема.
Проблема в другом. Вот есть у нас код:

x =- 1; // чей автор издевается над теми, кто его читает.

Далее мы подключаем сборку, где (в открытом неймспейсе) определен оператор =-. Если нам повезет, компилятор сообщит об ошибке типов. Если не повезет, код скомпилируется, и программа пойдет под откос.
Вы, конечно, скажете, что при неоднозначностях надо обязательно сообщать об ошибке. Но это сломает существующий код. Более того, даже если не учитывать breaking change, новое поведение будет хуже, чем предыдущее. В данный момент приведенный код — всегда ошибка компиляции. С вашими изменениями, подключение reference'а к компилирующемуся проекту может его сломать. Поскольку простого способа вызвать оператор по неймспейсу нет, пользователю языка в такой ситуации придется помучиться.
И все ради чего? Ради возможности писать программы, которые невозможно читать?

IT>Могу предложить ещё одно решение этой проблемы конкретно в этом топике — начать назвать вещи своими именами. Лично мне больше всего не нравится одно — то, что косяк назвают дизайнерским решением. Я согласен с тем, что это дизайнерское решение, но давайти говорить, что прежде всего — это косяк, а уже потом дизайнерское решение. Т.е. косяк, вызванный дизайнерским решением. После этого разговоры о том у кого какие предпочтения в оформлении кода автоматически заканчиваются и либо начинается позитивный разговор о возможном фиксе, либо все соглашаются, что с этим косяком можно жить и его фикс невозможен или нецелесообразен.

Почему вы считаете данное поведение косяком? Оно соответствует простой спецификации, которая соответствует простой идее: несколько операторных знаков подряд — это один операторный знак. Недостаток у нее только один: разные операторы надо вводить через пробел.

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

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

VD>Ой, тысяча извинений. Мы сейчас срочно уберем |> и запретим вводить другие операторы, только чтобы не портить стройность твоих рассуждений!

Ну, кажется ІТ просто искал пример, а не хотел запретить определение операторов внутри сборки.

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

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

Это я понимаю.

C>И все ради чего? Ради возможности писать программы, которые невозможно читать?

А вот этого не понимаю. Разработчику компилятора не надо учить программистов жизни, они как-нибудь без него разберуться.

Однажды Хейльсберг сказал, что матапрограммирование — это too big gun. Ты бы видел сколько в него было брошено камней, в том числе и теми, кто теперь говорит практически тоже самое в другой ситуации.

В общем, не надо. Про читабельность не надо.

C>Почему вы считаете данное поведение косяком? Оно соответствует простой спецификации, которая соответствует простой идее: несколько операторных знаков подряд — это один операторный знак. Недостаток у нее только один: разные операторы надо вводить через пробел.

Где эта спецификация? И желательно к ней приложить подробное разъяснение того, почему сделан именно такой выбор. Подробное и ясное разъяснение, с примерами, а не с криками, что вы все дебилы и не можете писать читабельный код.

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

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

Встречный вопрос. Почему тогда Немерле разрешает слитное написание скобок? Давайте требовать между ними наличие пробела.

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

VD>>Ой, тысяча извинений. Мы сейчас срочно уберем |> и запретим вводить другие операторы, только чтобы не портить стройность твоих рассуждений!

C>Ну, кажется ІТ просто искал пример, а не хотел запретить определение операторов внутри сборки.

Ага, и когда нашел, так сразу начал рассуждать о том, что он один.

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

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

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

IT>Это я понимаю.

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

C>>И все ради чего? Ради возможности писать программы, которые невозможно читать?

IT>А вот этого не понимаю. Разработчику компилятора не надо учить программистов жизни, они как-нибудь без него разберуться.

IT>Однажды Хейльсберг сказал, что матапрограммирование — это too big gun. Ты бы видел сколько в него было брошено камней, в том числе и теми, кто теперь говорит практически тоже самое в другой ситуации.

IT>В общем, не надо. Про читабельность не надо.

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

IT>Где эта спецификация? И желательно к ней приложить подробное разъяснение того, почему сделан именно такой выбор. Подробное и ясное разъяснение, с примерами, а не с криками, что вы все дебилы и не можете писать читабельный код.

http://nemerle.org/Lexical_structure_%28ref%29#Identifiers

Некоторое разъяснение, и даже с примерами, я уже кажется дал

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

IT>Возможность слитно писать несколько операторов подряд существует в большинстве известных языков программирования и является обычной практикой. Про слитное написание идентификаторов я не слышал.

Отсутствие метапрограммирования и требование всегда явно указывать тип переменной — тоже обычная практика. Последнее — для C, C++ и Java. Первое — в большинстве известных языков.

В старых версиях Бейсика такая "фича" была: http://thedailywtf.com/Articles/ANDYNO.aspx

IT>Встречный вопрос. Почему тогда Немерле разрешает слитное написание скобок? Давайте требовать между ними наличие пробела.

Потому что это не нужно. Если бы в языке была возможность определять свои скобки (в том числе парные, а-ля [[ ... ]]), скорее всего слитное написание было бы запрещено.

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

C>>>Поскольку простого способа вызвать оператор по неймспейсу нет, пользователю языка в такой ситуации придется помучиться.
IT>>Это я понимаю.
C>То есть вы предлагаете свое решение, понимая, насколько оно на самом деле неудобно пользователям языка и его разработчикам?

Я понимаю такое объяснение как аргумент.

C>>>И все ради чего? Ради возможности писать программы, которые невозможно читать?
IT>>А вот этого не понимаю. Разработчику компилятора не надо учить программистов жизни, они как-нибудь без него разберуться.
C>Я не про читабельность.

Я выделил выше "не про читабельность".

Ребята, поймите одну простую вещь. Когда вы пишете в Философию программирования в тему "как правильно расставлять пробелы", вы можете высказывать на эту тему любое своё мнение. Когда же вы выступаете в роли разработчика инструмента, забудьте о своих предпочтениях навсегда. Одну и ту же вещь всегда можно объяснить по разному. Сравни:

— Мне не нравится в Немерле проблема x=-1

1. — Такой проблемы в Немерле нет. Проблема в головах у тех немногочисленных дебилов, которые пишут нечитабельный код.
2. — Эта проблема обусловлена особенностями языка и является выбором в пользу более полезных и необходимых возможностей. Проблема может быть пофикшена, но не является приоритетной (либо не может быть пофикшена).

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

IT>>Где эта спецификация? И желательно к ней приложить подробное разъяснение того, почему сделан именно такой выбор. Подробное и ясное разъяснение, с примерами, а не с криками, что вы все дебилы и не можете писать читабельный код.
C>http://nemerle.org/Lexical_structure_%28ref%29#Identifiers
C>Некоторое разъяснение, и даже с примерами, я уже кажется дал

Издеваешься?

C>>>Если это косяк, то почему требование разделять разные идентификаторы пробелами не косяк? Ведь предложенные вами алгоритмы можно использовать и для разделения идентификаторов.
IT>>Возможность слитно писать несколько операторов подряд существует в большинстве известных языков программирования и является обычной практикой. Про слитное написание идентификаторов я не слышал.
C>Отсутствие метапрограммирования и требование всегда явно указывать тип переменной — тоже обычная практика. Последнее — для C, C++ и Java. Первое — в большинстве известных языков.

Не надо передёргивать.

IT>>Встречный вопрос. Почему тогда Немерле разрешает слитное написание скобок? Давайте требовать между ними наличие пробела.
C>Потому что это не нужно. Если бы в языке была возможность определять свои скобки (в том числе парные, а-ля [[ ... ]]), скорее всего слитное написание было бы запрещено.

Уверен, что не нужно? Тогда спроси у Влада нужны ли ему были когда-нибудь свои скобки или нет и не появились ли они случайно после этого в языке.

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

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

И есть как минимум один язык где это правило используется — Фортран.

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

IT>А вот этого не понимаю. Разработчику компилятора не надо учить программистов жизни, они как-нибудь без него разберуться.

IT, на тебя стало пагубно влиять проживание в стране победивший тоталитарной демократии.

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

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

Не надо называть чужие правила не верными только потому, что ты долгое время жил используя иные правила. А то вот ваше правительство попыталось "подарить" демократию Кабулу и Багдаду, и теперь искренне удивляется тому, почему "эти варвары" недовольны. Все ведь очень просто. Разные предпосылки — разные решения.

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

IT>Возможность слитно писать несколько операторов подряд существует в большинстве известных языков программирования

Вся линейка ML от ML, до Nemerle такую возможность не допускает.

IT> и является обычной практикой.

В Nemerle много "обычных практик" забыто. Не эта первая.

IT>Про слитное написание идентификаторов я не слышал.

Fortran. Там запись типа DOI=0 вполне возможна и может означать "DO I = 0"

IT>Встречный вопрос. Почему тогда Немерле разрешает слитное написание скобок? Давайте требовать между ними наличие пробела.

Потому что они не являются операторами. Он так же позволяет и слитное написание операторов и любых других лексических единиц (например, тех же скобок или идентификаторов). В прочем можно эти правила ужесточить. Хочешь?

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

KK>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

[f#]

let a=-1

[/f#]

let a=-1;;
-----^^

stdin(3,6): error FS0010: Unexpected infix operator in pattern

[haskell]

foo = let a=-1 in a

[/haskell]

Syntax error in declaration (unexpected keyword "in")

Так что nemerle, не один такой "плохой".

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

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

C>>>>Поскольку простого способа вызвать оператор по неймспейсу нет, пользователю языка в такой ситуации придется помучиться.
IT>>>Это я понимаю.
C>>То есть вы предлагаете свое решение, понимая, насколько оно на самом деле неудобно пользователям языка и его разработчикам?

IT>Я понимаю такое объяснение как аргумент.

Хм. Вы говорили, что есть простое решение. Я что-то такого до сих пор не вижу.

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

Мне кажется, что объект вашей критики — совсем не парсинг операторов. Скорее, вы недовольны тем, как принимаются решения в проекте. Если я прав, то вы тогда выбрали неудачный пример.

IT>>>Где эта спецификация? И желательно к ней приложить подробное разъяснение того, почему сделан именно такой выбор. Подробное и ясное разъяснение, с примерами, а не с криками, что вы все дебилы и не можете писать читабельный код.
C>>http://nemerle.org/Lexical_structure_%28ref%29#Identifiers
C>>Некоторое разъяснение, и даже с примерами, я уже кажется дал

IT>Издеваешься?

Да нет. Привожу спецификацию, точнее хоть что-то, что у нас есть.

IT>Уверен, что не нужно? Тогда спроси у Влада нужны ли ему были когда-нибудь свои скобки или нет и не появились ли они случайно после этого в языке.

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

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

H>Здравствуйте, x-code, Вы писали:

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

KK>>>Недостаток неприятный, но не смертельный. Было бы неплохо выводить более врзаумительное сообщение об ошибке: оператор не найден — возможно вы забыли поставить прбел между = и -.

XC>>Нет, я все понимаю, но вот такое... Лексический анализатор, который сканирует входной поток и выдает "лексемы", выкидывая при этом пробелы, комментарии и переносы строк, пишется студентом 1 курса за один вечер (а профессиональным программистом — за пару часов со всей отладкой и тестированием) на любом языке прогораммирования. Никаких специальных знаний для этого не нужно вообще...
XC>>Nemerle особенный?

H>Угу. В нем можно ввести произвольную операторную абракадабру. Посему все операторные нецифробуквенные символы (кроме скобок) склеиваются в один токен, для которого Немерл пытается найти обработчик.

в этих "пустяках" а не в войне фигурных скобок с begin/end, как раз и зарыта проигрышность си-подобного синтаксиса, это его ящик пандоры
недаром немерлисты вернулись к делфо-паскалевской "данное: тип"

я вседа считал, что если первый символ уже занят (на такую важнейшую вещь как присвоение), то аброкадабру с его участием писать не стоит, поэтому в паскале на присвоение выделено два символа ":="

глупость немерла заключается как раз в наследовании си-подобных прибамбасов, т.е. многое "недоперли" у делфи
зачем mutable?? проще же писать var, на худой конец obj. семь символов это прикол

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

KK>Мне не нравится что нельзя писать a=-1, а нужно писать a= -1

я не знаток всех синтаксических тонкостей данного языка, но между прочим могу заметить, что не понимаю почему нельзя было операцию присвоения обозначить как "<-" — это было бы двойственно оператору "->", используемому при выводе результата функции

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

MA>я не знаток всех синтаксических тонкостей данного языка, но между прочим могу заметить, что не понимаю почему нельзя было операцию присвоения обозначить как "<-" — это было бы двойственно оператору "->", используемому при выводе результата функции

Это можно сделать коротким макросом, но это не помогло бы решить проблему:

x<--1.

Что означает данная запись? "(x) <- (-1)" или "(x) < (--1)? Или "(x) <-- (1)"?

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

MA>недаром немерлисты вернулись к делфо-паскалевской "данное: тип"

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

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

Давай конкретно — что?

MA>зачем mutable?? проще же писать var, на худой конец obj. семь символов это прикол

А это чтобы было труднее писать это слово. Иммутабельность — наше все.

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

H>"Данное: тип" это вообще-то характерно для ML-семейства языков. Делфи и паскалем тут и не пахнет, скорее Алголом.

Дельфи и есть кривое развитие Алгола (через Паскаль, многое у Алгола позаимствовавший).

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

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

H>Давай конкретно — что?

Брек. Нам здесь только флэймов с паскаляфилами не хватало.

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

MA>в этих "пустяках" а не в войне фигурных скобок с begin/end, как раз и зарыта проигрышность си-подобного синтаксиса, это его ящик пандоры
MA>недаром немерлисты вернулись к делфо-паскалевской "данное: тип"

А чем не си-подобный синтаксис поможет с этой проблемой?

MA>я вседа считал, что если первый символ уже занят (на такую важнейшую вещь как присвоение), то аброкадабру с его участием писать не стоит, поэтому в паскале на присвоение выделено два символа ":="
MA>глупость немерла заключается как раз в наследовании си-подобных прибамбасов, т.е. многое "недоперли" у делфи
MA>зачем mutable?? проще же писать var, на худой конец obj. семь символов это прикол

Это сделано специально, чтобы поощрять людей используовать иммутабельные переменные.

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

C>Здравствуйте, mister-AK, Вы писали:

MA>>я не знаток всех синтаксических тонкостей данного языка, но между прочим могу заметить, что не понимаю почему нельзя было операцию присвоения обозначить как "<-" — это было бы двойственно оператору "->", используемому при выводе результата функции

C>Это можно сделать коротким макросом, но это не помогло бы решить проблему:
C>

x<--1.

C>Что означает данная запись? "(x) <- (-1)" или "(x) < (--1)? Или "(x) <-- (1)"?

хорошо, тогда надо было думать что выбирать, может символы <: или <~ ?
они тоже заняты под синтаксис немерла?

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

MA>хорошо, тогда надо было думать что выбирать, может символы <: или <~ ?
MA>они тоже заняты под синтаксис немерла?

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

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

C>>Это можно сделать коротким макросом, но это не помогло бы решить проблему:
C>>

x<--1.

C>>Что означает данная запись? "(x) <- (-1)" или "(x) < (--1)? Или "(x) <-- (1)"?

MA>хорошо, тогда надо было думать что выбирать, может символы <: или <~ ?
MA>они тоже заняты под синтаксис немерла?

Зачем пытаться решать проблему которая не существует и вряд ли будет существовать?

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


IT>>Где эта спецификация? И желательно к ней приложить подробное разъяснение того, почему сделан именно такой выбор. Подробное и ясное разъяснение, с примерами, а не с криками, что вы все дебилы и не можете писать читабельный код.

C>http://nemerle.org/Lexical_structure_%28ref%29#Identifiers

C>Некоторое разъяснение, и даже с примерами, я уже кажется дал

Following infix identifiers are reserved keywords: =, $, ?, |, ->, =>, <[, ]>, &&, ||.

а где ":" или оно не является зарезервированым?

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

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

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

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

недаром во всяких фортранах использовали именованые операторы даже для eq.

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

MA>

MA>Following infix identifiers are reserved keywords: =, $, ?, |, ->, =>, <[, ]>, &&, ||.

MA>а где ":" или оно не является зарезервированым?

Не является. Есть оператор конкатенации элемента со списоком ::.


MA>как только вы в мегасуперуниверсальном языке начинаете употреблять служебные оаераторы во всем чём попало, как то математичекие операторы, то язые теряет универсальность, мне кажется.

Использование оператора + для сложения чисел это неуниверсально?


MA>недаром во всяких фортранах использовали именованые операторы даже для eq.

Т.е. всякий фортран это в вашем понимании мегасуперуниверсальный язык?


З.Ы. Заканчивайте уже троллингом заниматься.