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

VD>А на мой взгляд проще ничего не объяснять и везде использовать "!", если уж его выбрать. Один символ при объявлении типа погоду не сделает.

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

class C : !Dictionary[ !List[T] ]

Или это тоже к неоднозначности приводит?

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

VD>Ну, а "!" в коде можно даже использовать, чтобы явно указать, что под именем имеется в виду исключительно тип:

Вместо typeof?

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

SAS>Восклицательный знак перед открывающей квадратной скобкой лишь чуть менее безобразен, чем точка. Лучше уж тогда ставить его перед именем типа:

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

Сравним:

MyNameSpace.MyClass.[T]
MyNameSpace.MyClass![T]

SAS>

SAS>class C : !Dictionary[ !List[T] ] 
SAS>

SAS>Или это тоже к неоднозначности приводит?

!MyMethod[T]().BoolField

Здесь ! относится к T или это логическое отрицание?

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

SAS>Восклицательный знак перед открывающей квадратной скобкой лишь чуть менее безобразен, чем точка. Лучше уж тогда ставить его перед именем типа:
SAS>

SAS>class C : !Dictionary[ !List[T] ] 
SAS>

SAS>Или это тоже к неоднозначности приводит?

Это будет конфликт с унарным "!" (логическое "нет"). Он хоть и макросом сделан, новсе же важный оператор.

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

SAS>Восклицательный знак перед открывающей квадратной скобкой лишь чуть менее безобразен, чем точка. Лучше уж тогда ставить его перед именем типа:
SAS>

SAS>class C : !Dictionary[ !List[T] ] 
SAS>

SAS>Или это тоже к неоднозначности приводит?

Свой пойнт в этом есть, но кроме неоднозначности ещё произошёл разрыв ! от [], что может быть не очень удобным при их добавлении в уже написанную строчку.

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

VD>Ну, а "!" в коде можно даже использовать, чтобы явно указать, что под именем имеется в виду исключительно тип:

А, вот с чем неувязка всплывёт тогда с таким позиционированием:

abstract class C[T] : Dictionary![ List![T] ] 
{
  abstract foo[Q] (x : Q) : C![T];
}
...
_ = x.foo![int] (1);

Не фатально конечно, пусть даже ! — тип, а ![] — generic параметры, но идея-то интересная, надо подумать ещё.

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

Точка в .[T] скрадывает суть выражения, будет похоже на основной member-of. (List.[int] выглядит некузяво, как будто имя индексера забыли ввести)
![T] выглядит вполне прилично (List![int])
Крышка ^[] будет выделяться даже в неподсвеченном тексте (List^[int])
$[], ?[], @[] маловероятно, что вызовут неоднозначности, потому как почти не используются в других контекстах. (List$[int], List?[int], List@[int])
Как ни странно, преимуществом !() будет тот факт, что его можно набрать в любой раскладке. Тем не менее, круглые скобки я бы не использовал ни в каком виде, сливается с простой группировкой выражений.
Ещё можно подумать об использовании {}, но такой вариант может наплодить ещё больше тараканов, т.к. в сознании слишком многих связан с блоком инструкций.

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

SAS>

SAS>public class Test«P,Q» : IEnumerable«P*Q»
SAS>

Первый же дятел с не-уникодным far или total commander или notepad++ или что там ещё бывает угробит такую цивилизацию.

Простите что вмешиваюсь, но как насчёт варианта влада без стрелочек, но с палочками
Вот так:

class MyClass|T| : IMyInterface|T|
{
}

Ещё как варианты

class MyClass/T/ : IMyInterface/T/
{
}

class MyClass/T\ : IMyInterface/T\
{
}

class MyClass*T* : IMyInterface*T*
{
}

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


а если <:T> и <:T1,T2> ?
тогда получается как в С + правило "перед типами ставить :"

но больше всего мне нравится как в F# — int list

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

БП>Здравствуйте, SergASh, Вы писали:

SAS>>

SAS>>public class Test«P,Q» : IEnumerable«P*Q»
SAS>>

БП>Первый же дятел с не-уникодным far или total commander или notepad++ или что там ещё бывает угробит такую цивилизацию.

Очень напрасно критикуете. Лапки прекрасно набираются даже в совершенно неюникодной Windows95 через Alt-0171 и Alt-0187. Эта возможность была еще в ДОС — держишь Alt и цифрами набираешь код символа. Про фар не знаю, но вряд ли там упустили эту фичу. Просьба к пользователям фара подтвердить.

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

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

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

БП>>Первый же дятел с не-уникодным far или total commander или notepad++ или что там ещё бывает угробит такую цивилизацию.

SAS>Очень напрасно критикуете. Лапки прекрасно набираются даже в совершенно неюникодной Windows95 через Alt-0171 и Alt-0187. Эта возможность была еще в ДОС — держишь Alt и цифрами набираешь код символа. Про фар не знаю, но вряд ли там упустили эту фичу. Просьба к пользователям фара подтвердить.

SAS>Я не говорю, что этот способ набора чрезвычайно удобен без клавиатурных сокращений. Но во-первых, не предполагается, что исходники на немерле будут мегабайтами набирать на чем-то примитивном вроде notepad'а. А во-вторых, есть прекрасная утилита для настройки глобальных хоткеев, называется AutoHotKey. Один раз настроил и будет вставлять нужный символ везде, а не только в студии.

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

IT>>А можно <> оставить как в шарпе? Без приколов и очень привычно.

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

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

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

Но неоднозначности появляются только в каких-то особых случаях, ведь так? Может можно сделать простую свёртку с простыми угловыми скобками, а если уж нарисовалась неоднозначность и ничерта не компилируется — то пусть программист использует тот же символ @ для устранения неоднозначностей который был в C#? Показывая этим @< что имеется ввиду не пользовательский оператор <, а именно угловая скобка в объявлении типа.

Я так ратую за простые треугольные скобки лишь потому что у Nemerle основной конкурент — не F#, не хаскель и не Скала, а именно C#. И для C# программиста знакомого Nemerle должен выглядеть эдаким шарпом на стероидах, в котором можно всё тоже самое только лучше и проще.

Даже создатели C#2 когда вводили свою эвристику — тоже ведь могли пойти на реализацию без всякой эвристики, наворотив спец-символов — в C#1 никаких дженериков не было и руки у них были развязаны. Но они сделали так как в C++, просто потому что основным конкурентом шарпу в этом вопросе был C++. И победить его внушив что C# это эдакий С++ только лучше они смогли в том числе и за счёт весьма похоже синтаксиса.

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

SAS>Очень напрасно критикуете. Лапки прекрасно набираются даже в совершенно неюникодной Windows95 через Alt-0171 и Alt-0187. Эта возможность была еще в ДОС — держишь Alt и цифрами набираешь код символа. Про фар не знаю, но вряд ли там упустили эту фичу. Просьба к пользователям фара подтвердить.

FAR — консольное приложение. ANSI версия гробит и лапки и длинные тире. Причём гробит основательно — заменяет на "<", ">" и "-".
И ещё момент: Немерль должен собираться (и редактироваться) под линуксами и макосами. И там и там туго с 1251.

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

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

БП>Первый же дятел с не-уникодным far или total commander или notepad++ или что там ещё бывает угробит такую цивилизацию.

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

ЗЫ

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

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

R>Простите что вмешиваюсь, но как насчёт варианта влада без стрелочек, но с палочками
R>Вот так:

R>

R>class MyClass|T| : IMyInterface|T|
R>{
R>}
R>

Плохо. "|" уже сильно задействован в других констуркциях. Конфликтов будет еще больше.

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

БП>Первый же дятел с не-уникодным far или total commander или notepad++ или что там ещё бывает угробит такую цивилизацию.

А что за проблемы с юникодом у notepad++? Сцинтилла вполне себе дружит с юникодом

Здравствуйте, VladD2!

Я поддерживаю Cyberax и тоже голосую за вариант с ``.

VD>Можно сказать, что это разновидность скобок. Пойдет как вариант, но как-то их совсем плохо видно.

"Плохо видно" — уже субъективный вариант. Против остальных вариантов были более веские аргументы, такие как оверхед для двухсимвольных скобок или аналогичность решения в D текущему решению в Nemerle.

Но у `` есть ряд плюсов: нет конфликтов с существующими конструкциями, можно набрать на клавиатуре, не требуется unicode поддержка у редактора кода.

VD>Нужно ли делать это до выпуска версии 1.0 или отложить смену синтаксиса до будущей версии?

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

VD>Делать ли такую смену в виде ключа компиляции допускающего как квадратные скобки с точкой (как принято сейчас), так и новые скобки?

Насколько я понял, новый синтаксис обсуждается для того, чтобы в конечном счете сделать алгоритм вывода типов более быстрым и простым. Если поддерживать оба варианта, алгоритма будет два, получается copy-paste со всеми вытекающим проблемами. Если делать ломающие изменения, то в отдельной версии, одна текущая "стабильная", а другая "экспериментальная" Nemerle2.

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

ВВ>А что за проблемы с юникодом у notepad++? Сцинтилла вполне себе дружит с юникодом

С каких это пор?