Re[8]: Паттерн матчинг классов без where
От: Аноним  
Дата: 10.01.12 15:09
Оценка:
CU>эвристика нужна, она и до этого была, просто строже, маленькие буквы не могли использоваться в качестве имени типов, но я показал что это возможно. Ты наверное не знал до этого ПМ, расскажу как было и как стало:

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

CU>если бы я знал как это делается, никогда этим не занимался, я думаю люди подкованные в компиляторе сами разберутся


у тебя бинарик(и) с патчем. сворачиваешь в архив и вывешиваешь на файлообменник или github.
я не подкован в компиляторе. но потестировать мог бы.
Re[9]: Паттерн матчинг классов без where
От: _Claus_  
Дата: 10.01.12 15:15
Оценка:
А>у тебя бинарик(и) с патчем. сворачиваешь в архив и вывешиваешь на файлообменник или github.
А>я не подкован в компиляторе. но потестировать мог бы.

или влей в мастер. патч ведь ничего не рвет. тогда подберу утреннюю сборку.
Re[9]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 10.01.12 15:29
Оценка:
Здравствуйте, Аноним, Вы писали:

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

А>или это для удобства компилятору?

да это нужно чтобы разрешить неоднозначность того что мы хотим от него, например такие записи:


| o       => // что мы хотим присвоить значение переменной или проверить что переменная имеет этот тип?
| o(a, b) => // что мы хотим присвоить поля объекта типа o, переменным a и b или же хотим проверить что типы полей совпадают с типами a и b?
| O       => // опять переменная или тип?

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

А>у тебя бинарик(и) с патчем. сворачиваешь в архив и вывешиваешь на файлообменник или github.

А>я не подкован в компиляторе. но потестировать мог бы.
тут не просто, там и интеграцию надо собранную инсталлировать, я посмотрю может соберу инсталлятор
Re[10]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 10.01.12 15:30
Оценка:
Здравствуйте, _Claus_, Вы писали:

А>>у тебя бинарик(и) с патчем. сворачиваешь в архив и вывешиваешь на файлообменник или github.

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

_C_>или влей в мастер. патч ведь ничего не рвет. тогда подберу утреннюю сборку.


я без согласования с Владом ничего не делаю, надо подумать над всем этим и сделать тесты, как решим так и зальем в мастер
Re[10]: Паттерн матчинг классов без where
От: Аноним  
Дата: 10.01.12 16:02
Оценка:
CU>[nemerle]
CU>| o => // что мы хотим присвоить значение переменной или проверить что переменная имеет этот тип?
CU>| o(a, b) => // что мы хотим присвоить поля объекта типа o, переменным a и b или же хотим проверить что типы полей совпадают с типами a и b?
CU>| O => // опять переменная или тип?

т. е. вся петрушка из-за того, что вы разрешаете объявить переменную с именем класса? ход неоднозначный, как при любви Влада к строгости
он это терпит? я бы, если мне будет позволено советовать, от такой фичи избавился. все станет простым и понятным.

CU>тут не просто, там и интеграцию надо собранную инсталлировать, я посмотрю может соберу инсталлятор

насколько я помню соглашения, номер сборки роли не играет. а версия в мастере и твоей ветке одинаковая. т. е. твой compiler.dll должен
работать без доп. движений. могу проверить.
Re[11]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 10.01.12 16:14
Оценка:
Здравствуйте, Аноним, Вы писали:

CU>>[nemerle]

CU>>| o => // что мы хотим присвоить значение переменной или проверить что переменная имеет этот тип?
CU>>| o(a, b) => // что мы хотим присвоить поля объекта типа o, переменным a и b или же хотим проверить что типы полей совпадают с типами a и b?
CU>>| O => // опять переменная или тип?

А>т. е. вся петрушка из-за того, что вы разрешаете объявить переменную с именем класса?

вы все понимаете неверно, все это не для того чтобы объявить переменную с именем класса, я вам разъяснил как работала эвристика до этого, если не понимаете суть вопроса, стоит ли вступать в дискуссию? Единственное для чего нужны изменения это поддержка маленьких букв для типов t, в паттернах типа t(a, b) для классов, без ошибок которые давал компилятор. Остальное остается по старому.

А> он это терпит? я бы, если мне будет позволено советовать, от такой фичи избавился. все станет простым и понятным.

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

CU>>тут не просто, там и интеграцию надо собранную инсталлировать, я посмотрю может соберу инсталлятор

А>насколько я помню соглашения, номер сборки роли не играет. а версия в мастере и твоей ветке одинаковая.
версия не одинаковая потому что внесены изменения, и одна сборка ничего не даст, интеграция тоже должна быть собрана на компиляторе
Re[12]: Паттерн матчинг классов без where
От: Аноним  
Дата: 10.01.12 16:30
Оценка:
CU>>>[nemerle]
CU>>>| o => // что мы хотим присвоить значение переменной или проверить что переменная имеет этот тип?
CU>>>| o(a, b) => // что мы хотим присвоить поля объекта типа o, переменным a и b или же хотим проверить что типы полей совпадают с типами a и b?
CU>>>| O => // опять переменная или тип?

А>>т. е. вся петрушка из-за того, что вы разрешаете объявить переменную с именем класса?

CU>вы все понимаете неверно, все это не для того чтобы объявить переменную с именем класса, я вам разъяснил как работала эвристика до этого, если не понимаете суть вопроса, стоит ли вступать в дискуссию?

я искренне пытаюсь понять. то что написано выше иначе у меня в голове не складывается.
берем утверждение
CU>>>| o => // что мы хотим присвоить значение переменной или проверить что переменная имеет этот тип?

если o — это известный тип, то ессно(!) анализ типа.
если o — не тип, ессно это переменная и присвоение ей же.
и далее то же самое. где я чего не понял? и какое другое понимание может быть?
Re[13]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 10.01.12 16:36
Оценка:
Здравствуйте, Аноним, Вы писали:

А>я искренне пытаюсь понять. то что написано выше иначе у меня в голове не складывается.

А>берем утверждение
CU>>>>| o => // что мы хотим присвоить значение переменной или проверить что переменная имеет этот тип?

А>если o — это известный тип, то ессно(!) анализ типа.

А>если o — не тип, ессно это переменная и присвоение ей же.
А>и далее то же самое. где я чего не понял? и какое другое понимание может быть?

ну так вот логика в компиляторе работает так, что запись с начальной маленькой буквы всегда трактуется как переменная в паттерне | o =>
это не я придумал, но это так уже много лет, и далее тоже самое, а записи с большой буквы ВСЕГДА трактуются как типы.
Я решил немного расширить только для записи o(a, b) где o — явно что тип, потому что объявили выражение конструктора, ну и также для | t as var =>
и | var is t =>, где явно что работает с типами. Просто сделать компилятор несколько умнее, что тут непонятного?
Re[14]: Паттерн матчинг классов без where
От: Аноним  
Дата: 10.01.12 16:51
Оценка:
CU>и | var is t =>, где явно что работает с типами. Просто сделать компилятор несколько умнее, что тут непонятного?

понятно, что нелогично. то, что идет за | однозначно вычисляется как тип или переменная без всякого злого колдунства.
а там хотите верьте, хотите нет.
Re[15]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 10.01.12 17:03
Оценка:
Здравствуйте, Аноним, Вы писали:

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

А>а там хотите верьте, хотите нет.

ну так было всегда, злое колдунство тут ненужно, все должно быть предсказуемо. Возможно это самое простое и легко трактуемое решение, когда один паттерн в разных местах программы означает одно и тоже, закладывать сюда типизатор, открыт ли тип или нет, даст каждый раз разные результаты и может дать очень непонятные ошибки. Но мы стараемся безболезненно для людей и компилятора, сделать его умнее, также на основе существующего синтаксиса.
Re[16]: Паттерн матчинг классов без where
От: Аноним  
Дата: 10.01.12 17:25
Оценка:
CU>ну так было всегда, злое колдунство тут ненужно, все должно быть предсказуемо. Возможно это самое простое и легко трактуемое решение, когда один паттерн в разных местах программы означает одно и тоже, закладывать сюда типизатор, открыт ли тип или нет, даст каждый раз разные результаты и может дать очень непонятные ошибки.

пример непонятной ошибки? я ж вот и хочу понять, как она может возникнуть. спать не могу

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


синтаксис хороший, и патч хороший, до идеала рукой подать.
Re[17]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 10.01.12 17:52
Оценка:
Здравствуйте, Аноним, Вы писали:

А>пример непонятной ошибки? я ж вот и хочу понять, как она может возникнуть. спать не могу


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

| A       =>


вы получите ошибку 1) A переменная не использована 2) все что ниже не используется, потому что переменная перекрыла его, вообщем неоднозначности только увеличиваются. Совсем другая эвристика паттернов, это другая тема, тут я уверен у спецов найдутся аргументы почему так не было сделано до сих пор, я углубляться в это не хочу. Вопрос остается открытым, Влад высказался что вроде все выглядит разумным, но пока не смотрел сам код, я скоро выложу сборку, заканчиваться она будет на слово LowerLetterTypesMatch можно качать и пробовать на существующем или новом коде.
Re[10]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 10.01.12 18:02
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>или влей в мастер. патч ведь ничего не рвет. тогда подберу утреннюю сборку.


выложил файл https://github.com/downloads/rsdn/nemerle/NemerleSetup-net-4.0-v1.1.468.0-experimental-LowerLetterTypesMatch.msi

можешь посмотреть существующие примеры, синтаксис без where, а также классы с маленькой буквы
Re[5]: Паттерн матчинг классов без where
От: calc.exe Россия  
Дата: 10.01.12 18:09
Оценка:
Здравствуйте, CodingUnit, Вы писали:

CU>ну предложи что лучше, какой синтаксис был бы логичнее


Предлагаю заменить длинные ключевые слова на одиночные спецсимволы. В примере топикстартера будет так:

class Test
{
  public field : int;
}

// старый синтаксис:
def func1(obj : Test)
{
 match (obj)
 {
   | Test where (field = f) => f
 }
}

// новый синтаксис:
def func2(obj : Test)
{
 match (obj)
 {
   | Test @(field = f) => f
 }
}


Не для Немерле, а для перспективного языка будет следующая серия замен:

with  - #
where - @
<-    - with


В случае ПМ будут краткие односимвольные инструкции. Для понимания их должно хватить. Кроме того высвобождается with для инициализаторов (Snippets] Обновленный макрос with
Автор: catbert
Дата: 13.12.10
) — очень красиво смотрится.
.
Re[18]: Паттерн матчинг классов без where
От: Аноним  
Дата: 10.01.12 18:19
Оценка:
CU>ну ты хочешь весь ПМ сделать на внешней логике, что за запись, есть ли тип такой или нет. Я уже сказал что если типы не открыты, а такое часто бывает

вот как такое бывает? хоть макросом генерим, все равно на финише понятно, тип это или нет. вот в этом затык у меня.
если б вообразить, что такое возможно, то да, а иначе это хомут. я так представляю, что в AST до типов сразу закладывается ограничение. а если так, то проблема там, эту связь надо считать позже. если по логике. F# обходится без такой казуистики. другие наверняка тоже. чем H хуже?
Re[7]: Паттерн матчинг классов без where
От: Ziaw Россия  
Дата: 11.01.12 05:48
Оценка:
Здравствуйте, CodingUnit, Вы писали:

CU>и хотя есть конструктор этого объекта с двумя параметрами он это не воспримет, а просто берет все поля которые есть в объекте,


это тоже кривость правда я не знаю, что тут можно изменить.

CU>точно также работает и с объектом, когда надо можно пользоваться рекорд паттерном, когда надо конструктором. Пока не видно твердых аргументов, имеющих основания, пока просто старая привычка пользоваться старым синтаксисом, просто стоит попробовать новый синтаксис и он выглядит стройно и логично. Если ты говоришь о логике ПМ, то она пока такая же как была раньше для where, так что если мы действуем не как в теории ПМ, если это действительно не правильно, имея конструкторы не матчить по ним, то об этом стоит поговорить отдельно как фич реквест, пока новый синтаксис это минимальное приближение к тому что было, не затрагивая основы.


Убедил. Это менее криво чем сейчас, а до Н2 все равно ничего не исправить. Лучшее враг хорошего.
Re[6]: Паттерн матчинг классов без where
От: Ziaw Россия  
Дата: 11.01.12 07:19
Оценка:
Здравствуйте, calc.exe, Вы писали:

CE>В случае ПМ будут краткие односимвольные инструкции. Для понимания их должно хватить. Кроме того высвобождается with для инициализаторов (Snippets] Обновленный макрос with
Автор: catbert
Дата: 13.12.10
) — очень красиво смотрится.


with будет доступен с новым парсером в nemerle2. Переходить ради него на символы мне совсем не нравятся.
Re[19]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 11.01.12 19:11
Оценка:
Здравствуйте, Аноним, Вы писали:


CU>>ну ты хочешь весь ПМ сделать на внешней логике, что за запись, есть ли тип такой или нет. Я уже сказал что если типы не открыты, а такое часто бывает


А>вот как такое бывает? хоть макросом генерим, все равно на финише понятно, тип это или нет. вот в этом затык у меня.

А>если б вообразить, что такое возможно, то да, а иначе это хомут. я так представляю, что в AST до типов сразу закладывается ограничение. а если так, то проблема там, эту связь надо считать позже. если по логике. F# обходится без такой казуистики. другие наверняка тоже. чем H хуже?

если генерим макросом, каким образом он узнает что это тип? если открыт тип то это тип, если нет то переменная, получается можно корректно сгенерить две макросборки, с разным поведением, вот это багодром тот еще, потом разбирайся что не так в твоей макросборке, что логика не соответствует. Для таких вещей сначала стоит разбираться в общей теории функциональных языков, потом знать сам язык, иметь опыт использования и говорить что могло быть лучше, а пока чистая теория и дискутировать тут сложно. Я не буду углубляться в тему почему так работает ПМ в Немерле, тема у нас другая, если хочешь размышлять на тему почему работает ПМ так, то заводи тему.
Re[6]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 11.01.12 19:18
Оценка:
Здравствуйте, calc.exe, Вы писали:

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


CU>>ну предложи что лучше, какой синтаксис был бы логичнее


CE>Предлагаю заменить длинные ключевые слова на одиночные спецсимволы. В примере топикстартера будет так:


CE>Не для Немерле, а для перспективного языка будет следующая серия замен:


CE>
CE>with  - #
CE>where - @
CE><-    - with
CE>


А чем существующий синтаксис не нравится?

| A(field = f) =>
| A(f)         =>


Если мы для каждой операции будем производить новый символ, то язык будет похож на хаскель (с очень высоким порогом вхождения), или один из эзотерических языков. Такие конструкции понятны автору их, но непонятны для нового человека, который пришел из известных языков. Как мечты на тему: здорово было бы иметь такой синтаксис, годиться, но не более.
Re[7]: Паттерн матчинг классов без where
От: calc.exe Россия  
Дата: 12.01.12 14:05
Оценка:
Здравствуйте, CodingUnit, Вы писали:

CU>Если мы для каждой операции будем производить новый символ, то язык будет похож на хаскель (с очень высоким порогом вхождения), или один из эзотерических языков. Такие конструкции понятны автору их, но непонятны для нового человека, который пришел из известных языков. Как мечты на тему: здорово было бы иметь такой синтаксис, годиться, но не более.


А сколько людей на данный момент вообще знают о pattern matching? Через некоторое время — да, синтаксис станет "естественным". А пока может быть самое время сделать его оптимально удобным. (А where в ПМ, насколько я помню, вообще ввел VladD2 — тут говорить о "традициях" вообще смешно.)
.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.