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. Но я не уверен, насколько это хорошо выписыватся в идеологию и грамматику немерле.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.