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

_C_>все таки как быть с текущим косяком (чувствительность к регистру), неужели все согласны оставить?

Ну вот Бейсик к регистру не чувствителен и что-то никому Бейсик не нравится.

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

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

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

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

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

Тут опять же на помощь приходят макросы, можно например сделать такой:

look_obj match (obj)
{
 | x() => // здесь получаете содержимое x
}

суть этого макроса проста, надо просканировать дерево выражений и найти использование членов класса obj, для этого надо знать его тип, он задается паттерном, берете его члены и смотрите не ссылается ли какое то выражение типа PExpr.Ref на такое имя и подставляете туда объект. Вообщем такой код:

look_obj match (obj)
{
 | x() => Use(field1, Method2()) // здесь field1 и Method2 принадлежат объекту, но неоднозначности надо отслеживать
}

// макросом надо переписать в такой:

match (obj)
{
 | x as id => Use(id.field1, id.Method2()) // здесь field1 и Method2 принадлежат объекту, но неоднозначности надо отслеживать
}

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

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

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

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

| x            => // переменная
| x()          => // может быть класс
| x(a, b)      => // все основные паттерны работают с типом нач.нам маленькую букву
| x(field = a) =>
| x as var     =>
| var is x     =>

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

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

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

Когда-то давно у меня было сообщение именно на эту тему Несогласованность в языке

Автор: calc.exe
Дата: 11.10.10

.

А вообще у меня предложение самое радикальное. Я предлагаю внутри языка полностью запретить типы/варианты/перечисления с маленькой буквы. Импортированный тип с маленькой буквы, если уж таковой случиться, тогда нельзя будет использовать в pattern matching. А что? Подобные случаи очень редки и их можно разрулить с помощью обычной логики на ифах. А в ПМ идентификатор с маленькой буквы автоматически будет только переменной.

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

CE>А вообще у меня предложение самое радикальное. Я предлагаю внутри языка полностью запретить типы/варианты/перечисления с маленькой буквы. Импортированный тип с маленькой буквы, если уж таковой случиться, тогда нельзя будет использовать в pattern matching. А что? Подобные случаи очень редки и их можно разрулить с помощью обычной логики на ифах. А в ПМ идентификатор с маленькой буквы автоматически будет только переменной.

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

// уже устал одно и тоже везде писать
| x   => // переменная
| x() => // пожалуйста используйте тип с маленькой буквы, только покажите скобками
| SomeEnum.a => // тоже подойдет если у вас перечисление

Здесь введена доп эвристика для x() что если конструктор (), то это тип, также в is, as, так что пожалуйста используйте, теперь это возможно, но товарищ начал с того что ему этого мало, ему надо чтобы все записи считались типами, но целый день сегодня об этом говорим, это не совсем то. Так что радикализм хорошо, но мы не совсем консерваторы чтобы вообще исключать возможные улучшения, разумный синтаксис вводиться, и он как правило совместим со старым решением. Экспериментальная версия с работающим синтаксисом из печи уже лежит в разделе Downloads, попробуйте и/или выдвигайте разумные доводы/аргументы.

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

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

CU>

CU>| a() => // тоже подойдет если у вас перечисление

CU>

с перечислением тот же синтаксис действует

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

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

Нет, эта фича — для многократного ухудшения читабельности кода, так как понять, что означает имя в обработчике матча можно только видя, откуда оно взялось. А предлагаемая фича скрывает самый ближний и наиболее вероятный источник имен. То есть вместо того, чтобы взглянув на строчку-две выше увидеть, что имя является полем сматченного объекта, придется удостовериться, что это не локальная переменная, объявленая выше и не поле текущего объекта. Ещё хуже скрытная подмена локальных переменных и полей инстанса (как показывалась выше). До кучи — появляющаяся опасность расширения уже существующих классов. Спасибо, мы такой радости ещё в Delphi наелись по самое нехочу...

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

Mumitroller

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

A>если страх велик, а фича нравится, могу предложить его эксплист вариант

A>match(var)
A>{
A> x() => // если у x есть fld1, fld2, то сразу можно написать
A> methodn(.fld1, .fld2)
A>}

A>так неоднозначности не будет даже при расширении.

Да, в таком виде вроде все проблемы решаются.

Mumitroller

Здравствуйте, _Claus_, Вы писали:
_C_> x() =>

это слишком жостко

Хотя бы x(*) и только для рекордов и вариантов, хотя, ИМХО, не нужная фитча, только неясность вносит (чтобы понять что ты хочешь ушло минут 8)

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

BM>Здравствуйте, _Claus_, Вы писали:
_C_>> x() =>

BM>это слишком жостко

BM>Хотя бы x(*) и только для рекордов и вариантов, хотя, ИМХО, не нужная фитча, только неясность вносит (чтобы понять что ты хочешь ушло минут 8)

Если так то надо просто ввести в язык правило проверки — тип с только с большой переменная только с маленькой и проверять выдавать на нарущение ошибку.