Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 15:23
Оценка:
Практика показывает, что неоднозначность между синтаксисом индексации:
some[index]

и синтаксисом аргументов типов
List[int]

создает ряд проблем.
В общем-то, вывод типов Немерла с ними справляется, но все же было бы лучше избавиться от этих пробелем. Это позволило бы:
1. Сделать алгоритм вывода типов более быстрым и простым.
2. Избавиться от уродливой точки, которую иногда нужно ставить перед аргументами типа.
3. Улучшить автодополнение при вводе значений в параметрах индексаторов.
4. Облегчить чтение кода содержащего явное указание параметров типов и индексаторов.

Собственно сделать это не сложно. Но есть три вопроса:
1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.
2. Нужно ли делать это до выпуска версии 1.0 или отложить смену синтаксиса до будущей версии?
3. Делать ли такую смену в виде ключа компиляции допускающего как квадратные скобки с точкой (как принято сейчас), так и новые скобки?

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

06.11.11 18:49: Перенесено из 'Nemerle'
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 15:30
Оценка: +3
Здравствуйте, VladD2, Вы писали:

VD>Собственно сделать это не сложно. Но есть три вопроса:

VD>1. Какой синтаксис скобок выбрать для этого?

Стандартный для С-подобных языков: <T>.

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




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


Если чистить язык от подобных детских болезней, то лучше на более ранней стадии.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 15:34
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Кстати, можно на старый синтаксис просто выдавать предупреждение какое-то время. Ну а потом 'кто не спрятался'.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 16:10
Оценка:
Здравствуйте, IT, Вы писали:

IT>Стандартный для С-подобных языков: <T>.


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

Я склоняюсь к синтаксису <| |> он ближе всего к сишному и при этом не очень мозолит глаз.

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


IT>


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


IT>Если чистить язык от подобных детских болезней, то лучше на более ранней стадии.


Это как-то расходится с ответом "хз" на второй вопрос.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 16:26
Оценка: +4
Здравствуйте, VladD2, Вы писали:

IT>>Стандартный для С-подобных языков: <T>.


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


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

VD>Я склоняюсь к синтаксису <| |> он ближе всего к сишному и при этом не очень мозолит глаз.


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

IT>>Если чистить язык от подобных детских болезней, то лучше на более ранней стадии.

VD>Это как-то расходится с ответом "хз" на второй вопрос.

Считай это как мысли вслух.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 16:42
Оценка:
Здравствуйте, IT, Вы писали:

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


Можно, это называется C#. Без макросов конечно, и сприколами вроде изменения смысла выражения от появления в нем скобок, но зато очень привычное.

VD>>Я склоняюсь к синтаксису <| |> он ближе всего к сишному и при этом не очень мозолит глаз.


IT>Вот только этого уродства не надо.


Очень аргументировано. Узнаю IT. Кроме привычек еще что-то есть?

IT>Лучше тогда оставить как есть.


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

IT> Я думаю, если что-то и менять, то только на <T>. От любого другого изменения будет только ещё хуже. Все эти двойные скобки — экзотика и смотрятся довольно мрачно. В квази-цитировании это ещё куда ни шло, но в остальных случаях, даже в твоих строках, это уже перебор.


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

Надо не забывать, что Немерле — это язык с изменяемым синтаксисом и мошьным выводом типов. Это куда более удобно нежели привычких С++-ный синтаксис (который на поверку еще то уродство). Это накладывает определенные ограничения. Одно из них — требование однозначной грамматики.

По мне так качество работы компилятора и легкость чтения важнее привычности синтаксиса. В конце концов в Немерле уже сделано несколько отступлений от традиций. Это и объявление типов. И отсутствие управляющих конструкций. И использование тех же [ ] вместо < >. Так почему бы не сделать еще одно отступление, если от этого будет реальная практическая польза? В конце концов мест где в коде нужно явно указывать аргументы типов не так много. Так что код мало чем изменится. В описании методов и типов два лишних символа погоды не сделают. Так в чем тогда вопрос?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.09 17:02
Оценка: 13 (2) +1
Здравствуйте, VladD2, Вы писали:

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


Это сложный вопрос.
Мне больше всего нравится, как сделано в Scala: типы-параметры [], вызов индексатора ()
Это очень логично, потому что вызов индексатора вполне можно представлять себе как вызов функции, аргументы которой — это индексы.
Re[5]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 17:19
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>Можно, это называется C#. Без макросов конечно, и сприколами вроде изменения смысла выражения от появления в нем скобок, но зато очень привычное.

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

VD>>>Я склоняюсь к синтаксису <| |> он ближе всего к сишному и при этом не очень мозолит глаз.

IT>>Вот только этого уродства не надо.
VD>Очень аргументировано. Узнаю IT. Кроме привычек еще что-то есть?

А что здесь ещё может быть кроме предпочтений? У тебя есть логическое объяснение почему <|T|> лучше <T>. Для моего утончённого чувства прекрасного <|T|>, как и любые другие двойные скобки, представляются настоящим уродством. А твоё объяснение про какие-то там проблемы в парсере не будут понятны и приняты подавляющим большинством пользователей языка. К тому же не такие они уж и большие проблемы.

IT>> Я думаю, если что-то и менять, то только на <T>. От любого другого изменения будет только ещё хуже. Все эти двойные скобки — экзотика и смотрятся довольно мрачно. В квази-цитировании это ещё куда ни шло, но в остальных случаях, даже в твоих строках, это уже перебор.


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


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

VD>Надо не забывать, что Немерле — это язык с изменяемым синтаксисом и мошьным выводом типов. Это куда более удобно нежели привычких С++-ный синтаксис (который на поверку еще то уродство). Это накладывает определенные ограничения. Одно из них — требование однозначной грамматики.


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

VD>По мне так качество работы компилятора и легкость чтения важнее привычности синтаксиса.


А кто тебе сказал, что <|T|> это лёгкость чтения? Лёгкость чтения как раз <T>. Это легко читать и к тому же привычно, что является большим плюсом, а не минусом, как ты тут хочешь нам доказать.

VD>В конце концов в Немерле уже сделано несколько отступлений от традиций. Это и объявление типов. И отсутствие управляющих конструкций. И использование тех же [ ] вместо < >. Так почему бы не сделать еще одно отступление, если от этого будет реальная практическая польза?


Что значит реальная практическая? То, что ты предлагаешь называется затычка, а не реальная практическая польза. Как проблему решить мы не знаем, давайте заткнём дырку чем-нибудь. Сначала её заткнули [T], потом .[T], теперь <|T\>. Я тебе, кстати, ещё пару лет назад говорил, что [T] — это плохо. Сегодня ты это утверждаешь сам. Ещё через пару лет до тебя дойдёт, что <|T|> ничем не лучше.

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


А зачем ты его тогда вообще поднял? Вывод типов, конечно, помогает, но проблему не решает ни в том, ни в другом случае.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Предлагаю подобрать скобки для типов...
От: Cyberax Марс  
Дата: 14.12.09 17:28
Оценка:
Здравствуйте, VladD2, Вы писали:

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

А зачем скобки?
List`int`
Sapienti sat!
Re[2]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 17:39
Оценка:
Здравствуйте, nikov, Вы писали:

N>Это сложный вопрос.

N>Мне больше всего нравится, как сделано в Scala: типы-параметры [], вызов индексатора ()
N>Это очень логично, потому что вызов индексатора вполне можно представлять себе как вызов функции, аргументы которой — это индексы.

Скала базируется на яве в кторой индексеров просто нет (только встроенные для массивов). В дотнете же они есть как отдельная сущность.

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

Ну, да посмотрим, что скажут другие.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 17:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>А зачем скобки?
C>
C>List`int`
C>


Можно сказать, что это разновидность скобок. Пойдет как вариант, но как-то их совсем плохо видно. Можно конечно использовать « » но их нет на клавиатуре, так что будут проблемы со вводом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Предлагаю подобрать скобки для типов...
От: Ilya10k Россия  
Дата: 14.12.09 18:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Практика показывает, что неоднозначность между синтаксисом индексации:

VD>
VD>some[index]
VD>

VD>и синтаксисом аргументов типов
VD>
VD>List[int]
VD>

VD>создает ряд проблем.
VD>В общем-то, вывод типов Немерла с ними справляется, но все же было бы лучше избавиться от этих пробелем. Это позволило бы:
VD>1. Сделать алгоритм вывода типов более быстрым и простым.
VD>2. Избавиться от уродливой точки, которую иногда нужно ставить перед аргументами типа.
VD>3. Улучшить автодополнение при вводе значений в параметрах индексаторов.
VD>4. Облегчить чтение кода содержащего явное указание параметров типов и индексаторов.

Отлично!

VD>Собственно сделать это не сложно. Но есть три вопроса:

VD>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.
Не имеет принципиального значения.

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

Как можно раньше.

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

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

VD>Приветствуются любые мысли!
... << RSDN@Home 1.2.0 alpha 4 rev. 1238>>
Re: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.09 18:13
Оценка:
Здравствуйте, VladD2, Вы писали:

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


И ещё, в случае breaking changes (включая случай поддержки старого синтаксиса как deprecated), было бы очень желательно предоставить утилиту для автоматической миграции кода на новый синтаксис.
Re[2]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 14.12.09 18:20
Оценка: +1
N>И ещё, в случае breaking changes (включая случай поддержки старого синтаксиса как deprecated), было бы очень желательно предоставить утилиту для автоматической миграции кода на новый синтаксис.

Есть ли смысл тратить на это силы которых и так немного? Даже большой проект, если он компилировался до breaking changes — после них можно будет пофиксить от силы в человеко-час-два. А такую утилиту придётся писать минимум день.
Re[3]: Предлагаю подобрать скобки для типов...
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 14.12.09 18:23
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, да посмотрим, что скажут другие.


На мой взгляд, в порядке предпочтения идут варианты:

1. Cyberax (`T`)
2. Nikov (круглые скобки для индексаторов)
3. IT (<T>)
4. VladD2 (<|T|>)

Аргументы за и против все те же, что уже были преведены.
Двойные скобки слишком выделяются. Для ключевой особенности языка — квазицитирования — это ещё ничего, но для обычных аргументов типа, перебор.
Ce n'est que pour vous dire ce que je vous dis.
Re: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 14.12.09 18:30
Оценка: 29 (1) +4
VD>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.

Если менять то только на простые угловые скобки <T>. Основные проблемы при миграции с C# на Nemerle — это квадратные скобки в generic'aх и постфиксная запись типов. Но если к записи типов не просто привыкаешь, но и в итоге понимаешь что это куда лучше чем в C#, то с квадратными скобками всё не так однозначно.
Двойные скобки — лучше оставить для макросов, каких-то собственных операторов и т.п. Кошмарить ими программиста который писал на C# — это снижать популярность языка.

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


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

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


Нет, время на это тратить не стоит. Мелкий проект — может спокойно жить и на старой версии компилятора. А по моим прикидкам — даже крупный проект реально перевести на новый синтаксис врукопашную от силы за час или два. Особенно учитывая что generic-и реально не сильно то и объявляются — хвала выводу типов.
Re[2]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 18:36
Оценка:
Здравствуйте, hi_octane, Вы писали:

_>Если менять то только на простые угловые скобки <T>. Основные проблемы при миграции с C# на Nemerle — это квадратные скобки в generic'aх и постфиксная запись типов. Но если к записи типов не просто привыкаешь, но и в итоге понимаешь что это куда лучше чем в C#, то с квадратными скобками всё не так однозначно.

_>Двойные скобки — лучше оставить для макросов, каких-то собственных операторов и т.п. Кошмарить ими программиста который писал на C# — это снижать популярность языка.

Вот, Влад, послушай умного человека.

_>Нет, время на это тратить не стоит. Мелкий проект — может спокойно жить и на старой версии компилятора. А по моим прикидкам — даже крупный проект реально перевести на новый синтаксис врукопашную от силы за час или два. Особенно учитывая что generic-и реально не сильно то и объявляются — хвала выводу типов.


Проблема не столько в использовании <|T|> там, где помогает вывод типов, сколько там где он не помогает:

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

Имхо, бредятина.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 18:41
Оценка: 1 (1) +1
Здравствуйте, Don Reba, Вы писали:

DR>На мой взгляд, в порядке предпочтения идут варианты:


DR>1. Cyberax (`T`)


С трудом нашёл как ввести этот символ с клавиатуры. Да и смахивает больше на строковый литерал, чем на параметр типа.

DR>2. Nikov (круглые скобки для индексаторов)


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

DR>3. IT (<T>)


А здесь привычки не важны.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 14.12.09 18:41
Оценка:
Здравствуйте, VladD2, Вы писали:

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


А обязательно нужен синтаксис именно в стиле "обрамления" параметра? Если уж пошла такая пьянка с <| |>, то можно покреативить и в таком ключе:

List?int
List!int
List@int

Еще мне нравится List*int, но такой синтаксис вроде как занят.
Re[2]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 18:42
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>List?int

ВВ>List!int
ВВ>List@int

ВВ>Еще мне нравится List*int, но такой синтаксис вроде как занят.


А для более чем одного параметра?
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 18:42
Оценка: 1 (1) +1
Здравствуйте, IT, Вы писали:

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


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

В шарпе проблема неоднозначности решается введением эвристики:

7.5.4.2 Grammar ambiguities
The productions for simple-name (§7.5.2) and member-access (§7.5.4) can give rise to ambiguities in the grammar for expressions. For example, the statement:
F(G<A,B>(7));
could be interpreted as a call to F with two arguments, G < A and B > (7). Alternatively, it could be interpreted as a call to F with one argument, which is a call to a generic method G with two type arguments and one regular argument.
If a sequence of tokens can be parsed (in context) as a simple-name (§7.5.2), member-access (§7.5.4), or pointer-member-access (§18.5.2) ending with a type-argument-list (§4.4.1), the token immediately following the closing > token is examined. If it is one of
( ) ] } : ; , . ? == !=
then the type-argument-list is retained as part of the simple-name, member-access or pointer-member-access and any other possible parse of the sequence of tokens is discarded. Otherwise, the type-argument-list is not considered to be part of the simple-name, member-access or pointer-member-access, even if there is no other possible parse of the sequence of tokens. Note that these rules are not applied when parsing a type-argument-list in a namespace-or-type-name (§3.8). The statement
F(G<A,B>(7));
will, according to this rule, be interpreted as a call to F with one argument, which is a call to a generic method G with two type arguments and one regular argument. The statements
F(G < A, B > 7);
F(G < A, B >> 7);
will each be interpreted as a call to F with two arguments. The statement
x = F < A > +y;
will be interpreted as a less than operator, greater than operator, and unary plus operator, as if the statement had been written x = (F < A) > (+y), instead of as a simple-name with a type-argument-list followed by a binary plus operator. In the statement
x = y is C<T> + z;
the tokens C<T> are interpreted as a namespace-or-type-name with a type-argument-list.


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


VD>>>>Я склоняюсь к синтаксису <| |> он ближе всего к сишному и при этом не очень мозолит глаз.

IT>>>Вот только этого уродства не надо.
VD>>Очень аргументировано. Узнаю IT. Кроме привычек еще что-то есть?

IT>А что здесь ещё может быть кроме предпочтений? У тебя есть логическое объяснение почему <|T|> лучше <T>.


Естественно, есть! x<|y|> — однозначно тип. А x<T> нет. x<|y, z|>a — однозначно ошибочно записанный тип, а x<y, z>a — допустимое (в некоторых контекста) выражение.

IT>Для моего утончённого чувства прекрасного <|T|>, как и любые другие двойные скобки, представляются настоящим уродством. А твоё объяснение про какие-то там проблемы в парсере не будут понятны и приняты подавляющим большинством пользователей языка. К тому же не такие они уж и большие проблемы.


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

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

def x = Method!int(Method!(string, int)("aa"));

Или, как предложил Ников, использовать для индексеров иснаксис круглых скобок (как в Скале и ВБ), а квадратные использовать только для типов.

Но боюсь, что это будет еще не привычнее для людей.

В варианте с двойными скобками все что прийдется объяснить тем кто знает С++-подобный язык это, что вместо < > нужно использовать <| |>.
Method<|T|>() : T { ... }
Method<|T1, T2|>(x : T1) : T2 { ... }

def x = Method<|int|>(Method<|string, int|>("aa"));

В 99% случае явное указание параметров типов можно будет опустить:
Method<|T|>() : T { ... }
Method(x : T1) : T2 { ... }

def x = Method(Method("aa"));

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

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


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


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

VD>>Надо не забывать, что Немерле — это язык с изменяемым синтаксисом и мошьным выводом типов. Это куда более удобно нежели привычких С++-ный синтаксис (который на поверку еще то уродство). Это накладывает определенные ограничения. Одно из них — требование однозначной грамматики.


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


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

VD>>По мне так качество работы компилятора и легкость чтения важнее привычности синтаксиса.


IT>А кто тебе сказал, что <|T|> это лёгкость чтения?


Это очевидно. Мне не нужно думать индексер это, выражение или имя. Я точно буду знать, что имя. Учитывая, что явное описание параметров нужно очень редко, то тут и думать не о чем.

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


Да, я не спорю, что привычность — это плюс. Но тут как опять встает выбор. Или привычность, или качество. Выбор < >, сделанный Страуструпом создан множество проблем. Это и лексическая неоднозначность ">" и ">>". И грамматическая неоднозначность между именем типа и выражением. В С++ первая проблема вообще не решалась, а вторая решалась за счет контекстной зависимости и обязательного объявления всех типов выше их использования. Это полная задница. В Шарпе ввели эвристики, но они не безупречны. В итоге поляки отказались от использования < >. Мне кажется к этому вопросу даже не стоит возвращаться.

VD>>В конце концов в Немерле уже сделано несколько отступлений от традиций. Это и объявление типов. И отсутствие управляющих конструкций. И использование тех же [ ] вместо < >. Так почему бы не сделать еще одно отступление, если от этого будет реальная практическая польза?


IT>Что значит реальная практическая?


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

IT>То, что ты предлагаешь называется затычка, а не реальная практическая польза.


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

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

IT>Как проблему решить мы не знаем, давайте заткнём дырку чем-нибудь.


Как раз как решить мы знаем. А вот вы занимаетесь откровенной демагогией.

IT>Сначала её заткнули [T], потом .[T], теперь <|T\>. Я тебе, кстати, ещё пару лет назад говорил, что [T] — это плохо. Сегодня ты это утверждаешь сам. Ещё через пару лет до тебя дойдёт, что <|T|> ничем не лучше.


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

Повторяю последний раз. Мое мнение: внутренняя не однозначность намного хуже непохожетси на С++! И тут выбора нет.
"." действительно была затычкой. Решение крайне не красивое и живущее исключительно из-за того, что реально параметры типов задавать в выражениях явно приходится крайне редко. Многие на это указывали. Про то что плохо <[ или <# я слышал только от тебя.
Самое же парадоксальное, что в борьбе с этой не красивостью поляки снова пошли на ноднозначность и стали бороться с ней путем спекулятивных типизаций, т.е., по сути, привязкой к контексту!

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


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


Я уже 100 раз повторился. "." не обязательная. Это приводит к тому, что один хрен в компиляторе используется эвристика (спекулятивная типизация). Это приводит к тому числу проблем, что их даже трудно описать.

Вот недавно я заметил, что комлит в коде вроде:
tbl[ro$]

где "$" используется для указания позиции ввода, выдает неверный результат. В списке дополнения есть только типы. Почему? Да потому, что блин, чтобы понять что такое "tbl[ro]" компилятор выполняет спекулятивную типизацияю. При этом "tbl[ro]" пытаются стипизировать как тип. Если это прокатит, то пляски продолжаются в одну сторону, если нет, то в другую. Но в любом случее пляски продолжаются только если все подвыражения корректны. А при комплите "ro" — это не законченное выражение. Оно никогда не стипизируется ни как тип, ни как переменная. В результате полноценного комплита получить не удается.
То же происходит в случае ошибки. Неоднозначность приводитк к тому, что выдать внятной диагностики не удается.

В общем, чем меньше спекуляций при типизации, тем лучше.

Мое мнение — лучше ввести составные скобки.
Как вариант, конечно можно оставить точку, но сделать ее явной. Чтобы ее нужно было ставить всегда когда описываешь список параметров типов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 14.12.09 18:47
Оценка:
Здравствуйте, IT, Вы писали:

IT>А для более чем одного параметра?


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

List!int-int-int

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

List!int*int*int

Или вообще сделать такой синтаксис:

"TypeName" "!" ( Type | ["Type"] )

т.е. будет

List ! int int int
List!int int int

без всяких лишних знаков.
Re[5]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 18:47
Оценка:
Здравствуйте, IT, Вы писали:

DR>>1. Cyberax (`T`)


IT>С трудом нашёл как ввести этот символ с клавиатуры. Да и смахивает больше на строковый литерал, чем на параметр типа.


Согласен. Плюс еще одна проблема. Немерле уже позовлят использовать ' в именах идентификаторов и символах. Его будет очень легко перепутать с `.

DR>>2. Nikov (круглые скобки для индексаторов)


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


Влад еще и реалист.
1. Поменять привычку < > на <| |> — плевое дело. Чистая механика. А вот индексировать массивы круглыми скобками — это уже серьезный шаг.
2. Перелапатить компилятор на круглые скобки будет намного сложнее. А фактор соложности тоже никто не отмеля. Я не могу потратить еще пол года на это.

DR>>3. IT (<T>)


IT>А здесь привычки не важны.


Не понял. Это твой вариант!
Он не проходит, так как менять одну неоднозначность на другую (большую) бессмысленно и даже вредно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 14.12.09 18:50
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>В принципе конечно есть варианты. Например, можно описывать параметры типов как в "D":

VD>
VD>Method!T() : T { ... }
VD>Method!(T1, T2)(x : T1) : T2 { ... }

VD>def x = Method!int(Method!(string, int)("aa"));
VD>


Голосую за синтаксис а ля D Я бы даже догадался, что это генерик, хотя D не знаю.
Re[3]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 18:51
Оценка:
Здравствуйте, hi_octane, Вы писали:

N>>И ещё, в случае breaking changes (включая случай поддержки старого синтаксиса как deprecated), было бы очень желательно предоставить утилиту для автоматической миграции кода на новый синтаксис.


_>Есть ли смысл тратить на это силы которых и так немного? Даже большой проект, если он компилировался до breaking changes — после них можно будет пофиксить от силы в человеко-час-два. А такую утилиту придётся писать минимум день.


Согласен. Ворнингов должно хватить. В прочем, конвертер наврено не будет уж очень сложным. Позиции всех "неверных" токенов ведь будут. А махнуть их не глядя — это уже не сложно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 18:55
Оценка:
Здравствуйте, IT, Вы писали:

IT>Вот, Влад, послушай умного человека.


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

IT>Проблема не столько в использовании <|T|> там, где помогает вывод типов, сколько там где он не помогает:


IT>
IT>class MyClass<|T|> : IMyInterface<|T|>
IT>{
IT>}
IT>

IT>Имхо, бредятина.

С последним согласен. Рассуждения действительно не выдерживают критики.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 14.12.09 19:00
Оценка: 4 (1)
Здравствуйте, VladD2, Вы писали:

VD>С последним согласен. Рассуждения действительно не выдерживают критики.


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

Если уж < > не получается, то лучше уж брать что-то совсем другое. А вариант D тебе не нравится?
Re[6]: Предлагаю подобрать скобки для типов...
От: Иванков Дмитрий Россия  
Дата: 14.12.09 19:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>1. Поменять привычку < > на <| |> — плевое дело. Чистая механика. А вот индексировать массивы круглыми скобками — это уже серьезный шаг.

Сорри, что пока про мелочи, но аккорд <||> на клавиатуре заметно сложнее [], <> и .[], в нём четыре шифт-клавиши (из двух правых углов клавы, на моей по крайне мере).
Re[7]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 19:26
Оценка: -3
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Сорри, что пока про мелочи, но аккорд <||> на клавиатуре заметно сложнее [], <> и .[], в нём четыре шифт-клавиши (из двух правых углов клавы, на моей по крайне мере).


Мне кажется, что это совсем мелочи. Кому это важно, забиндит себе клав.скоращения. Скажем те же Ctrl+<
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 19:27
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Честно, мне тоже <| |> не очень нравится. Не проблема иметь синтаксис, непохожий на Схх. Но в данном случае проблема как раз в том, что синтаксис похож. И в то же время не похож. И вот эти самые "|" начинают как-то цеплять глаз. Ибо в чем-то твои оппоненты правы — конечный пользователь не будет же думать о проблемах парсера, он будет смотреть на синтаксис и видеть что "|", очевидно, лишнее.


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


Он мне меньше нравистя. Да и от текущего .[ ] он не сильно отличается. Тоже похоже на подпорку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 19:40
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

VD>>1. Поменять привычку < > на <| |> — плевое дело. Чистая механика. А вот индексировать массивы круглыми скобками — это уже серьезный шаг.

ИД>Сорри, что пока про мелочи, но аккорд <||> на клавиатуре заметно сложнее [], <> и .[], в нём четыре шифт-клавиши (из двух правых углов клавы, на моей по крайне мере).

Собственно за угловые скобки я не держусть. Можно и так: [|int|], и так int# и даже так #int# хотя в таком варианте возникает неоднозначность с препроцессором. Но ее устранить не сложно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.09 19:40
Оценка: +2
Здравствуйте, Воронков Василий, Вы писали:

ВВ>List!int-int-int


ВВ>Опять-таки синтаксис а ля кортежи мне бы тут тоже понравился. Не уверен по поводу неоднозначностей:


ВВ>List!int*int*int


ВВ>Или вообще сделать такой синтаксис:


ВВ>"TypeName" "!" ( Type | ["Type"] )


ВВ>т.е. будет


ВВ>List ! int int int

ВВ>List!int int int

ВВ>без всяких лишних знаков.


Жуть.
Re[7]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 19:40
Оценка: +1
Здравствуйте, VladD2, Вы писали:

IT>>А что здесь ещё может быть кроме предпочтений? У тебя есть логическое объяснение почему <|T|> лучше <T>.

VD>Естественно, есть! x<|y|> — однозначно тип. А x<T> нет. x<|y, z|>a — однозначно ошибочно записанный тип, а x<y, z>a — допустимое (в некоторых контекста) выражение.

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

IT>>Для моего утончённого чувства прекрасного <|T|>, как и любые другие двойные скобки, представляются настоящим уродством. А твоё объяснение про какие-то там проблемы в парсере не будут понятны и приняты подавляющим большинством пользователей языка. К тому же не такие они уж и большие проблемы.


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


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

VD>В принципе конечно есть варианты. Например, можно описывать параметры типов как в "D":

VD>[c#]
VD>Method!T() : T { ... }
VD>Method!(T1, T2)(x : T1) : T2 { ... }

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

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

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

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

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

IT>>А кто тебе сказал, что <|T|> это лёгкость чтения?

VD>Это очевидно. Мне не нужно думать индексер это, выражение или имя. Я точно буду знать, что имя. Учитывая, что явное описание параметров нужно очень редко, то тут и думать не о чем.

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

VD>Да, я не спорю, что привычность — это плюс. Но тут как опять встает выбор. Или привычность, или качество. Выбор < >, сделанный Страуструпом создан множество проблем. Это и лексическая неоднозначность ">" и ">>". И грамматическая неоднозначность между именем типа и выражением. В С++ первая проблема вообще не решалась, а вторая решалась за счет контекстной зависимости и обязательного объявления всех типов выше их использования. Это полная задница. В Шарпе ввели эвристики, но они не безупречны. В итоге поляки отказались от использования < >. Мне кажется к этому вопросу даже не стоит возвращаться.


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

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


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

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


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

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


Тогда ищи другое решение, но не <|T|>.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.09 19:40
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

VD>>В принципе конечно есть варианты. Например, можно описывать параметры типов как в "D":

VD>>
VD>>Method!T() : T { ... }
VD>>Method!(T1, T2)(x : T1) : T2 { ... }

VD>>def x = Method!int(Method!(string, int)("aa"));
VD>>


ВВ>Голосую за синтаксис а ля D Я бы даже догадался, что это генерик, хотя D не знаю.


Да, дишный синтаксис неплох.
Re[4]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 19:42
Оценка: :)))
Здравствуйте, VladD2, Вы писали:

IT>>Вот, Влад, послушай умного человека.

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

Мы здесь все умные, просто явно я это говорю не про всех
Если нам не помогут, то мы тоже никого не пощадим.
Re: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.09 19:43
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Влад, ты еще поясни, предлагается менять синтаксис и при определении, и при вызове?
Re[4]: Предлагаю подобрать скобки для типов...
От: SergASh  
Дата: 14.12.09 19:46
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Или вообще сделать такой синтаксис:


ВВ>"TypeName" "!" ( Type | ["Type"] )


ВВ>т.е. будет


ВВ>List ! int int int

ВВ>List!int int int

Не годится, на месте одного из int может быть другой generic, так что однозначности не добиться. По той же причине не подойдет и синтаксис в стиле кортежей.
Re[7]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 19:46
Оценка: :)))
Здравствуйте, Иванков Дмитрий, Вы писали:

VD>>1. Поменять привычку < > на <| |> — плевое дело. Чистая механика. А вот индексировать массивы круглыми скобками — это уже серьезный шаг.

ИД>Сорри, что пока про мелочи, но аккорд <||> на клавиатуре заметно сложнее [], <> и .[], в нём четыре шифт-клавиши (из двух правых углов клавы, на моей по крайне мере).

Для аккордов лучше подойдёт такое: [:||||:]
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 14.12.09 19:50
Оценка:
Здравствуйте, nikov, Вы писали:

ВВ>>List ! int int int

ВВ>>List!int int int
ВВ>>без всяких лишних знаков.
N>Жуть.

Да ладно, всего-то добавить скобки, и получается синтаксис D, как я тут в соседней ветке обнаружил. А можно и привычные < > сохранить. И получается уже вполне вменяемое:

List!<int,int>
Re[6]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.09 19:55
Оценка: +2
Здравствуйте, Воронков Василий, Вы писали:

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


ВВ>>>List ! int int int

ВВ>>>List!int int int
ВВ>>>без всяких лишних знаков.
N>>Жуть.

ВВ>Да ладно, всего-то добавить скобки, и получается синтаксис D, как я тут в соседней ветке обнаружил. А можно и привычные < > сохранить. И получается уже вполне вменяемое:


ВВ>List!<int,int>


Если убрать ! и потребовать вложенные сконструированные типы брать в скобки, то получится вариант Хаскеля, который минималистичен, по-своему красив, но требует опеределенной привычки. Он допускает частичное применение, хорошо гармонирует с вызовом функций вида f x. Но я не уверен, насколько это хорошо выписыватся в идеологию и грамматику немерле.
Re: Предлагаю подобрать скобки для типов...
От: SergASh  
Дата: 14.12.09 19:58
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Да, и чем раньше все привыкнут к новому синтаксису, тем лучше.

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

Нет, категорически нет. Релиза ещё не было, чего ради делать совместимость с более ранней версией, которая по сути бета? Можно подумать, Влад, тебе не хватает проблем кроме как поддерживать два параллельных синтаксиса.
Re[7]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 14.12.09 19:59
Оценка:
Здравствуйте, nikov, Вы писали:

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


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

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

Я так понимаю, это все равно приведет к неоднозначности в грамматике Немерле. Собственно, нынешнее list.[T] не спроста появилось.
Re[8]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 20:02
Оценка:
Здравствуйте, 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|>.


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

Мне в общем-то по барабану. Двухсимвольные скобки меня вполне устраивают. Они однозначны и хорошо читаются. Ты же считаешь, то они плохо читаются. Вот и предложи, то что по-твоему читается лучше. Но это не должны быть ни [ ], ни < >.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 14.12.09 20:06
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Переименуете Немерле в Боян?
Re[9]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 20:08
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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

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


![T]
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Предлагаю подобрать скобки для типов...
От: Flem1234  
Дата: 14.12.09 20:10
Оценка:
Здравствуйте, IT, Вы писали:

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


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

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




Как по мне, так лучше вообще ничего не менять, чем менять на аццкие двойные скобки.
Re[8]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.09 20:15
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


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


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


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

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


Но этот синтаксис не предназначен, чтобы задавать типы-аргументы при вызове функций — в Хаскеле они всегда выводятся автоматически.
Re[9]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 20:16
Оценка: +3
Здравствуйте, Flem1234, Вы писали:

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


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

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

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

А если разрешить в объявлении не использовать !, то вообще нормуль будет.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 20:18
Оценка: 8 (1)
Здравствуйте, nikov, Вы писали:

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


Кроме того в Хаскеле типы именуются с только с большой буквы, что тоже в свою очередь помогает устранять неоднозначность.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.09 20:20
Оценка: 2 (1)
Здравствуйте, VladD2, Вы писали:

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


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


Дело в том, что в объявлении-то всегда их писать приходится, они не выводятся. Поэтому должна быть возможность писать коротко. То есть, или и то и другое разрешать, или только []
Re[10]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.09 20:22
Оценка: +3
Здравствуйте, IT, Вы писали:

IT>!<T>

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

Мне из этих вариантов первый не нравится эстетически, остальные два — одинаково нравятся.
Re: Предлагаю подобрать скобки для типов...
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 14.12.09 20:36
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[2]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 20:38
Оценка:
Здравствуйте, nikov, Вы писали:

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


На мой взгляд синтаксис определения и вызова должны быть едины.
Вопрос конечно тоже дискутируемый, но моя позиция в данном вопросе очень проста. Чем меньше нужно запоминать и объснять, тем лучше. То, что в одном случае нужно писать одно, а в другом другое — это придется объяснять и запоминать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 20:39
Оценка:
Здравствуйте, IT, Вы писали:

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


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


Да. Явно, не про всех.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 20:43
Оценка:
Здравствуйте, nikov, Вы писали:

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


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

И за это придется платить тем, что объяснять новичкам, что мол здесь мы "заворачиваем", а здесь нет?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.12.09 20:45
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

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


Потому что a(b)(c) уже сейчас является валидным синтаксисом, и может возникнуть неоднозначность.
Re: Предлагаю подобрать скобки для типов...
От: SergASh  
Дата: 14.12.09 20:48
Оценка:
Занятно, в ветке высказываются пока 11 человек, и на основании этих высказываний будет меняться дизайн языка. Может на более широкое обсуждение вынести вопрос? Интересно, в частности, что сами поляки думают по данному поводу.

Лично мне импонирует вариант с лапками. То, что их нет на клавиатуре, не такая уж и проблема, забиндить можно. Зато будет и однозначно, и похоже на дорогой сердцу С++'ников и C#'истов синтаксис, и одиночный символ вместо двух, что облегчает восприятие (мне во всяком случае).
public class Test«P,Q» : IEnumerable«P*Q»
Re[10]: Предлагаю подобрать скобки для типов...
От: Иванков Дмитрий Россия  
Дата: 14.12.09 20:50
Оценка:
Здравствуйте, 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 классов или методов. Причём вполне интуитивно, что подсказка для типа и "инстанциация" связаны друг с другом, чем можно объяснить необязательность ![] в выражениях.

За вариант пока не голосую, но выглядит неплохо.
Re[11]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 21:04
Оценка: 2 (1) +1
Здравствуйте, Иванков Дмитрий, Вы писали:

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


+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).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 21:08
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

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


Потому же почему нельзя использовать [ ], будет конфликтовать с имеющимися конструкции (вызовом функций).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Предлагаю подобрать скобки для типов...
От: SergASh  
Дата: 14.12.09 21:23
Оценка: 2 (1) -2
Здравствуйте, VladD2, Вы писали:

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


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

Или это тоже к неоднозначности приводит?
Re[12]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 21:26
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Вместо typeof?
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Предлагаю подобрать скобки для типов...
От: IT Россия linq2db.com
Дата: 14.12.09 21:32
Оценка:
Здравствуйте, SergASh, Вы писали:

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


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

Сравним:

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

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

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

!MyMethod[T]().BoolField

Здесь ! относится к T или это логическое отрицание?
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.12.09 21:36
Оценка:
Здравствуйте, SergASh, Вы писали:

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

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

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

Это будет конфликт с унарным "!" (логическое "нет"). Он хоть и макросом сделан, новсе же важный оператор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Предлагаю подобрать скобки для типов...
От: Иванков Дмитрий Россия  
Дата: 14.12.09 21:46
Оценка:
Здравствуйте, SergASh, Вы писали:

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

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

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

Свой пойнт в этом есть, но кроме неоднозначности ещё произошёл разрыв ! от [], что может быть не очень удобным при их добавлении в уже написанную строчку.
Re[12]: Предлагаю подобрать скобки для типов...
От: Иванков Дмитрий Россия  
Дата: 14.12.09 21:57
Оценка:
Здравствуйте, VladD2, Вы писали:

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


А, вот с чем неувязка всплывёт тогда с таким позиционированием:
abstract class C[T] : Dictionary![ List![T] ] 
{
  abstract foo[Q] (x : Q) : C![T];
}
...
_ = x.foo![int] (1);


Не фатально конечно, пусть даже ! — тип, а ![] — generic параметры, но идея-то интересная, надо подумать ещё.
Re[12]: Предлагаю подобрать скобки для типов...
От: Мишень-сан  
Дата: 14.12.09 21:59
Оценка:
Здравствуйте, VladD2, Вы писали:

Точка в .[T] скрадывает суть выражения, будет похоже на основной member-of. (List.[int] выглядит некузяво, как будто имя индексера забыли ввести)
![T] выглядит вполне прилично (List![int])
Крышка ^[] будет выделяться даже в неподсвеченном тексте (List^[int])
$[], ?[], @[] маловероятно, что вызовут неоднозначности, потому как почти не используются в других контекстах. (List$[int], List?[int], List@[int])
Как ни странно, преимуществом !() будет тот факт, что его можно набрать в любой раскладке. Тем не менее, круглые скобки я бы не использовал ни в каком виде, сливается с простой группировкой выражений.
Ещё можно подумать об использовании {}, но такой вариант может наплодить ещё больше тараканов, т.к. в сознании слишком многих связан с блоком инструкций.
Re[2]: Предлагаю подобрать скобки для типов...
От: Блудов Павел Россия  
Дата: 15.12.09 00:25
Оценка: 1 (1)
Здравствуйте, SergASh, Вы писали:

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


Первый же дятел с не-уникодным far или total commander или notepad++ или что там ещё бывает угробит такую цивилизацию.
Re[3]: Предлагаю подобрать скобки для типов...
От: Rival Таиланд
Дата: 15.12.09 05:44
Оценка:
Простите что вмешиваюсь, но как насчёт варианта влада без стрелочек, но с палочками
Вот так:

class MyClass|T| : IMyInterface|T|
{
}
«История жизни – это, по существу, развитие сознания, которое завуалировано морфологией.» Пьер Тейяр де Шарден
Re[4]: Предлагаю подобрать скобки для типов...
От: Rival Таиланд
Дата: 15.12.09 06:38
Оценка:
Ещё как варианты

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

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

class MyClass*T* : IMyInterface*T*
{
}
«История жизни – это, по существу, развитие сознания, которое завуалировано морфологией.» Пьер Тейяр де Шарден
Re: Предлагаю подобрать скобки для типов...
От: kitsunekko  
Дата: 15.12.09 07:37
Оценка:
Здравствуйте, VladD2, Вы писали:


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

но больше всего мне нравится как в F# — int list
Re[3]: Предлагаю подобрать скобки для типов...
От: SergASh  
Дата: 15.12.09 08:17
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

БП>Здравствуйте, 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, по крайней мере у меня не получилось. А лапки можно, так что я за лапки голосую
Re[4]: Предлагаю подобрать скобки для типов...
От: Мишень-сан  
Дата: 15.12.09 09:40
Оценка: +4
Здравствуйте, SergASh, Вы писали:

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


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


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


Прикиньте лично для себя, готовы ли Вы биндить две кнопки для этих целей, а потом ещё привыкать к ним. Лично мне кажется, что консерватизм тут уместен. Программный код это всё-таки не документ с рюшечками. Во всяком случае, рюшечки в виде юникодных символов в синтаксисе тут будут явно лишними.
Re[7]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 15.12.09 10:29
Оценка: +2
IT>>А можно <> оставить как в шарпе? Без приколов и очень привычно.

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


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


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


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

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

Даже создатели C#2 когда вводили свою эвристику — тоже ведь могли пойти на реализацию без всякой эвристики, наворотив спец-символов — в C#1 никаких дженериков не было и руки у них были развязаны. Но они сделали так как в C++, просто потому что основным конкурентом шарпу в этом вопросе был C++. И победить его внушив что C# это эдакий С++ только лучше они смогли в том числе и за счёт весьма похоже синтаксиса.
Re[4]: Предлагаю подобрать скобки для типов...
От: Блудов Павел Россия  
Дата: 15.12.09 10:33
Оценка: 4 (1) +1
Здравствуйте, SergASh, Вы писали:

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


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

Уверен, что лет через двадцать, когда люди будут знать только две кодировки, utf-8 и utf-32, можно будет использовать для конструкций языка хоть иероглифы. А сейчас это будут по большей части грабли.
Re[3]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 13:42
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

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


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

ЗЫ

А вообще, жаль, что дела обстаят так. Использование юникода могло бы сильно улучшить читабельность кода в некоторых местах. Главное не переборщить.
Но, конечно, пока используются национальные раскладки с юникодом будет фигово.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 13:42
Оценка:
Здравствуйте, Rival, Вы писали:

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

R>Вот так:

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


Плохо. "|" уже сильно задействован в других констуркциях. Конфликтов будет еще больше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 15.12.09 13:45
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

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


А что за проблемы с юникодом у notepad++? Сцинтилла вполне себе дружит с юникодом
Re[3]: Предлагаю подобрать скобки для типов...
От: Рысцов Денис  
Дата: 15.12.09 13:52
Оценка:
Здравствуйте, VladD2!

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

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


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

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

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


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

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


Насколько я понял, новый синтаксис обсуждается для того, чтобы в конечном счете сделать алгоритм вывода типов более быстрым и простым. Если поддерживать оба варианта, алгоритма будет два, получается copy-paste со всеми вытекающим проблемами. Если делать ломающие изменения, то в отдельной версии, одна текущая "стабильная", а другая "экспериментальная" Nemerle2.
Re[4]: Предлагаю подобрать скобки для типов...
От: jenyavb  
Дата: 15.12.09 15:27
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


С каких это пор?
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
Re: Предлагаю подобрать скобки для типов...
От: jenyavb  
Дата: 15.12.09 15:34
Оценка: 13 (2) +1
Здравствуйте, VladD2, Вы писали:

VD>Собственно сделать это не сложно. Но есть три вопроса:

VD>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.

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

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


Лучше до, чтобы не заботиься об обратной совместимости.

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


Тогда упрощения кода и вывода типов не получится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
Re[8]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 15:35
Оценка: 1 (1)
Здравствуйте, hi_octane, Вы писали:

_>Но неоднозначности появляются только в каких-то особых случаях, ведь так?


Неоднозначности или есть, или нет.
Конструкция: x[y] может рассматриваться или как тип с параметром типа, или как индекстатор.
В принципе вывод типов позволят понять, что за конструкцию мы разбираем. Но для этого приходится производить спекулятивные типизации.

Спекулятивная типизация — это попытка типизировать некое выражение как нечто на что оно похоже.
Общий алгоритм можно опсать так:
TypeExpr(expr : PExpr) : TExpr
{
  match (TryTypeAsType())
  {
    | Some => TypeAsType()
    | None =>
      match (TryTypeAsLocalRef())
      {
        | Some => TypeAsLocalRef()
        | None => TExpr.Error()
      }
  }
}


По большому счету это работает.
Но если углубиться, то можно заметить следующие проблемы:
1. Ухудшенная реакция на ошибки (по сравнению с однозначной грамматикой).
Скажем если у нас есть x[y] и программист ошибается в написании y или x, то типизация завершается неудачей и производится попытка интерпретировать выражение другим образом. Предположим программист подразумевал под x[y] выражение индексации, но компилятор может выдать сообщение об ошибке вроде "'y' не верный тип". Это введет программиста в заблуждение. Или он может выдать слишком общее сообщение, что тоже плохо.

2. Автодополнение при вводе. Тут возникают проблемы того же характера. Скажем программист опять же набрал x[y|] ("|" — это место в котором программист захотел дополнить идентификатор). Предположим, что с "y" начинаются тип "Yyy" и локальная переменная "yxz". В режиме автодополнения спекцляции бесполезны. Идентификатор ведь не полный. Если первой спекуляцией будет TryTypeAsType, то будет возращен список типов, а список локальных переменных возвращен не будет.

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


1. Символ "@" уже используется в языке и делает любую последовательность символов идентификатором.
2. Мне не нравится сама идея применения чего-то в отдельных случаях. Это делает язык сложнее, забивая его не нужными частностями.

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


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

Буквой приходится поступаться. На мой взгляд менее неоднозначная грамматика делает
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 15:37
Оценка:
Здравствуйте, Блудов Павел, Вы писали:

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


И utf-8, и utf-32 — это одна кодировка — Юникод. Просто разные форматы ее записи в файл.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 15.12.09 15:44
Оценка: 8 (1)
Здравствуйте, jenyavb, Вы писали:

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

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

Ну вообще с давних. Я вот прекрасно редактирую файлы в UTF8 в Programmers Notepad.
Re[2]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 15.12.09 15:45
Оценка: 1 (1)
Здравствуйте, jenyavb, Вы писали:

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


VD>>Собственно сделать это не сложно. Но есть три вопроса:

VD>>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.

J>Я бы предпочел синтаксис из скалы. Индексаторы это свойства с параметрами, а параметры указываютсяя в скабках. В васике тоже используются скобки и ничего плохого в это нет. Кроме того часто бывает нужно заменить вызов индексатора на вызов функции и тогда приходится менять квадратные скобки на круглые, а так не нужно будет.


Хочу еще добавить, что для типов-аргументов любой синтаксис кроме A<T> и A[T] будет в некоторой степени неестественным. А вот для индексации массивов arr(x) = 1 будет почти таким же естественным как arr[x] = 1.
Re[5]: Предлагаю подобрать скобки для типов...
От: Воронков Василий Россия  
Дата: 15.12.09 15:47
Оценка:
Здравствуйте, jenyavb, Вы писали:

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

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

Собственно:
Re[2]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 15.12.09 15:48
Оценка:
J>Я бы предпочел синтаксис из скалы. Индексаторы это свойства с параметрами, а параметры указываютсяя в скабках. В васике тоже используются скобки и ничего плохого в это нет. Кроме того часто бывает нужно заменить вызов индексатора на вызов функции и тогда приходится менять квадратные скобки на круглые, а так не нужно будет.

Собственный синтаксис для индексаторов — это ещё и подсказка что в данном случае имеем доступ к коллекции или чему-то мимикрирующуему под коллекцию. Круглые скобки это более универсально, но в каждом конкретном случае придётся разбираться коллекция ли там под капотом, или имеем вызов функции, которая что-то считает и возвращает какое-то разовое значение. Т.е. снижается наглядность при чтении кода.
Re[2]: Предлагаю подобрать скобки для типов...
От: Иванков Дмитрий Россия  
Дата: 15.12.09 15:57
Оценка: 4 (1) +2
Здравствуйте, nikov, Вы писали:

N>Мне больше всего нравится, как сделано в Scala: типы-параметры [], вызов индексатора ()

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

А типы-параметры вполне можно представлять как вызов индексатора семейства типов.
Собственно смысла в смене "тип-параметр vs индексатор" на "индексатор vs вызов функции" нет, в контексте этой ветки.
Re[3]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 15.12.09 16:04
Оценка: 2 (1)
N>Хочу еще добавить, что для типов-аргументов любой синтаксис кроме A<T> и A[T] будет в некоторой степени неестественным. А вот для индексации массивов arr(x) = 1 будет почти таким же естественным как arr[x] = 1.

В то время когда публике представляли C# 1.0 и VB.NET я читал бумажную статью о том что глядя на конструкцию X = y мы не знаем в реальности что она делает ни в C++ ни VB classic. Статья была красивая (жаль сейчас не найти), и цель её — была объяснить тем кто писал на C++ почему в C# не сделали переопределния оператора =, и ещё кучу всего. Глядя на конструкцию x = MyClass.MyProp(i); — я точно также не могу понять — что она делает, будет ли она что-то вычислять или вернёт готовое значение, стоит ли вообще пытаться писать MyClass.MyProp(i) = x, можно ли делать по ней select, и т.п. В общем одни минусы, при том что единственный плюс это то что синтаксис унифицирован внутри самого языка, и сделан подобным какому-то другому языку на какой-то другой платформе... не маловато-ли плюсов?

Введение () для индексаторов, это имхо такой же шаг назад на те же грабли как и возврат к set/get методам вместо свойств. И то и другое — синтаксический сахар к методам. Но этот сахар сделали что лучше передать смысл конструкций.
Re[3]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 16:13
Оценка: +1
Здравствуйте, nikov, Вы писали:

N>Хочу еще добавить, что для типов-аргументов любой синтаксис кроме A<T> и A[T] будет в некоторой степени неестественным. А вот для индексации массивов arr(x) = 1 будет почти таким же естественным как arr[x] = 1.


Я как старый сишник считаю, что синтаксис arr(x) тоже не естественный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 15.12.09 16:23
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

x.<T>Foo(y);
Re[9]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 15.12.09 16:27
Оценка:
_>>Но неоднозначности появляются только в каких-то особых случаях, ведь так?

VD>Неоднозначности или есть, или нет.

VD>Конструкция: x[y] может рассматриваться или как тип с параметром типа, или как индекстатор.
VD>В принципе вывод типов позволят понять, что за конструкцию мы разбираем. Но для этого приходится производить спекулятивные типизации.

Я имел ввиду неоднозначности с <T>. Но за столь развёрнутый ответ спасибо — увы, наверное кроме двух-трёх человек никто толком не может рассказать насколько реализуемы и однозначны те или иные виды объявлений из всего фейерверка бурлесков который уже напредлагали в голосовании.

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


VD>1. Символ "@" уже используется в языке и делает любую последовательность символов идентификатором.

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

Так если эта частность будет всплывать только в 1-м случае из 10 и в конструкции вида X(T<Y, Z>) или какой-то подобной пользователя заставят написать X(T@<Y, Z>) — никто нам и слова не скажет. Да и лексер насколько я помню и так переписывать надо для in-line поддержки linq.

VD>Ну, дык под "можно" наверно понимаеются возможности языка, а не синтаксическая идентичность. Так?


Для человека который до этого писал только на шарпе — любая невозможность писать тем способом каким он привык, или уже знает — это те самые -100 баллов про которые часто пишут разработчики компилятора C# в своих блогах. Поэтому, имхо, там где возможно, нам стоит быть ближе и доступнее тем кто начинает писать на Nemerle.
Re[10]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 16:56
Оценка:
Здравствуйте, hi_octane, Вы писали:

_>Для человека который до этого писал только на шарпе — любая невозможность писать тем способом каким он привык, или уже знает — это те самые -100 баллов про которые часто пишут разработчики компилятора C# в своих блогах. Поэтому, имхо, там где возможно, нам стоит быть ближе и доступнее тем кто начинает писать на Nemerle.


Этот вопрос решается по другому. Можно сделать поддержку C#-синтаксиса, так чтобы в проект можно было бы просто включать C#-файлы.

Это даже не очень сложно сделать. Я планировал это сделать до релиза, но к сожалению задержал Вольфхаунд который хотел реализовать PEG-парсер в виде макроса немерле, но так до сих пор его и не реализовал.
Будет построитель парсеров, обязательно сделаю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 15.12.09 17:00
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Этот вопрос решается по другому. Можно сделать поддержку C#-синтаксиса, так чтобы в проект можно было бы просто включать C#-файлы.


И что, вы собираетесь делать честную поддержку сишарповских member lookup, type inference и overload resolution?
Re[12]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.12.09 17:20
Оценка:
Здравствуйте, nikov, Вы писали:

N>И что, вы собираетесь делать честную поддержку сишарповских member lookup, type inference и overload resolution?


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

У нас другая задача. Точнее их две:
1. Упростить перевод проектов на Nemerle. Люди смогут брать готовые C#-проекты и развивать их с помощью Немерле. Кроме того появится возможность заимствования из других C#-проектов. Ну, и за одно решится проблема "непривычности" и психологические проблемы.
2. Использовать дизайнеры и генераторы кода рассчитанные на C#.

ЗЫ

Что касается планов по второй версии (или это будет отдельный язык... скажем "N"), то возможно в ней реализуем некоторые настройки которые позволят эмулировать другие языки не только на синтаксическом уровне, но и на семантическом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Предлагаю подобрать скобки для типов...
От: jenyavb  
Дата: 16.12.09 04:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я как старый сишник считаю, что синтаксис arr(x) тоже не естественный.


В си у [] это просто упрощенный синтакис для доступа к памяти. В Nemerle даже unsafe нет, так что смысла копировать си тоже нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
Re[4]: Предлагаю подобрать скобки для типов...
От: jenyavb  
Дата: 16.12.09 04:31
Оценка: 1 (1)
Здравствуйте, hi_octane, Вы писали:

_>В то время когда публике представляли C# 1.0 и VB.NET я читал бумажную статью о том что глядя на конструкцию X = y мы не знаем в реальности что она делает ни в C++ ни VB classic. Статья была красивая (жаль сейчас не найти), и цель её — была объяснить тем кто писал на C++ почему в C# не сделали переопределния оператора =, и ещё кучу всего. Глядя на конструкцию x = MyClass.MyProp(i); — я точно также не могу понять — что она делает, будет ли она что-то вычислять или вернёт готовое значение, стоит ли вообще пытаться писать MyClass.MyProp(i) = x, можно ли делать по ней select, и т.п.


А теперь замени круглые скобки на квадратные — что изменилось? Да и не стоит забывать что в основном используются только дефолтные индексаторы.

_> В общем одни минусы, при том что единственный плюс это то что синтаксис унифицирован внутри самого языка, и сделан подобным какому-то другому языку на какой-то другой платформе... не маловато-ли плюсов?


Основной плюс — это то, что можно будет использовать естественные [] вместо всяких узвращений.
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
Re[13]: Предлагаю подобрать скобки для типов...
От: Аноним  
Дата: 16.12.09 07:43
Оценка:
Здравствуйте, VladD2,

А нельзя ли сделать вообще без всяких скобок:

Map int int foo;

?
(если глупость, не пинайте, я немерле пока не знаю, но планирую)
Re: вариант <| |>
От: Иванков Дмитрий Россия  
Дата: 16.12.09 08:11
Оценка:
Вроде бы не упоминалось ещё: есть оператор |> для функций, симметричного ему <| пока нет, но это тоже не очень приятное перекрытие.
Re[5]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 16.12.09 08:15
Оценка:
J>А теперь замени круглые скобки на квадратные — что изменилось?

Ну сравни

x = MyClass.X(a, b);
     с 
x = MyClass.X[a, b];


И что изменилось? Как программист в случае индексации [] я получаю подсказку что имеет место обращение к коллекции, которая как-то индексируется. Что при повторном обращении с тем же набором индексов [a, b] — я получу тот же самый элемент что и в прошлый раз (в случае ссылочных типов — так и reference equal элемент), что я могу по этой коллекции прокатить foreach или select, и т.п. Повторюсь — индексаторы это костыль к методам, но не больший костыль чем свойства. Да и есть уже один язык который подвергся тотальной унификации и теперь сидит в очень узкой нише — lisp. Лиспу никаких скобок кроме круглых не надо, но и писать на нём готовы считанные люди.
Re[14]: Предлагаю подобрать скобки для типов...
От: hi_octane Беларусь  
Дата: 16.12.09 08:18
Оценка:
А>А нельзя ли сделать вообще без всяких скобок:

А>
А>Map int int foo;
А>

А>?
А>(если глупость, не пинайте, я немерле пока не знаю, но планирую)

Тогда вложенные Map<int, Pair<int, string>> придётся писать в польской нотации или как-то ещё извращаться — уж лучше оставить [] как это сейчас.
Re[8]: Вариант D: !T и !(T1, T2)
От: Иванков Дмитрий Россия  
Дата: 16.12.09 08:21
Оценка:
С опусканием скобок проблемы могут быть с вложенными именами:
Foo!Bar.Baz // Foo!(Bar).Baz vs Foo!(Bar.Baz)
Re[2]: Предлагаю подобрать скобки для типов...
От: Мишень-сан  
Дата: 16.12.09 08:58
Оценка:
Здравствуйте, jenyavb, Вы писали:

J>Я бы предпочел синтаксис из скалы. Индексаторы это свойства с параметрами, а параметры указываютсяя в скабках. В васике тоже используются скобки и ничего плохого в это нет. Кроме того часто бывает нужно заменить вызов индексатора на вызов функции и тогда приходится менять квадратные скобки на круглые, а так не нужно будет.


В Nemerle допустимо такое выражение (взято отсюда
Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.
):
_multiDimArray : array[2, int] = array.[2][[1, 2, 3], [4, 5, 6]];


Если использовать синтаксис scala, как Вы предложили, точка уйдёт и получится неоднозначность.
Re[3]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 16.12.09 09:32
Оценка:
Здравствуйте, Мишень-сан, Вы писали:

МС>В Nemerle допустимо такое выражение (взято отсюда
Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.
):

МС>
МС>_multiDimArray : array[2, int] = array.[2][[1, 2, 3], [4, 5, 6]];
МС>


МС>Если использовать синтаксис scala, как Вы предложили, точка уйдёт и получится неоднозначность.


Не понял, какая неоднозначность? Приведи пример двух вариантов синтаксического разбора.
Re[3]: Предлагаю подобрать скобки для типов...
От: jenyavb  
Дата: 16.12.09 10:12
Оценка: 4 (1)
Здравствуйте, Мишень-сан, Вы писали:

МС>В Nemerle допустимо такое выражение (взято отсюда
Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.
):

МС>
МС>_multiDimArray : array[2, int] = array.[2][[1, 2, 3], [4, 5, 6]];
МС>

МС>Если использовать синтаксис scala, как Вы предложили, точка уйдёт и получится неоднозначность.

Количество элементов при инициализации массива тоже придется указывать в круглых скобках. И это ИМХО плюс, так как в квадратных скобках указывается содержимое массива (или тип элементов).
Re[4]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 16.12.09 10:21
Оценка:
Здравствуйте, jenyavb, Вы писали:


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


Мне кажется, это безразлично, так как литерал 2 — это точно не тип.
Re: Предлагаю подобрать скобки для типов...
От: seregaa Ниоткуда http://blogtani.ru
Дата: 16.12.09 11:24
Оценка: +1
Здравствуйте, VladD2, Вы писали:

А как вам такой вариант:
При объявлении типов/методов использовать синтаксис со стандартными угловыми скобками, а при использовании в условиях необходимости уточнить тип — уточнять его через двоеточие, как это уже принято в Немерле. И дать возможность избирательно уточнять тип параметров генерика, а не как в c# — или для всех параметров или ни для кого.

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

что то вроде этого:
class A<T1, T2>
{
  x : T1;
  y : T2;

  m<T>(x : int) : void {}  
}

def c = A:<int,int>();
def v = c.m:<int>();


или так:

def c = A:<T1:int>();


ну или так:
def c = A():<int,int>;
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[9]: Вариант D: !T и !(T1, T2)
От: Воронков Василий Россия  
Дата: 16.12.09 11:46
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>С опусканием скобок проблемы могут быть с вложенными именами:

ИД>
ИД>Foo!Bar.Baz // Foo!(Bar).Baz vs Foo!(Bar.Baz)
ИД>


Не уверен, что это будет проблемой для парсера. К тому же в D это работает.
Re[4]: Предлагаю подобрать скобки для типов...
От: Мишень-сан  
Дата: 16.12.09 12:55
Оценка: 4 (1)
Здравствуйте, jenyavb, Вы писали:

J>Здравствуйте, Мишень-сан, Вы писали:


МС>>В Nemerle допустимо такое выражение (взято отсюда
Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.
):

МС>>
МС>>_multiDimArray : array[2, int] = array.[2][[1, 2, 3], [4, 5, 6]];
МС>>

МС>>Если использовать синтаксис scala, как Вы предложили, точка уйдёт и получится неоднозначность.

J>Количество элементов при инициализации массива тоже придется указывать в круглых скобках. И это ИМХО плюс, так как в квадратных скобках указывается содержимое массива (или тип элементов).


array.[2] это не массив из 2-х элементов, а 2-мерный массив.
Re[2]: вариант <| |>
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.12.09 13:23
Оценка:
Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Вроде бы не упоминалось ещё: есть оператор |> для функций, симметричного ему <| пока нет, но это тоже не очень приятное перекрытие.


Важен открывающий символ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Предлагаю подобрать скобки для типов...
От: jenyavb  
Дата: 16.12.09 13:41
Оценка:
Здравствуйте, Мишень-сан, Вы писали:

МС>array.[2] это не массив из 2-х элементов, а 2-мерный массив.


Понятно. Значит нужно думать что делать с многомерными массивами. Текущая форма записи тоже не очень очевидная. Интересно, как оно сделано в scala?
... << RSDN@Home 1.2.0 alpha 4 rev. 1325>>
Re: <T>
От: Константин Л. Франция  
Дата: 16.12.09 13:42
Оценка: -1
Здравствуйте, VladD2, Вы писали:

[]

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

def someFunc()
{
def items = [1, 2, 3];
def result = [items | items.Head >>> 1 ];
...
result.Count >> 0;
}

ы?
Re[6]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 16.12.09 13:44
Оценка: 4 (1)
Здравствуйте, jenyavb, Вы писали:

J>Понятно. Значит нужно думать что делать с многомерными массивами. Текущая форма записи тоже не очень очевидная. Интересно, как оно сделано в scala?


В Scala нет многомерных массивов, как и в Java. Вместо этого там используются вложенные массивы.
Re[2]: <T>
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.12.09 14:03
Оценка: +1
Здравствуйте, Константин Л., Вы писали:

КЛ>Кроме того, я с ходу не соображу, но не кажется ли вам, что использования сравнения встречается сейчас реже чем, декларации дженериков? Это я к тому, что можно для сравнений сделать операторы двойными, а для сдвигов — тройными.


Путанница будет еще та.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Предлагаю подобрать скобки для типов...
От: SergASh  
Дата: 16.12.09 15:23
Оценка:
Здравствуйте, seregaa, Вы писали:

S>А как вам такой вариант:

S>При объявлении типов/методов использовать синтаксис со стандартными угловыми скобками, а при использовании в условиях необходимости уточнить тип — уточнять его через двоеточие, как это уже принято в Немерле. И дать возможность избирательно уточнять тип параметров генерика, а не как в c# — или для всех параметров или ни для кого.

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

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

Как по мне, то вариант с двоеточием выглядит приятнее чем с восклицательным знаком, собакой или точкой. Для сравнения
def map = Dictionary:<long,List:<int>>();

def map = Dictionary!<long,List!<int>>();

def map = Dictionary@<long,List@<int>>();

def map = Dictionary.<long,List.<int>>();

Я бы за первое проголосовал
Re[3]: Предлагаю подобрать скобки для типов...
От: seregaa Ниоткуда http://blogtani.ru
Дата: 16.12.09 16:43
Оценка:
Здравствуйте, SergASh, Вы писали:

S>>И дать возможность избирательно уточнять тип параметров генерика, а не как в c# — или для всех параметров или ни для кого.

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

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

SAS>Надо бы выяснить у тех, кто хорошо знает потроха компилятора, останутся ли проблемы с неоднозначностью если чистые угловые скобки будут только в объявлениях. Из того, что VladD2 до сих пор говорил, следует, что проблемы есть только при вызовах.


Мне тоже кажется с ":<" неоднозначностей быть не должно, так и не придумал, в каких еще случаях может появиться такая комбинация. Но если остановиться на синтаксисе с двоеточием и угловыми скобками, то придется перелопатить парсинг объявления классов и методов — вернуть поддержку угловых скобок.

Есть еще сомнения Влада по поводу разных синтаксисов определения и вызова:

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

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

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

Аргумент против квадратных скобок, вернее просто мое имхо — парсить вызовы функций, типизованных "квадратными скобками", перемешанные с вызовами индексаторов — то еще удовольствие, тем более для старого шарпера. Лично я начал воспринимать двоеточия буквально с первой строки листинга на Немерле, а квадратные скобки меня до сих пор напрягают (правда мое знакомство с языком ограничивается статьями Влада и нескольким самодельными примерами).
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re: Предлагаю подобрать скобки для типов...
От: Пельмешко Россия blog
Дата: 16.12.09 17:49
Оценка: +2
Здравствуйте, VladD2, Вы писали:

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


А почему бы не убрать необязательную точку из type application expression и ввести её для indexed lookup expression, как в F#?
def list = List[int]()
def uups = list.[0]

В F# достаточно удобно + есть такая штука, как slice expression:
let arr = [| 1; 2; 3 |]
let two = arr.[1]
let slice = arr.[0..1]


З.Ы. я против <|T|>, неудобно набирать + 2 символа + не скажу, что приятный на глаз синтаксис, хотя C-подобность есть, если издалека посмотреть
З.Ы.Ы. в F# (что то шибко много раз я употребил эти два символа в этом форуме ) pipeline-оператор |> выглядит няшно только когда выстроен в вертикальный ряд... после такого:
show <| filter <| map <| x
...хаскельный оператор $ выглядит намного приятнее, хоть и непонятнее для новичков:
show $ filter $ map $ x

Короче ИМХО нафиг эту геометрию из < | >
Re[2]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.12.09 21:58
Оценка:
Здравствуйте, Пельмешко, Вы писали:

П>А почему бы не убрать необязательную точку из type application expression и ввести её для indexed lookup expression, как в F#?

П>
П>def list = List[int]()
П>def uups = list.[0]
П>


Шило на мыло. К тому же доступ по индексу в Немерле встречается намного чаше чем описание параметров типа внутри кода.

П>В F# достаточно удобно + есть такая штука, как slice expression:

П>
П>let arr = [| 1; 2; 3 |]
П>let two = arr.[1]
П>let slice = arr.[0..1]
П>


Это здорово, но к делу не относится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Предлагаю подобрать скобки для типов...
От: seregaa Ниоткуда http://blogtani.ru
Дата: 16.12.09 22:38
Оценка:
Здравствуйте, seregaa, Вы писали:

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


Имелось ввиду — "парсить" исходники глазами, читая код с листа. Говорить за парсер Немерле я не могу )
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[11]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 17.12.09 17:22
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Этот вопрос решается по другому. Можно сделать поддержку C#-синтаксиса, так чтобы в проект можно было бы просто включать C#-файлы.


Вы учтите, что в C# некоторые вещи запатентованы, так что имеет смысл заранее поговорить с юристом.
Re[12]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 17.12.09 17:24
Оценка:
Здравствуйте, nikov, Вы писали:

VD>>Этот вопрос решается по другому. Можно сделать поддержку C#-синтаксиса, так чтобы в проект можно было бы просто включать C#-файлы.


N>Вы учтите, что в C# некоторые вещи запатентованы, так что имеет смысл заранее поговорить с юристом.


Ещё: Ecma-334, Microsoft patent statement
Re[12]: Предлагаю подобрать скобки для типов...
От: Иванков Дмитрий Россия  
Дата: 17.12.09 19:22
Оценка:
Здравствуйте, nikov, Вы писали:

N>Вы учтите, что в C# некоторые вещи запатентованы, так что имеет смысл заранее поговорить с юристом.


Не думаю, что документ не прогнанный через спеллчекер заслуживает внимания
Re[13]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.09 21:01
Оценка:
Здравствуйте, nikov, Вы писали:

N>>Вы учтите, что в C# некоторые вещи запатентованы, так что имеет смысл заранее поговорить с юристом.


N>Ещё: Ecma-334, Microsoft patent statement


Кабздей ослику, тфу ты, Моно!

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

В прочем, я вообще не понимаю, что там можно было патентовать? Шарп содран с Явы. Это ясно как божий день. Ни одной новой фичи в нем нет. Что в нем патентовать то?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 17.12.09 21:09
Оценка:
Здравствуйте, VladD2, Вы писали:

N>>Ещё: Ecma-334, Microsoft patent statement


VD>Кабздей ослику, тфу ты, Моно!


А ты уверен, что у Novell и Microsoft нет никакого соглашения о кросс-лицензировании? Они как-никак партнеры.
Re[15]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.12.09 22:28
Оценка: +1
Здравствуйте, nikov, Вы писали:

N>А ты уверен, что у Novell и Microsoft нет никакого соглашения о кросс-лицензировании? Они как-никак партнеры.


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

А отношения между Новелом и МС меня не трогают, как не трогает партнерство между львом и антилопой.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Предлагаю подобрать скобки для типов...
От: sto Украина http://overstore.codeplex.com
Дата: 19.12.09 21:39
Оценка: +1 :)
Здравствуйте, hi_octane, Вы писали:

J>>А теперь замени круглые скобки на квадратные — что изменилось?


_>Ну сравни


_>
_>x = MyClass.X(a, b);
_>     с 
_>x = MyClass.X[a, b];
_>


_>И что изменилось? Как программист в случае индексации [] я получаю подсказку что имеет место обращение к коллекции, которая как-то индексируется. Что при повторном обращении с тем же набором индексов [a, b] — я получу тот же самый элемент что и в прошлый раз (в случае ссылочных типов — так и reference equal элемент), что я могу по этой коллекции прокатить foreach или select, и т.п. Повторюсь — индексаторы это костыль к методам, но не больший костыль чем свойства. Да и есть уже один язык который подвергся тотальной унификации и теперь сидит в очень узкой нише — lisp. Лиспу никаких скобок кроме круглых не надо, но и писать на нём готовы считанные люди.


ИМХО, наиболее приятной альтернативой представляется индексатор с круглыми скобками.
1) Он не вводит никаких новых символов в конструкции, а только убирает (точку).
2) Он есть в VB.NET
3) Индексатор в .NET — это метафора "свойство с параметрами", или же "дефолтное свойство с параметрами" в случае this[]. Как отметили выше, в С индексатор — это метафора прямого доступа к памяти, которая в безопасном дотнете не совсем уместна. То, что такой синтаксис оставили (в С#) для массивов, а также дали возможность объявлять свои индексаторы — это, имхо, для блюдения все того же принципа "наименьшей болезенности" при переходе с С/С++. То есть в С — это доступ к памяти, в С++ -доступ к памяти/вызов перегруженного оператора [], в С# — это таки вызов метода, и круглые скобки для него, имхо, были бы логичнее даже в C#.
4) При всем уважении к доводам процитированного автора — "обращение к коллекции", "тот же самый элемент", "могу прокатить foreach" — это не всегда, мягко говоря, верно, и относиться больше к code conventions и рекомендациям по дизайну классов.
5) (Могу ошибаться) Так ли уж часто в прикладном коде на функциональном языке нужен индексатор? В Dictionary словаря можно Item(TKey key) использовать.
There is no such thing as the perfect design.
Re[7]: Предлагаю подобрать скобки для типов...
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 19.12.09 21:48
Оценка:
Здравствуйте, sto, Вы писали:

sto>5) (Могу ошибаться) Так ли уж часто в прикладном коде на функциональном языке нужен индексатор? В Dictionary словаря можно Item(TKey key) использовать.


Мои написанные на Немерле алгоритмы часто работают с гигабайтами данных. Без массивов тут — никуда.
Ce n'est que pour vous dire ce que je vous dis.
Re[7]: Предлагаю подобрать скобки для типов...
От: hardcase Пират http://nemerle.org
Дата: 20.12.09 13:40
Оценка: -1
Здравствуйте, sto, Вы писали:

sto>3) Индексатор в .NET — это метафора "свойство с параметрами", или же "дефолтное свойство с параметрами" в случае


Тогда было бы логично обращаться к нему натурально через точку, как и в случае со свойствами:
a.[10]

Эта идея тут уже высказывалась, основной аргумент "против": индексатор используется не в пример чаще конструкции уточнения типа.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[5]: Предлагаю подобрать скобки для типов...
От: vdimas Россия  
Дата: 23.12.09 10:49
Оценка:
Здравствуйте, VladD2, Вы писали:

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


А смотрится вполне, эстетически лучше, чем все предложенное.

А может ли знак "!" идти после идентификатора в N? Если нет, то попробовать его:
class MyClass!T! : IMyInterface!T!
{
}

или даже так:
class MyClass!T : IMyInterface!T
{
}

class MyClass!TKey,TValue : IMyInterface!TKey,TValue
{
}
Re[6]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.12.09 12:17
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А может ли знак "!" идти после идентификатора в N?


С не парными символами вообще проблем много.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: В копилку
От: artelk  
Дата: 23.12.09 21:43
Оценка:
"Магический" токен можно засунуть внутрь:

MyClass[of T1, T2] // где-то я что-то такое видел...
MyClass[of T1, of T2]
MyClass[:T1, :T2]
MyClass[!T1, !T2]
MyClass[@T1, @T2]
MyClass[ #T1, #T2]
MyClass[$T1, $T2]
MyClass[%T1, %T2]
MyClass[^T1, ^T2]
MyClass[&T1, &T2]
MyClass[`T1, `T2]
MyClass['T1, 'T2] // где-то я что-то такое видел...
MyClass[?T1, ?T2]

Аналогично для угловых скобок <...>
Re: Предлагаю подобрать скобки для типов...
От: seregaa Ниоткуда http://blogtani.ru
Дата: 24.12.09 05:27
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.

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

Функциональный язык к новым синтаксисом уже есть, имхо F# прочно займет эту нишу, да и "железные" языки подтягиваются. Поэтому для Немерле было бы лучше остаться си-шарпом-на-стероидах, а значит иметь максимальную совместимость с его синтаксисом.
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[2]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.09 11:01
Оценка:
Здравствуйте, seregaa, Вы писали:

S>Функциональный язык к новым синтаксисом уже есть,


С новым, говоришь?
Этому новому синтаксису где-то около 30 лет.

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


Согласен. Но дизайн языка — это всегда компромиссы. В данном случае имеет место компромисс между похожестью на шарп и однозначностью синтаксиса. На мой взгляд большая однозначность лучше, так как она способствует как упрощению языка, так и лучшей его расширяемости. А расширяемость — конек Немерле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Предлагаю подобрать скобки для типов...
От: seregaa Ниоткуда http://blogtani.ru
Дата: 24.12.09 11:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


S>>Функциональный язык к новым синтаксисом уже есть,

VD>С новым, говоришь?
VD>Этому новому синтаксису где-то около 30 лет.
Я имел ввиду новизну не в историческом смысле, а в смысле незнакомости для c# программистов, who new to functional programming.

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


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

Я не за идентичности синтаксиса любой ценой, но за максимально возможное соответствие. Мой пост можно расценивать как вклад в копилку аргументов за сохранение угловых скобок, пусть и с двоеточием в виде префикса. А окончательное решение конечно нужно принимать по совокупности всех аргуменов.
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[4]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.12.09 13:31
Оценка:
Здравствуйте, seregaa, Вы писали:

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


S>Я не за идентичности синтаксиса любой ценой, но за максимально возможное соответствие. Мой пост можно расценивать как вклад в копилку аргументов за сохранение угловых скобок, пусть и с двоеточием в виде префикса. А окончательное решение конечно нужно принимать по совокупности всех аргуменов.


И получается, что интересы новичков начинают конфликтовать с интересами тех, кто использует язык по полной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Предлагаю подобрать скобки для типов...
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.09 08:23
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Собственно сделать это не сложно. Но есть три вопроса:

VD>1. Какой синтаксис скобок выбрать для этого? Например, можно использовать скобки состоящие из двух символов (на подобии тех, что используются в квази-цитировании) — <( )>, [< >] или скобки в сочетании с некоторым символом: <% %>, <| |> и т.п. Скобки вида ([ ]) и [( )] лучше не использовать, так как они конфликтуют с имеющимися конструкциями.
VD>2. Нужно ли делать это до выпуска версии 1.0 или отложить смену синтаксиса до будущей версии?
VD>3. Делать ли такую смену в виде ключа компиляции допускающего как квадратные скобки с точкой (как принято сейчас), так и новые скобки?

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


А может оставить < > но ввести слово typename как было в шаблонах с++ ?
йё
Re: Предлагаю подобрать скобки для типов...
От: konstardiy  
Дата: 29.12.09 16:12
Оценка:
Здравствуйте, VladD2, Вы писали:
List :( T = Type1 )

List : (Type1)


или
Dictionary @ (KeyT = Type1 & ValueT = Type2)
Dictionary @(Type1, type2)

То сть тогда @ преобеает смылсл слова "специализируется". Dictionary специализируеься type1 и Type 2
Возможность укзать явно, для каких аргументов генерика какой тип принять — мне нравится.
Этого варианта в голсовании нет.
Re[2]: Предлагаю подобрать скобки для типов...
От: nikov США http://www.linkedin.com/in/nikov
Дата: 29.12.09 16:17
Оценка:
Здравствуйте, konstardiy, Вы писали:

K>Возможность укзать явно, для каких аргументов генерика какой тип принять — мне нравится.


А может быть, сразу, и значения по умолчанию приделать...
Re[2]: Предлагаю подобрать скобки для типов...
От: hardcase Пират http://nemerle.org
Дата: 29.12.09 21:33
Оценка:
Здравствуйте, konstardiy, Вы писали:

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

K>
K>List :( T = Type1 )

K>List : (Type1)
K>


Эстетически выглядит плохо — как грустный "смайлик".

K>или

K>
K>Dictionary @ (KeyT = Type1 & ValueT = Type2)
K>Dictionary @(Type1, type2)
K>


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


А может заюзать подчеркивание? Оно глаза не так мозолит, как разные, в сущности мусорные, символы?

Dictionary_[Type1, type2]
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: Предлагаю подобрать скобки для типов...
От: Мишень-сан  
Дата: 30.12.09 07:30
Оценка:
Здравствуйте, hardcase, Вы писали:

H>А может заюзать подчеркивание? Оно глаза не так мозолит, как разные, в сущности мусорные, символы?


H>Dictionary_[Type1, type2]


Не выйдет, к сожалению
_ вполне легальный символ в любом литерале, причём на любой позиции. ИМХО, такой вариант создаст ещё больше неоднозначностей, чем <> или [].
Re[3]: Предлагаю подобрать скобки для типов...
От: konstardiy  
Дата: 30.12.09 10:18
Оценка:
Здравствуйте, nikov, Вы писали:

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


K>>Возможность укзать явно, для каких аргументов генерика какой тип принять — мне нравится.


N>А может быть, сразу, и значения по умолчанию приделать...

Ага, типа после констреинтов на тип писать
default <DesiredDefaultNonAbstractCreatableType>;
Re[3]: Предлагаю подобрать скобки для типов...
От: konstardiy  
Дата: 30.12.09 10:22
Оценка:
Здравствуйте, hardcase, Вы писали:

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


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

K>>
K>>List :( T = Type1 )

K>>List : (Type1)
K>>


H>Эстетически выглядит плохо — как грустный "смайлик".


K>>или

K>>
K>>Dictionary @ (KeyT = Type1 & ValueT = Type2)
K>>Dictionary @(Type1, type2)
K>>


H>С "собакой" получще, но квадратные скобки привычнее, по крайней мере со смайлами не ассоциируется....



H>А может заюзать подчеркивание? Оно глаза не так мозолит, как разные, в сущности мусорные, символы?


H>Dictionary_[Type1, type2]


А еще в Nemerle это целая конструкция языка (дюбой вариант).
можно конечно вообще
T with {T1};//объявление
T with (DesiredType); //указание аргумента
Re[4]: Предлагаю подобрать скобки для типов...
От: hardcase Пират http://nemerle.org
Дата: 30.12.09 19:23
Оценка:
Здравствуйте, Мишень-сан, Вы писали:

H>>Dictionary_[Type1, type2]


МС>Не выйдет, к сожалению

МС>_ вполне легальный символ в любом литерале, причём на любой позиции. ИМХО, такой вариант создаст ещё больше неоднозначностей, чем <> или [].

Честно говоря, я не вижу принципиальных ограничений. Wildcard _ по прямому назначению используется в несколько ином контексте: сопоставление с образцом, частичное применение, по непрямому — префикс игнорируемого значения; а вот случай конкретизации генерика вполне обособлен (слева всегда идет имя типа) и однозначен. Мне просто кажется, что такой вариант читать проще — нету крякозябров всяких: @, #, !. Ближайшей альтернативой можно считать пару ^[ ]
/* иЗвиНите зА неРовнЫй поЧерК */
Re[5]: Предлагаю подобрать скобки для типов...
От: hardcase Пират http://nemerle.org
Дата: 30.12.09 19:33
Оценка:
А да. Забыл сказать. Я предлагаю использовать эту конструкцию "Имя_[" неразрывно, не допуская пробелы:
Dictionary_[ string, List_[object] ]

Т.е. фактически получим новое вхождение в варианту PExpr — GenericName — со списком аргументов.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[5]: Предлагаю подобрать скобки для типов...
От: seregaa Ниоткуда http://blogtani.ru
Дата: 31.12.09 11:48
Оценка:
Здравствуйте, VladD2, Вы писали:

S>>Я не за идентичности синтаксиса любой ценой, но за максимально возможное соответствие. Мой пост можно расценивать как вклад в копилку аргументов за сохранение угловых скобок, пусть и с двоеточием в виде префикса. А окончательное решение конечно нужно принимать по совокупности всех аргуменов.


VD>И получается, что интересы новичков начинают конфликтовать с интересами тех, кто использует язык по полной.


Конкретно здесь конфликта не вижу — синтаксис определения типов все равно будет меняться, и тем кто уже юзает язык все равно придется привыкать по новой и переписывать свой код. Кстати, ты похоже уже принял решение по скобочкам? — вон и голосование прикрыл. Странно только, что в гугловой группе этот вопрос не обсуждался.
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re: !<>
От: _nn_ www.nemerleweb.com
Дата: 07.09.11 16:02
Оценка: 6 (1) +1
Чем не устраивает !<> ?

1. Проще в наборе чем двойные скобки.
2. Нет неоднозначности.
3. Почти как C#, но зато без проблем: http://en.csharp-online.net/ECMA-334%3A_9.2.3_Grammar_ambiguities

[MyAttribute(typeof(IList!<string>))]
public class A!<T> where T : IMyInterface!<string>
{
   public B : IEnumerable!<T>{ get; set; }
}

def x = List!<int, List!<int, List!<int>>>([1, 2])[0];


http://rsdn.nemerleweb.com
http://nemerleweb.com
Re: Предлагаю подобрать скобки для типов...
От: catbert  
Дата: 07.09.11 22:03
Оценка:
Здравствуйте, VladD2, Вы писали:

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


http://bikeshed.org/
Re: Предлагаю подобрать скобки для типов...
От: Аноним  
Дата: 08.09.11 10:17
Оценка:
А почему вообще не писать так

func a(a,b,c):d
....



вызов ф(int,1,4):double

???

какой смысл вообще выделять генерики то?
Почему их не сделать обычным типом?
Re[2]: Предлагаю подобрать скобки для типов...
От: _nn_ www.nemerleweb.com
Дата: 08.09.11 11:02
Оценка:
Здравствуйте, Аноним, Вы писали:

А>А почему вообще не писать так


А>func a(a,b,c):d

А>....



А>вызов ф(int,1,4):double


А>???


А>какой смысл вообще выделять генерики то?

А>Почему их не сделать обычным типом?

Это что означает ? Давайте подробнее.

скобки () создадут другой конфлик
class A {}
class B {}

module P
{
  F[T](t : T) : int -> void { }
  F(t : int) : void { }

  Main() : void
  {
    def A = 1;
    def B = 2;
    F(A)(B);
  }
}


Это вызов генерик метода F с типом A или вызов метода F с аргументом A ?
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[3]: Предлагаю подобрать скобки для типов...
От: Аноним  
Дата: 08.09.11 11:18
Оценка:
Здравствуйте, _nn_, Вы писали:

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


А>>А почему вообще не писать так


А>>func a(a,b,c):d

А>>....



А>>вызов ф(int,1,4):double


А>>???


А>>какой смысл вообще выделять генерики то?

А>>Почему их не сделать обычным типом?

__>Это что означает ? Давайте подробнее.


__>скобки () создадут другой конфлик

__>
__>class A {}
__>class B {}

__>module P
__>{
__>  F[T](t : T) : int -> void { }
__>  F(t : int) : void { }

__>  Main() : void
__>  {
__>    def A = 1;
__>    def B = 2;
__>    F(A)(B);
__>  }
__>}
__>


class A {}
class B {}

module P
{
  F(T ,t : T) : int -> void { }
  F(t : int) : void { }
  Main() : void
  {
    def A = 1;
    def B = 2;
    F(A, B); // это вызов генерика
    F(A); // это вызов функции

  }
}
Re[4]: Предлагаю подобрать скобки для типов...
От: _nn_ www.nemerleweb.com
Дата: 08.09.11 12:02
Оценка:
Здравствуйте, Аноним, Вы писали:

Т.е. типы и аргументы в перемешку ?

class A {}
class B {}

module P
{
  F(X, Y ,x : Y, y : Y) : void { }
  F(x : int, y : int, z : int, w : int) : void { }
  Main() : void
  {
    def A = 1;
    def B = 2;
    F(A, B, A, B); // вызовет генерика или нет ?
  }
}
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[5]: Предлагаю подобрать скобки для типов...
От: Аноним  
Дата: 08.09.11 12:10
Оценка:
Здравствуйте, _nn_, Вы писали:

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


__>Т.е. типы и аргументы в перемешку ?


class A {}
class B {}

module P
{
  F(X, Y ,x : Y, y : Y) : void { }
  F(x : int, y : int, z : int, w : int) : void { }
  Main() : void
  {
    def A = 1;
    def B = 2;
    F(A, B, A, B); // вызовет генерика или нет ? - функции
так как передаются значения
F(type(A), type(B), A, B) // для генерика 
  }
}


А вообще в таких неоднозначностяъ надо просто ругаться
Re[5]: Предлагаю подобрать скобки для типов...
От: Аноним  
Дата: 08.09.11 12:54
Оценка:
Здравствуйте, _nn_, Вы писали:

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


__>Т.е. типы и аргументы в перемешку ?


class A {}
class B {}

module P
{
  F(X, Y ,x : Y, y : Y) : void { }
  F(x : int, y : int, z : int, w : int) : void { }
  Main() : void
  {
    def A = 1;
    def B = 2;
    F(:A, :B, A, B); //  генерика 
    F(A, B, A, B); // Функция
 }
}
Re[2]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.11 13:49
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Почему их не сделать обычным типом?


Очевидно, потому что они являются обобщенным типом.

ЗЫ

Сори, какой вопрос, таков ответ.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Предлагаю подобрать скобки для типов...
От: Аноним  
Дата: 08.09.11 14:20
Оценка:
Здравствуйте, VladD2, Вы писали:

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


А>>Почему их не сделать обычным типом?


VD>Очевидно, потому что они являются обобщенным типом.


VD>ЗЫ


VD>Сори, какой вопрос, таков ответ.


Зачем делать искусственное разделение?
Re[6]: Предлагаю подобрать скобки для типов...
От: _nn_ www.nemerleweb.com
Дата: 08.09.11 14:32
Оценка:
Здравствуйте, Аноним, Вы писали:

Дело в том, что, как раз, в большинстве случаев тип в генерик методе явно указывать не нужно.
А когда нужно, хотелось бы легко различать где типы и где аргументы, ну и, кроме того, не будет неоднозначностей.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[4]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.11 14:33
Оценка:
Здравствуйте, Аноним, Вы писали:

>>Сори, какой вопрос, таков ответ.


А>Зачем делать искусственное разделение?


Не вижу никакой искусственности. Нмерл не выводит обобщенных типов и требует их явного задания.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Предлагаю подобрать скобки для типов...
От: Аноним  
Дата: 08.09.11 15:12
Оценка:
Здравствуйте, VladD2, Вы писали:

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


>>>Сори, какой вопрос, таков ответ.


А>>Зачем делать искусственное разделение?


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


Есть принципиальная причина "Немерл не выводит обобщенных типов и требует их явного задания"?
Зачем усложнять когда можно обобщить?

например что такое статистический объект? это тип или это значение?
Re[6]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.11 17:27
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Есть принципиальная причина "Немерл не выводит обобщенных типов и требует их явного задания"?

А>Зачем усложнять когда можно обобщить?

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

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

А>например что такое статистический объект?


Не знаю. Это у тебя надо спросить.

А>это тип или это значение?


О чем речь то?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Предлагаю подобрать скобки для типов...
От: Аноним  
Дата: 08.09.11 20:21
Оценка: +1
Здравствуйте, VladD2, Вы писали:

Давайте рассуждать логицски и систематицски.

Какие в семибитном ASCII существуют скобки?

[] <> {} ()

Усё.

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

Имеем варианты:

1) допустить неоднозначности и бороться с ними по возможности цивилизованными способами;

2) вводить другие символы, которые у кого-нибудь да вызовут аллергию.

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

Лично мне больше всего импонируют варианты Type<Arg> и Type`Arg`, потому что символ ` набирается нажатием одной кнопки без шифта и не выглядит слишком дико.
Re[7]: Предлагаю подобрать скобки для типов...
От: CodingUnit Россия  
Дата: 08.09.11 20:22
Оценка: 1 (1) +1
Здравствуйте, VladD2, Вы писали:

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


А>>Есть принципиальная причина "Немерл не выводит обобщенных типов и требует их явного задания"?

А>>Зачем усложнять когда можно обобщить?

VD>Вот обобщение в данном случае и есть усложнение. В этом мире ничего даром не дается. Вывод обобщенного типа дает больше поводов для ошибок, замедлит алгоритм и потребует много работы на его реализацию. Меж тем, практика показывает, что обобщенные локальные функции в Nemerle используются очень редко, и всегда могут быть заменены методами.


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


А>>например что такое статистический объект?


Ребят а охота вам так париться из за возможного несоответствия с индексаторами, я честно говоря их вообще редко использую и уродовать синтаксис генериков из за него мне кажется было бы пустой тратой времени, по крайней мере сейчас, можно эту задачу оставить до лучших времен, пока поразмыслить над этим. Мне кажется лучше поменять синтаксис индексаторов чем генериков, они наиболее жизненноважные.
Re[8]: Предлагаю подобрать скобки для типов...
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.09.11 20:33
Оценка:
Здравствуйте, CodingUnit, Вы писали:

CU>Ребят а охота вам так париться из за возможного несоответствия с индексаторами,


Да никто и не парится. Просто кто-то поднял тему столетней давности.

Уже решили ничего не менять. Используется синтаксис [] и точка как средство разрешения неоднозначностей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Предлагаю подобрать скобки для типов...
От: Аноним  
Дата: 08.09.11 20:42
Оценка: 1 (1)
Здравствуйте, Аноним, Вы писали:

Хотя нет, самый годный вариант, по-моему — квадратные скобки для типов и круглые для индексеров.

С определением индексеров что-то проблем не вижу.
Re[3]: Предлагаю подобрать скобки для типов...
От: Аноним  
Дата: 08.09.11 20:53
Оценка: +1
Здравствуйте, Аноним, Вы писали:

А>Хотя нет, самый годный вариант, по-моему — квадратные скобки для типов и круглые для индексеров.


Хотя нет, не годный. Все варианты фиговые по-своему, но <> хотя бы привычный.
Re: Предлагаю подобрать скобки для типов...
От: Рамиль Вахитов  
Дата: 10.09.11 09:35
Оценка: -1
Предлагаю оператор дженерик типа оставить как есть, а оператор получения элемента по индексу изменить на >>> и на <<<. Понимаю, что необычно и длиннее на один символ, но зато позволяет получать элементы по индексу с конца. Считаю что это удобнее чем писать так: arr[arr.Length — i — 1]
Re[6]: Предлагаю подобрать скобки для типов...
От: sergey_shandar США http://getboost.codeplex.com/
Дата: 06.11.11 04:07
Оценка:
Здравствуйте, hi_octane, Вы писали:

J>>А теперь замени круглые скобки на квадратные — что изменилось?


_>Ну сравни


_>
_>x = MyClass.X(a, b);
_>     с 
_>x = MyClass.X[a, b];
_>


_>И что изменилось? Как программист в случае индексации [] я получаю подсказку что имеет место обращение к коллекции, которая как-то индексируется.

Не факт. Тот кто написал этот X мог сделать его реализацию как угодно.

_>Что при повторном обращении с тем же набором индексов [a, b] — я получу тот же самый элемент что и в прошлый раз (в случае ссылочных типов — так и reference equal элемент), что я могу по этой коллекции прокатить foreach или select, и т.п.

Кто сказал что MyClass реализует IEnumerable? foreach не имеет никакго отношения к "X[]".
getboost.codeplex.com
citylizard.codeplex.com
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.