M>Можно пример из Kotlin, где left, right не теряются?

В Котлин не нужен враппер, поэтому сохраняется исходный тип, как если бы в Скале был case class.

M>Я, кажется, понимаю. Имеется в виду неявное приведение, если переменная сматчилась с каким-то типом?

да, при имплисит конверсии мы потеряли исходный тип и соответственно все имена

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

C>>>Оператор "стрелочка" у них зарезервирован для анонимных функций: "val doubled = ints.map {it => it * 2}".
VD>>Ты внимательно на эту стрелочку посмотри. В типах используется "->". В Нмерле для типов используется "->", а "=>" используется для лямбд (=> — это макрос).
C>Это не такое уж хорошее решение, тогда.

Поздравляю с началом фанатства.

VD>>Зачем в лябде нужны фигурные скобки я так же понять не могу. В лямбдах каждый символ на счету.
C>Фигурные скобки, наверное, можно опускать. Действует то же правило, что и в Java/C. Впрочем, мелочи.

Нельзя. И как раз из-за наличия синтаксиса с it. Иначе нельзя будет определить начало одного и конец другого выражения.

C>>>В принципе, неплохое решение — fun(), сигнатуры и вызовы разделены.
VD>>Где? Ты точно разобрался в синтаксисе?
C>Да. Мне в Скале не очень нравится то, что функциональные типы и лямбды описываются с помощью одного и того же символа "=>". Их разделение мне кажется правильным решением.

Да откуда ты это взял? Для описания типа используется ->, а для лямбд =>. Это уже стало классикой вроде.

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

C>У Котлина как минимум PM по всем иммутабельным типам делается, в том числе и legacy. Генерация hashCode/equals — пока непонятно.

Откуда ты это взял (и про неизменяемость, и про "по всем")?

VD>>Потом я с автором языка общался пару месяцев назад, и он мне четка сказал, что описание берется из определения класса. Вряд ли что-то за это время изменилось.
C>То есть?

Какие из букв непонятны?

VD>>Какие еще на фиг деструкторы? Это ты про Decomposer functions?
C>Деструктуризаторы, не деструкторы — это стандартный термин в PM. Т.е. функции, разбирающие объект на составные части, которые можно использовать в PM.

Нет такой терминологии. Ты ее только что придумал.

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

C>Стоит ли говорить, что после этого использование PM при работе с legacy-кодом превращается в ужас?

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

C>>>Управляющие конструкции (в Kotline есть нелокальный return),
VD>>Чё? Это ты о инлайн-функциях что ли? Можно пример?
C>Ага. http://confluence.jetbrains.net/display/Kotlin/Nonlocal+returns+and+jumps (раздел "Break and continue is custom control structures") — в Скале такое не получается.

Это особенность одного вида функций, а не фича как таковая. И реально это косяк в языке. Просто авторы боятся макросов, которые решают проблему принципиально, вот и выдумали костыль. А ты радуешься этому костылю, так как до этого видел языки и без макросов, и без костылей.

VD>>И что? А если нужно два параметра? И зачем эти скобки? Сравни Шарп:
VD>>

VD>>from s in strings where s.length == 5 orderby s select s.toUpperCase()
VD>>

VD>>или без сахара:
VD>>

VD>>strings.Where(s => s.length == 5).OrderBy(s => s).Select(s => s.toUpperCase())
VD>>

VD>>Можно вбить внятные имена. Нет непонятных скобок. Нет проблем, если параметров у лямбды должно быть несколько.
C>Различие с Котлином будет только в скобках. По мне — пофиг.

Фиксированное имя параметров (it). В общем, на мой взгляд — это весьма спорное решение.

C>>>Это ещё и получше будет, чем в Scala. Особенно учитывая наличие анонимных типов (aka "именованые туплы").
VD>>Как только речь заходит о случаях которые не укладываются в сахар с it, то все становится не так радужно.
C>То есть?

Будет нагромождение не нужных вложенных скобок.

C>Не, ну про implicit так же говорили. А получился ужастик в итоге.

Зависит от того как его готовить и для чего использовать. В Немерле и Шарпе неявное приведение есть, но оно ничему не мешает. Просто в Скале на базе неявного приведения стали эмулировать методы-расширения. Вот это было перебором.

Здравствуйте, QrystaL, Вы писали:
Сколько ж можно клепать одно и тоже? Что лет как есть lisp, haskell, нет мы возьмем java добавим пару фич, и вот новый мега язык готов.

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

D>Здравствуйте, QrystaL, Вы писали:
D>Сколько ж можно клепать одно и тоже? Что лет как есть lisp, haskell, нет мы возьмем java добавим пару фич, и вот новый мега язык готов.

lisp и haskell на другой платформе; здесь же цель увеличить выбор языков под jvm. Судя по всему, если их "клепают", значит существующие не полностью удовлетворяют сообщество

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

A>Сайберакс имеет ввиду что названия .left .right мы потеряли, и нужно вводить свои (t1,t2) или пользоваться анонимными ._1/._2
A>На самом деле нет ни одной причины не объявить Tree как case class. Так что на мой взгляд он просто привередничает
Заметь про то, что мне интересен legacy-код. Да и не всё можно завернуть в case-классы.

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

C>>Ага. http://confluence.jetbrains.net/display/Kotlin/Nonlocal+returns+and+jumps (раздел "Break and continue is custom control structures") — в Скале такое не получается.
M>Отчего же? Есть scala.util.control.Break
Неудобно. Хочется break/continue с метками в циклах for. И без бросков исключений, чтоб работало не со скоростью улитки.

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

C>>3) Null-safety вмонтировано в язык. В Скале только уродский Option, который даже для Pattern matching'а использовать нормально нельзя.
M>Есть NotNull, но его ещё не допилили до человеческого состояния. И это nullable по умолчанию, а не notnull.
M>Почему Option уродский? Почему нельзя нормально использовать для паттерн-матчинга?
Option уродский из-за того, что "Some(4)==4" будет false. Без всяких ошибок во время компиляции.

Это объясняется тем, что Option'ы могут быть вложены друг в друга (абсолютно теоретическая вещь, на практике используется крайне изредка), так что авторазвёртывание Option'ов не стали делать.

C>>7) Именованные параметры, в том числе для туплов.
M>Что имеется в виду?

//Пример 1
def getPoint = (x=1,y=2,z=3)

val f = getPoint()
println(f.x);

//Пример 2
case class GeoPosition(val degLat : Int, val degLong : Int, 
   val height : Int, val minutesLat : Int, val minutesLong : Int, val ts : Timestamp);

x match {
    case GeoPosition(_, _, _, 11) => println("Высота 11 метров!!");
//Упс. Слегка промахнулись. Это не высота, а минуты широты.
...
}

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

C>>Это не такое уж хорошее решение, тогда.
VD>Поздравляю с началом фанатства.
Я тут товарищам помог на Дельфи проект допинать. Мне сейчас синтаксис так пофиг, что вообще.

C>>Фигурные скобки, наверное, можно опускать. Действует то же правило, что и в Java/C. Впрочем, мелочи.
VD>Нельзя. И как раз из-за наличия синтаксиса с it. Иначе нельзя будет определить начало одного и конец другого выражения.
Почему же? "it" будет валиден в пределах одного оператора, как в обычном старом добром С.

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

C>>У Котлина как минимум PM по всем иммутабельным типам делается, в том числе и legacy. Генерация hashCode/equals — пока непонятно.
VD>Откуда ты это взял (и про неизменяемость, и про "по всем")?
Да, вижу что торможу.

VD>>>Какие еще на фиг деструкторы? Это ты про Decomposer functions?
C>>Деструктуризаторы, не деструкторы — это стандартный термин в PM. Т.е. функции, разбирающие объект на составные части, которые можно использовать в PM.
VD>Нет такой терминологии. Ты ее только что придумал.
"Деструктурирующее присваивание" — вполне себе термин.

C>>Стоит ли говорить, что после этого использование PM при работе с legacy-кодом превращается в ужас?
VD>Чудес не бывает. Если информацию о соответствии параметров конструктора полям/пропертям взять неоткуда, то сделать ПМ автоматически будет невозможно. Поверь тому кто занимался этим вопросом не ради интереса.
Ок, верю.

C>>Ага. http://confluence.jetbrains.net/display/Kotlin/Nonlocal+returns+and+jumps (раздел "Break and continue is custom control structures") — в Скале такое не получается.
VD>Это особенность одного вида функций, а не фича как таковая. И реально это косяк в языке. Просто авторы боятся макросов, которые решают проблему принципиально, вот и выдумали костыль. А ты радуешься этому костылю, так как до этого видел языки и без макросов, и без костылей.
Ну ты знаешь моё мнение насчёт макросов.

VD>>>Можно вбить внятные имена. Нет непонятных скобок. Нет проблем, если параметров у лямбды должно быть несколько.
C>>Различие с Котлином будет только в скобках. По мне — пофиг.
VD>Фиксированное имя параметров (it). В общем, на мой взгляд — это весьма спорное решение.
Откуда фиксированное??

arr map {k,v => "Key: "+k+",val: "+v }

Из примеров анонимных функций там.

C>>Не, ну про implicit так же говорили. А получился ужастик в итоге.
VD>Зависит от того как его готовить и для чего использовать. В Немерле и Шарпе неявное приведение есть, но оно ничему не мешает. Просто в Скале на базе неявного приведения стали эмулировать методы-расширения. Вот это было перебором.
И не только расширенные методы, а ещё и DSLи.

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

D>Сколько ж можно клепать одно и тоже? Что лет как есть lisp, haskell, нет мы возьмем java добавим пару фич, и вот новый мега язык готов.
Из подобных языков есть только более-менее близкий OCaml и Go. Оба мало приспособлены для JVM.

C>Заметь про то, что мне интересен legacy-код. Да и не всё можно завернуть в case-классы.

Легаси код в Котле придётся разруливать через implicit def decomposer — так что с точки зрения работы с легаси кодом, вообще разницы нет между Скалой и Котлом

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

C>Почему же? "it" будет валиден в пределах одного оператора, как в обычном старом добром С.

Как без скобок вырзить вот такую лямбду:

x => y => x * y

?

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

C>"Деструктурирующее присваивание" — вполне себе термин.

"Деструктивное" — да. Только это из другой оперы. Это означает "разрушающее", т.е. меняющее что-то по месту.

C>Ну ты знаешь моё мнение насчёт макросов.

Ага. Но уверен, что оно изменилось бы, если бы ты попробовал их на практие.

Кстати, предлагаю провести эксперимент. Могу посодействовать в освоении немерла и его макросов. А потом посмотрим, поменяешь ты свое мнение или нет.

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

C>Откуда фиксированное??
C>

C>arr map {k,v => "Key: "+k+",val: "+v }
C>

Ну, дык и здравствуй совершенно не нужные скобки и описание параметров. Я же говорил о сокращенном синтаксисе с it.

Ну, да ладно. Возможно на меня давлеют привычки.


C>>>Не, ну про implicit так же говорили. А получился ужастик в итоге.
VD>>Зависит от того как его готовить и для чего использовать. В Немерле и Шарпе неявное приведение есть, но оно ничему не мешает. Просто в Скале на базе неявного приведения стали эмулировать методы-расширения. Вот это было перебором.
C>И не только расширенные методы, а ещё и DSLи.

С этим я не знаком. Даже не прдеставляю как на приведении типов делать ДСЛ-и. ДСЛ-ти там вроде бы на неявном параметре функций делают. И в этом плане инлайн-функции в Котлине — это тоже самое, точнее, переработанное решение. В Немерле это решение не нужно, так как макросы отлично решают те же проблемы.

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

C>>"Деструктурирующее присваивание" — вполне себе термин.
VD>"Деструктивное" — да. Только это из другой оперы. Это означает "разрушающее", т.е. меняющее что-то по месту.
Именно что "деструктурирующее" (пример: http://www.bitstampede.com/2006/05/24/destructuring-assignment-part-one/ ). Т.е. разбирающее объект на кусочки.

C>>Ну ты знаешь моё мнение насчёт макросов.
VD>Ага. Но уверен, что оно изменилось бы, если бы ты попробовал их на практие.
Я боюсь, что их будут пробовать другие. Implicit в Scala тоже выглядит неплохо, но вот разбираться в том, что понаписали во всяких там Specs с их помощью — это АДЪ.

VD>Кстати, предлагаю провести эксперимент. Могу посодействовать в освоении немерла и его макросов. А потом посмотрим, поменяешь ты свое мнение или нет.
VD>Обещаю — это будет увлекательно. Нужно только найти достойную, интересную задачу на которой изучать язык.
Я в принципе не хочу работать на .NET-языках, хотя бы из-за того, что не работаю в Windows. А так, с макросами Nemerle я игрался пару лет назад.

C>>И не только расширенные методы, а ещё и DSLи.
VD>С этим я не знаком. Даже не прдеставляю как на приведении типов делать ДСЛ-и. ДСЛ-ти там вроде бы на неявном параметре функций делают. И в этом плане инлайн-функции в Котлине — это тоже самое, точнее, переработанное решение. В Немерле это решение не нужно, так как макросы отлично решают те же проблемы.
В Scala делается так: ключевые слова сделаны в виде объектов, на основании которых имплицитно конструируются обёртки, а дальше с помощью инфиксных фукнций они мутируются.

Самый безобидный пример из Specs:

class helloWorld extends Specification {
  "'hello world' has 11 characters" in {
     "hello world".size must be equalTo(11)
  }
  "'hello world' matches 'h.* w.*'" in {
     "hello world" must be matching("h.* w.*")
  }
}

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

C>>Почему же? "it" будет валиден в пределах одного оператора, как в обычном старом добром С.
VD>Как без скобок вырзить вот такую лямбду:
VD>

VD>x => y => x * y
VD>

VD>?
А что тут такого? Разбираем: (x => (y => x*y)) — два вложенных блока.

Абсолютно аналогично в С:

for(int f=0;f<10;++f)
   if (f==2)
      doSomething();

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

C>Именно что "деструктурирующее" (пример: http://www.bitstampede.com/2006/05/24/destructuring-assignment-part-one/ ). Т.е. разбирающее объект на кусочки.

Ах вот ты о чем. Ясно. Только что за деструктуризаторы ты имеешь в виду? Если речь о функциях, то я уже говорил, что у этого подхода есть два недостатка: 1) он не позволяет порождать быстрый код, 2) он не позволяет вычислять полноту охвата (все ли варианты паттернов присутствуют в сопоставлении с образцом).

C>Я боюсь, что их будут пробовать другие. Implicit в Scala тоже выглядит неплохо, но вот разбираться в том, что понаписали во всяких там Specs с их помощью — это АДЪ.

А что бояться то? Другие уже используют. Жалоб пока нет. Точнее жалобы есть, но только на то что макры не столь гибки как хотелось бы.

Проверено на практике. Нет ни одного человека который бы освоил макросы на практике и при этом бы боялся бы их применения другими.

В общем, мое дело предложить...

C>Я в принципе не хочу работать на .NET-языках, хотя бы из-за того, что не работаю в Windows.

Есть Моно, если что. Проблема только в том, что под Моно (и тем более Линукс) нет IDE. А без нее конечно это все не то.

C>А так, с макросами Nemerle я игрался пару лет назад.

Игрался не считается. Надо написать, пусть небольшое, но реальное приложение в котором требуется МП или ДСЛ. А игры они обычно только неверное впечатление создают.

C>Самый безобидный пример из Specs:
C>

C>class helloWorld extends Specification {
C>  "'hello world' has 11 characters" in {
C>     "hello world".size must be equalTo(11)
C>  }
C>  "'hello world' matches 'h.* w.*'" in {
C>     "hello world" must be matching("h.* w.*")
C>  }
C>}
C>

Это примерно то что предлагается сделать в Котлин. Проблем две: 1) опять же скорость невысокая, так как интерпретация; 2) выразительные возможности ограниченные.

Но где здесь неявные приведения типов?

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

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

C>>>Почему же? "it" будет валиден в пределах одного оператора, как в обычном старом добром С.
VD>>Как без скобок вырзить вот такую лямбду:
VD>>

VD>>x => y => x * y
VD>>

VD>>?
C>А что тут такого? Разбираем: (x => (y => x*y)) — два вложенных блока.

Ты вырази это дело с it или с их синтаксисом но без скобок.

C>Абсолютно аналогично в С:

Причем тут С? Мы кажется о лямбдах речь вели.

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

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

C>>Самый безобидный пример из Specs:
C>>

C>>class helloWorld extends Specification {
C>>  "'hello world' has 11 characters" in {
C>>     "hello world".size must be equalTo(11)
C>>  }
C>>  "'hello world' matches 'h.* w.*'" in {
C>>     "hello world" must be matching("h.* w.*")
C>>  }
C>>}
C>>

VD>Это примерно то что предлагается сделать в Котлин. Проблем две: 1) опять же скорость невысокая, так как интерпретация; 2) выразительные возможности ограниченные.

Влад, откуда ты взял про интерпретацию? "hello world".size must be equalTo(11) — это вполне себе компилируемый кусок кода, а строка выше это описание тесткейса.