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

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

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

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

N>Если убрать ! и потребовать вложенные сконструированные типы брать в скобки, то получится вариант Хаскеля, который минималистичен, по-своему красив, но требует опеределенной привычки. Он допускает частичное применение, хорошо гармонирует с вызовом функций вида f x. Но я не уверен, насколько это хорошо выписыватся в идеологию и грамматику немерле.

Ты такое имеешь в виду?

List<int,(List<int,int>)>

Я так понимаю, это все равно приведет к неоднозначности в грамматике Немерле. Собственно, нынешнее list.[T] не спроста появилось.

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

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

Я считаю, что если человек основывает выбор языка на лексических предпочтения, а не на возможностях и удобстве использования языка, то ему со мной не по пути. Споры "скобки vs. begin/end" — это развлечение для идиотов. Я в нем участвовать не собираюсь.
При этом я не хочу плевать на пользователей, их вкусы и мнение. Но если выбор идем между большей однозначностью и удобстве в использовании, то разговор о синтаксических предпочтениях отдельных личностей идет в лес.

VD>>Ну, а точки тебе понятны? Они не трогают твое чувство прекрасного?

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

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

IT>Меня кстати, ещё трогал mutable и помнится я предлагал заменить его на var. Но со временем я понял, что его излишняя многословность даже на пользу. А [] и .[] меня до сих пор напрягают. Но это лучше, чем <|T|>. Это меня точно бесить будет.

Я что-то не пойму почему тебя не бесят .[T], но бесят <|T|> ?
А скажем, [|T|] тебя бесят?
Вообще, ты можешь как-то конкретизировать, что тебе не нравится то?

VD>>В принципе конечно есть варианты. Например, можно описывать параметры типов как в "D":
VD>>[c#]
VD>>Method!T() : T { ... }
VD>>Method!(T1, T2)(x : T1) : T2 { ... }

IT>Если уж на то пошло, то может такой вариант подойдёт.

А на чем все это основано то? По мне так такой синтаксис не блещет красотой.

IT>1. Заменить .[] на ![]. При этом можно даже везде в теле методов требовать обязательного !.
IT>2. В объявлении методов разрешить как [], так и ![]. Там ведь никаких неоднозначностей нет.

Ага. Точно разрешить и так и эдак и пусть народ изголяется. Это уже точно кривое решение.

IT>>>Давай изуродуем язык всякими <|T|>. Он, конечно, останется однозначный, только после этого нафиг никому не нужный.
VD>>Я на 100% уверен, что при наличии реальных достоинств на подобное "уродство" никто даже внимания не обратит.

IT>А я уже 'никто'?

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

IT>>>А кто тебе сказал, что <|T|> это лёгкость чтения?
VD>>Это очевидно. Мне не нужно думать индексер это, выражение или имя. Я точно буду знать, что имя. Учитывая, что явное описание параметров нужно очень редко, то тут и думать не о чем.

IT>Тебе сначала нужно будет распарсить эти козябры глазами, а уже потом не думать. Например, квазицитирование легко читается только при наличии специальной подстветки в студии и использовании пробелов для выделения того, что внутри скобок. Для улучшения читабельности тебе придётся всё время писать не <|T|>, а <| T |>, т.к. <|T|> читается совсем отвратительно.

Чушь это. Читается отлично. Просто ты пока не привык. Учитывая, что еще подсветка синтаксиса будет, так вообще проблем не вижу. Можно даже фон подкрашивать.

IT>Значит надо думать вокруг [] и замены точки на что-нибудь другое.

Пойдет [| |] ? За одно язык переменуем в [||]

IT>Ты же ведь говоришь о языке не только для удобства парсера, но ещё и для удобства людей, правильно?

Правильно.

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

Это из пальца высосанно. А то что неудобны следствия текущего решения — это факт.

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

Я вижу банальный каприз. В том же F# используют разные сочетания скобок. В том числе и <| |>, но не для типов, а для разных компрешеншонов. И никто, никогда не сказал, что это уродство.

VD>>Повторяю последний раз. Мое мнение: внутренняя не однозначность намного хуже непохожетси на С++! И тут выбора нет.

IT>Тогда ищи другое решение, но не <|T|>.

Ну, тебя не устраивает ты и предлагай.

Мне в общем-то по барабану. Двухсимвольные скобки меня вполне устраивают. Они однозначны и хорошо читаются. Ты же считаешь, то они плохо читаются. Вот и предложи, то что по-твоему читается лучше. Но это не должны быть ни [ ], ни < >.

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

VD>Пойдет [| |] ? За одно язык переменуем в [||]

Переименуете Немерле в Боян?

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

[Плевки в пользователей поскипаны]

VD>Мне в общем-то по барабану. Двухсимвольные скобки меня вполне устраивают. Они однозначны и хорошо читаются. Ты же считаешь, то они плохо читаются. Вот и предложи, то что по-твоему читается лучше. Но это не должны быть ни [ ], ни < >.

![T]

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

IT>Для аккордов лучше подойдёт такое: [:||||:]

Можно еще смайликами:

def a = A[:int, int:];
def b = A<[int, int]>;
def b = A(:int, int:);

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

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

N>>Если убрать ! и потребовать вложенные сконструированные типы брать в скобки, то получится вариант Хаскеля, который минималистичен, по-своему красив, но требует опеределенной привычки. Он допускает частичное применение, хорошо гармонирует с вызовом функций вида f x. Но я не уверен, насколько это хорошо выписыватся в идеологию и грамматику немерле.

ВВ>Ты такое имеешь в виду?

ВВ>List<int,(List<int,int>)>

Нет, вот такое:

Maybe Bool
Maybe (Maybe Bool)
Map (Map Int Int) (Maybe String)

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

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

F>Как по мне, так лучше вообще ничего не менять, чем менять на аццкие двойные скобки.

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

Можно ещё вариант D рассмотреть. В общем, ! смотрится гораздо лучше. Тогда любой из следующих вариантов в принципе по барабану:

!<T>
![T]
!(T)

А если разрешить в объявлении не использовать !, то вообще нормуль будет.

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

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

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

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

IT>>2. В объявлении методов разрешить как [], так и ![]. Там ведь никаких неоднозначностей нет.

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

Дело в том, что в объявлении-то всегда их писать приходится, они не выводятся. Поэтому должна быть возможность писать коротко. То есть, или и то и другое разрешать, или только []

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

IT>!<T>
IT>![T]
IT>!(T)

Мне из этих вариантов первый не нравится эстетически, остальные два — одинаково нравятся.

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

VD>Приветствуются любые мысли!

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

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

N>Влад, ты еще поясни, предлагается менять синтаксис и при определении, и при вызове?

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

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

VD>>То есть умными людьми являются только те, что высказывают мнение сходное с тывоим?

IT>Мы здесь все умные, просто явно я это говорю не про всех

Да. Явно, не про всех.

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

N>Дело в том, что в объявлении-то всегда их писать приходится, они не выводятся. Поэтому должна быть возможность писать коротко. То есть, или и то и другое разрешать, или только []

О какой краткости идет речь? Один символ на класс/метод?

И за это придется платить тем, что объяснять новичкам, что мол здесь мы "заворачиваем", а здесь нет?

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

KV>А почему бы не использовать просто круглые скобки, как и в случае аргументов-значений, на основании логики типа "и те и другие являются неизменяемым списком аргументов, специфицирующих ту или иную сущность языка (обощенные типы в одном случае и вызываемые типы в другом)"?

Потому что a(b)(c) уже сейчас является валидным синтаксисом, и может возникнуть неоднозначность.

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

Лично мне импонирует вариант с лапками. То, что их нет на клавиатуре, не такая уж и проблема, забиндить можно. Зато будет и однозначно, и похоже на дорогой сердцу С++'ников и C#'истов синтаксис, и одиночный символ вместо двух, что облегчает восприятие (мне во всяком случае).

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

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

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

IT>>>2. В объявлении методов разрешить как [], так и ![]. Там ведь никаких неоднозначностей нет.

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

N>Дело в том, что в объявлении-то всегда их писать приходится, они не выводятся. Поэтому должна быть возможность писать коротко. То есть, или и то и другое разрешать, или только []

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

abstract class C[T] : Dictionary![ List![T] ] {
  abstract foo[Q] (x : Q) : C![T];
}
def t = C ();
t.Add (List![int] ());
_ = null is List![int];
def hardTypeFun (x : List![_]) { ... };

То есть императивно-агрессивный знак ! обозначает "инстанциацию" и используется везде, кроме введения новых generic-аргументов в объявлениях generic классов или методов. Причём вполне интуитивно, что подсказка для типа и "инстанциация" связаны друг с другом, чем можно объяснить необязательность ![] в выражениях.

За вариант пока не голосую, но выглядит неплохо.

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

ИД>Есть нюанс, разный синтаксис должен очень просто объясняться.

+1

ИД>Пока что только такое приходит в голову:
ИД>

ИД>abstract class C[T] : Dictionary![ List![T] ] {
ИД>  abstract foo[Q] (x : Q) : C![T];
ИД>}
ИД>def t = C ();
ИД>t.Add (List![int] ());
ИД>_ = null is List![int];
ИД>def hardTypeFun (x : List![_]) { ... };
ИД>

ИД>То есть императивно-агрессивный знак ! обозначает "инстанциацию" и используется везде, кроме введения новых generic-аргументов в объявлениях generic классов или методов. Причём вполне интуитивно, что подсказка для типа и "инстанциация" связаны друг с другом, чем можно объяснить необязательность ![] в выражениях.

ИД>За вариант пока не голосую, но выглядит неплохо.

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

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

abstract class C[T] : Dictionary![ List![T] ] 
{
  abstract foo[Q] (x : Q) : C![T];
}

def t = C ();

t.Add (List!()); // ссылка на конструктор
_ = null is List!; // аналогично List![_] но допускает и тип без параметр типов

NamespaceA.Type1!.Type2! // четко указывает, что мы имеем дело не со свойством, а с типом (Type2) причем он объявлен не в пространстве имен, а вложен в другой тип (Type1).

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

KV>А почему бы не использовать просто круглые скобки, как и в случае аргументов-значений, на основании логики типа "и те и другие являются неизменяемым списком аргументов, специфицирующих ту или иную сущность языка (обощенные типы в одном случае и вызываемые типы в другом)"?

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