Re[2]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 08.01.12 20:34
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Не использовать ли для этого оператор инициализации? Всем, кто им пользуется код будет понятен.


CU>>
CU>> match (obj)
CU>> {
CU>>   | Test() <- { field = f } => f
CU>> }
CU>>


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

| Test(field = f) => f


или даже

| Test(f) => f

если поле одно, а тот синтаксис конструктор паттерн и не потянет, хотя вообще какой то другой синтаксис сделать совсем не просто, для where сделано свое PExpr.Where тип в аст, чтобы что то здесь расширять я боюсь придется править и лексер и парсер и дерево и все остальное. Синтаксис Test(field = f) просто живет на существующем синтаксисе, а распознавание на уровне типизации, где раньше был блок что только вариант опции могут работать с таким синтаксисом, теперь уже class, interface, variant. Изменения уже в мастере так что можно тестировать.

Z>Хотя, конечно, две стрелки в разные стороны совсем не радуют мое чувство прекрасного.

согласен
Re[2]: Паттерн матчинг классов без where
От: IT Россия linq2db.com
Дата: 08.01.12 23:15
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Не использовать ли для этого оператор инициализации? Всем, кто им пользуется код будет понятен.


Зачем? Предложенный синтаксис более чем понятен и максимально компактен.
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Паттерн матчинг классов без where
От: _Claus_  
Дата: 08.01.12 23:17
Оценка:
я немного потестил изменение — все нравится.
вот странность есть:

class u
  public h: int = 5
  
module Program 
      
  Main() : void
    
    def g : object = u()        
    
    match(g)
      | u(h) => _ = h
      | _ => {}


error : `u' cannot be variant option, since it starts with lowercase letter

невнятная ошибка, необоснованная, как по мне. особенно учитывая расширение.
Re[3]: Паттерн матчинг классов без where
От: _Claus_  
Дата: 08.01.12 23:33
Оценка:
а это вроде должно работать. вроде ты был согласный. или нет?

class U
  public j: int = 5
  public h: int = 5
  
module Program 
      
  Main() : void
  
    def g : object = U()        
    
    match(g)
      | U(h) => _ = h
      | _ => {}


error: pattern matches 1 values, while the type `U' has 2 fields

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

оно и более компактно, и человечней.

PS каждый пост требует вводить имя и пароль. вдруг. как починить?
Re[4]: Паттерн матчинг классов без where
От: Аноним  
Дата: 09.01.12 00:02
Оценка:
вот даже совместимость можно сделать полную с написанным, — вместо этой ошибки проверить, можно ли завязать поля по именам,
и если нет, тогда ее и показывать. так никому плохо не будет, а некоторым хорошо станет
Re[3]: Паттерн матчинг классов без where
От: Ziaw Россия  
Дата: 09.01.12 04:20
Оценка:
Здравствуйте, IT, Вы писали:

Z>>Не использовать ли для этого оператор инициализации? Всем, кто им пользуется код будет понятен.


IT>Зачем? Предложенный синтаксис более чем понятен и максимально компактен.


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

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

Конечно же where надо менять. Мне оно не нравится примерно по тем же причинам: найдено быстрое и костыльное решение, неплохо выглядящее лишь на первый взгляд. Добавлено ключевое слово к when/with к которым и так новичкам привыкнуть непросто.

P.S. Кстати, те небольшие правки, которыми можно добиться нужного поведения, тестировались на сложных, многовложенных матчах?
Re[4]: Паттерн матчинг классов без where
От: IT Россия linq2db.com
Дата: 09.01.12 06:36
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Тем, что предложен синтаксис вызова конструктора. При этом такого конструктора у типа нет. Вдобавок, матч по конструктору сейчас однозначно ассоциирован с матчем по варианту, зачем терять эту однозначность?


Мне этот синтаксис больше напоминает инициализатор, чем конструктор. А если конструктор, то с параметрами по умолчанию для всех полей класса.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Паттерн матчинг классов без where
От: Ziaw Россия  
Дата: 09.01.12 10:11
Оценка:
Здравствуйте, IT, Вы писали:

Z>>Тем, что предложен синтаксис вызова конструктора. При этом такого конструктора у типа нет. Вдобавок, матч по конструктору сейчас однозначно ассоциирован с матчем по варианту, зачем терять эту однозначность?


IT>Мне этот синтаксис больше напоминает инициализатор, чем конструктор. А если конструктор, то с параметрами по умолчанию для всех полей класса.


Инициализатор это <-. Зачем его напоминать, если он уже есть?
Re[4]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 09.01.12 11:18
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>
_C_>class u
_C_>  public h: int = 5
  
_C_>module Program 
      
_C_>  Main() : void
    
_C_>    def g : object = u()        
    
_C_>    match(g)
_C_>      | u(h) => _ = h
_C_>      | _ => {}
_C_>


_C_>error : `u' cannot be variant option, since it starts with lowercase letter


_C_>невнятная ошибка, необоснованная, как по мне. особенно учитывая расширение.


да это остатки от кода работающего с вариантными опциями, надо подумать что с этим делать, дело в том что когда начинается с большой это явно тип, в ПМ приходится различать что мы матчим типы или переменные, в принципе в o(a, b), o — не может быть переменной, а (a, b) могут быть и тем и другим. Я посмотрю что можно будет сделать в компиляторе.
Re[4]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 09.01.12 11:22
Оценка:
Здравствуйте, _Claus_, Вы писали:

_C_>а это вроде должно работать. вроде ты был согласный. или нет?


_C_> match(g)

_C_> | U(h) => _ = h
_C_> | _ => {}

_C_>error: pattern matches 1 values, while the type `U' has 2 fields


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

_C_>PS каждый пост требует вводить имя и пароль. вдруг. как починить?

не знаю, у меня есть такое, но firefox запомнил пароль, и когда ввожу ник, он пароль подставляет
Re[4]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 09.01.12 11:30
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


Z>Тем, что предложен синтаксис вызова конструктора. При этом такого конструктора у типа нет. Вдобавок, матч по конструктору сейчас однозначно ассоциирован с матчем по варианту, зачем терять эту однозначность?


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

Z>Язык должен быть максимально логичен. В данном случае логикой является легкость реализации и количество символов. Мне это не нравится.

Z>Конечно же where надо менять. Мне оно не нравится примерно по тем же причинам: найдено быстрое и костыльное решение, неплохо выглядящее лишь на первый взгляд. Добавлено ключевое слово к when/with к которым и так новичкам привыкнуть непросто.

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

Z>P.S. Кстати, те небольшие правки, которыми можно добиться нужного поведения, тестировались на сложных, многовложенных матчах?


да, в своей библиотеке я заменил все where на такой синтаксис, там есть и большие вложенные паттерны, пока все работает
Re[5]: Паттерн матчинг классов без where
От: Ziaw Россия  
Дата: 09.01.12 12:19
Оценка: 1 (1)
Здравствуйте, CodingUnit, Вы писали:

Z>>Конечно же where надо менять. Мне оно не нравится примерно по тем же причинам: найдено быстрое и костыльное решение, неплохо выглядящее лишь на первый взгляд. Добавлено ключевое слово к when/with к которым и так новичкам привыкнуть непросто.


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


Так я же предложил. Если для паттерн для варианта по синтаксису совпадает с его конструктором, то паттерн для объекта должен синтаксически совпадать с выражением его инициализации (точнее его подмножеством, имеющим смысл в виде паттерна).
Re[5]: Паттерн матчинг классов без where
От: Аноним  
Дата: 09.01.12 12:35
Оценка:
CU>это правильно, в ПМ паттерн конструктор должен матчить все поля, или опускать с помощью _, иначе это неверно, мы следуем традиции функциональных языков, пока кардинальные изменения в ПМ не собираемся вводить, но стоит пообсуждать.

можно не нарушать традицию, но вместо этой ошибки делать предложенный анализ на возможное сопоставление по именам полей.
более интеллектуальный компилятор — хорошо. меньше кода — тоже хорошо.
Re[6]: Паттерн матчинг классов без where
От: IT Россия linq2db.com
Дата: 09.01.12 14:20
Оценка:
Здравствуйте, Ziaw, Вы писали:

IT>>Мне этот синтаксис больше напоминает инициализатор, чем конструктор. А если конструктор, то с параметрами по умолчанию для всех полей класса.

Z>Инициализатор это <-. Зачем его напоминать, если он уже есть?

<- такое же уродство как и where и является следствием недостаточной расширяемости языка. Надеюсь в следующей версии это будет исправлено.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 09.01.12 15:27
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Так я же предложил. Если для паттерн для варианта по синтаксису совпадает с его конструктором, то паттерн для объекта должен синтаксически совпадать с выражением его инициализации (точнее его подмножеством, имеющим смысл в виде паттерна).


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


| Test where (field = f) => 
| Test() <- {field = f} => // на один символ короче where (не то за что стоит бороться)
| Test() <- {f, f2} => // как определить конструктор? такого синтаксиса нет
| Test(field = f)       =>


ну так он и совпадает:

| Test(f)       =>


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

variant A
{
  | B
    {
      field : int;

      public this(a : int, b : int) {}
    }
 | 
}

    def test = A.B(1);
    match (test)
    {
      | A.B(1, 2) => ... // не скомпилируется
    }


и хотя есть конструктор этого объекта с двумя параметрами он это не воспримет, а просто берет все поля которые есть в объекте, точно также работает и с объектом, когда надо можно пользоваться рекорд паттерном, когда надо конструктором. Пока не видно твердых аргументов, имеющих основания, пока просто старая привычка пользоваться старым синтаксисом, просто стоит попробовать новый синтаксис и он выглядит стройно и логично. Если ты говоришь о логике ПМ, то она пока такая же как была раньше для where, так что если мы действуем не как в теории ПМ, если это действительно не правильно, имея конструкторы не матчить по ним, то об этом стоит поговорить отдельно как фич реквест, пока новый синтаксис это минимальное приближение к тому что было, не затрагивая основы.
Re[5]: Паттерн матчинг классов без where
От: CodingUnit Россия  
Дата: 09.01.12 21:52
Оценка:
Здравствуйте, CodingUnit, Вы писали:

_C_>>error : `u' cannot be variant option, since it starts with lowercase letter


_C_>>невнятная ошибка, необоснованная, как по мне. особенно учитывая расширение.


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


Я реализовал эту функцию, теперь o(a, b) должен матчится правильно, введена следующая эвристика:


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


по идее не должно быть конфликтов, компилятор собирается в двух проходах, но могут быть скрытые недочеты, просьба протестить на разных вариантах, сами изменения сейчас пока не в мастере, а в ветке NowhereMatch главного репозитария, надеюсь разберетесь как ее выкачать
Re[6]: Паттерн матчинг классов без where
От: _Claus_  
Дата: 10.01.12 13:34
Оценка:
CU>Я реализовал эту функцию, теперь o(a, b) должен матчится правильно, введена следующая эвристика:


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


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

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


не мог бы, уважаемый CodingUnit, просто выложить бинарик(и), чтобы желающие тестить просто в bin закинули, не парясь с вытяжкой
и компиляцией. сэкономил бы время всем.
Re[6]: Паттерн матчинг классов без where
От: Аноним  
Дата: 10.01.12 14:25
Оценка:
CU>Я реализовал эту функцию, теперь o(a, b) должен матчится правильно, введена следующая эвристика:


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

CU>


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


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


_C_>матчит переменную это присваивает или сравнивает? и если сравнивает то как — по ссылке или по равенству?

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

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

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


_C_>не мог бы, уважаемый CodingUnit, просто выложить бинарик(и), чтобы желающие тестить просто в bin закинули, не парясь с вытяжкой

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


CU>>Я реализовал эту функцию, теперь o(a, b) должен матчится правильно, введена следующая эвристика:



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

CU>>


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

А>или некрасивый?

раньше не распознавал маленькие буквы в качестве имени типов, например не работал следующий синтаксис:


| o(a, b)  =>
| t as var => 
| var is t =>


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

старая эвристика:
| o       => // всегда просто создает переменную, потому что с маленькой буквы
| o()     => // матчит переменную все равно
| o(a, b) => // отказывается матчить потому что маленькая буква
| O(a, b) => // a и b переменные, O - тип
| O(A, B) => // паттерн конструктор A и B типы, если типов нет или не совместимы с полями, ошибка
| O       => // тип, если типа нет ошибка

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