match(l:list[string])
{
| '0'::tail => WriteLine("ok"); //Значение головы нужно
| '1'::tail => WriteLine("ok"); //Значение головы нужно
| '2'::tail => WriteLine("ok"); //Значение головы нужно
| '3'::tail => WriteLine("ok"); //Значение головы нужно
| '4'::tail => WriteLine("ok"); //Значение головы нужно
| '5'::tail => WriteLine("ok"); //Значение головы нужно
| _ => WriteLine("bad");
}
AB>def ok_list = ["0", "1", "2", "3"]; //а вот тут можно список правильных вариантов дописывать
AB>
Согласен, только лучше вместо списка использовать Set. Его можно взять или в 3.5 фрэймворке (System.Collections.Generic.HashSet), подключив %ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll, или в пространстве имен Nemerle.Collections.Set.
def pattertns = System.Collections.Generic.HashSet(["1", "2", "3", "4"]);
//def pattertns = Nemerle.Collections.Set(["1", "2", "3", "4"]);
def res = match (["1"])
{
| s :: _ when pattertns.Contains(s) => true
| _ => false
}
Первй по шустрей так как основан на хэшировании, второй фунциональный, что позволяет хранить множество вариантов Set-а отличающихся одним-двумя элементами (без излишних трат памяти).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, z00n, Вы писали:
Z>А так Nemerle допускает? Если нет, то студент, который писал для Nemerle паттерн матчинг — халтурно реализовал Or-patterns Z>
let test lst =
match lst with
| "1"|"2"|"3"|"4"|"5"as h::tail -> h ^ ", ok"
| _ -> "bad"
;
#
val test : string list -> string = <fun>
# test ["1";"33";"35"];;
- : string = "1, ok"
# test ["3";"33";"35"];;
- : string = "3, ok"
# test ["5";"33";"35"];;
- : string = "5, ok"
# test ["6";"33";"35"];;
- : string = "bad"
Резюмируя — есть на свете языки, где оператор `|` можно использовть между любыми паттернами, а не только между верхнеуровневыми guerded_patterns(в терминологии Nemerle). Nemerle не из таких, что само по себе не ужасно — у Haskell, например, тоже нет or-patterns, а у SML по стандарту 97 года нет даже гардов.
IT>Если же всё же отходить в сторону от поставленной задачи, то можно было написать так:
IT>
Здравствуйте, z00n, Вы писали:
Z>А так Nemerle допускает? Если нет, то студент, который писал для Nemerle паттерн матчинг — халтурно реализовал Or-patterns Z>
Здравствуйте, z00n, Вы писали:
Z>Резюмируя — есть на свете языки, где оператор `|` можно использовть между любыми паттернами, а не только между верхнеуровневыми guerded_patterns(в терминологии Nemerle). Nemerle не из таких, что само по себе не ужасно — у Haskell, например, тоже нет or-patterns, а у SML по стандарту 97 года нет даже гардов.
Дело не в языках. Дело в том, что это уже невозможно просто читать. Одно из достоинств ПМ как раз улучшить читаемость кода и распутать запутанные алогоритмы. А тут ситуация в точности обратная.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, z00n, Вы писали:
IT>Дело не в языках. Дело в том, что это уже невозможно просто читать. Одно из достоинств ПМ как раз улучшить читаемость кода и распутать запутанные алогоритмы. А тут ситуация в точности обратная.
Мне не кажется, что or-patterns ухудшают читабельность, скорее наоборот. Любые or-patterns можно расписать — по клаузе на каждый случай(как вы и продемонстрировали) — но странно делать это руками, если есть компилятор. Связывание or-patterna c переменной в Ocaml с непривычки выглядит и впрямь несколько странно, но можно скобки добавить.
Да, спасибо, я знаю, и даже разбирался с этим самым алгоритмом для своих целей. Он годится для любого языка, даже статическая типизация влияет лишь на одну оптимизацию (span). Для ML он лишь в том смысле, что в бумаге описано лишь как компилировать VarPattern и ConstructorPattern — AsPattern, Guards и TypeConstraintPattern студенту пришлось придумывать самому. Мое замечание имело в виду, что на OrPattern он явно спасовал (при том, что разрешил опускать одинаковую правую часть у паттернов верхнего уровня)
Здравствуйте, z00n, Вы писали:
IT>>Дело не в языках. Дело в том, что это уже невозможно просто читать. Одно из достоинств ПМ как раз улучшить читаемость кода и распутать запутанные алогоритмы. А тут ситуация в точности обратная.
Z>Мне не кажется, что or-patterns ухудшают читабельность, скорее наоборот. Любые or-patterns можно расписать — по клаузе на каждый случай(как вы и продемонстрировали) — но странно делать это руками, если есть компилятор. Связывание or-patterna c переменной в Ocaml с непривычки выглядит и впрямь несколько странно, но можно скобки добавить.
Вполне допускаю, что это дело привычки и на таком простом варианте это выглядит в общем-то ещё ничего. Я просто думаю о том, куда может разыграться фантазия и как с этим потом бороться.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, z00n, Вы писали:
Z>Мне не кажется, что or-patterns ухудшают читабельность, скорее наоборот. Любые or-patterns можно расписать — по клаузе на каждый случай(как вы и продемонстрировали) — но странно делать это руками, если есть компилятор. Связывание or-patterna c переменной в Ocaml с непривычки выглядит и впрямь несколько странно, но можно скобки добавить.
Со скобками было бы ничего (логично и понятно). А так, откровенно говоря вводит в заблуждение.
Что касается привычек, то когда в языке к слишком многому нужно привыкать, то язык становится сложным для изучения. Это беда большинства ФЯ. Очень не хотелось бы, чтобы новые гибриды так же страдали этим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, z00n, Вы писали:
Z>Мое замечание имело в виду, что на OrPattern он явно спасовал (при том, что разрешил опускать одинаковую правую часть у паттернов верхнего уровня)
ОК.
1. Можно спросить почему так прямо у "студента".
2. Можно внести фича-реквест в багтрекер (только, на мой взгляд, лучше в обязательном порядке использовать скобки) и ждать пока его реализуют, или даже попытаться сделать это самостоятельно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
