Здравствуйте, VladD2, Вы писали:
C>>А что тут такого? Разбираем: (x => (y => x*y)) — два вложенных блока. VD>Ты вырази это дело с it или с их синтаксисом но без скобок.
У них пока нет синтаксиса без скобок.
C>>Абсолютно аналогично в С: VD>Причем тут С? Мы кажется о лямбдах речь вели.
Про то как можно разрешить проблему со скобочным синтаксисом.
Здравствуйте, Курилка, Вы писали:
К>Влад, откуда ты взял про интерпретацию? "hello world".size must be equalTo(11) — это вполне себе компилируемый кусок кода, а строка выше это описание тесткейса.
Большинство интерпретаторов — это вполне себе компилируемые программы. Только от этого гни интерпретаторами быть не перестают.
Проблема эмулируемых ДСЛ-ей в том, что нет четкой возможности преобразовать исходную программу (описываемую в терминах предметной области) в эффективную целевую программу. Вот погляди, например, на макрос PegGrammar. Его исходный язык — это PEG-грамматика. На выходе у него должна быть эффективная реализация алгоритма рекурсивного спуска с откатами. Это подразумевает, что в конечном коде не должно быть объектов, проверок и т.п. Там должен быть тупой С-ишный код. При этом код должен содержать кучу оптимизаций. Эмулируемые ДСЛ-и не позволяют сгенерировать эффективный код. Выходом является только герерация кода в рантайме средствами вроде генерации байт-кода, генерации исходников и последующей их компиляции, или штучек вроде деревьев выражений в дотнете. Но все это сложно. По сему обычно эффективность таких решений в десятки (а то и сотни) раз медленнее оптимальных.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
VD>>Ты вырази это дело с it или с их синтаксисом но без скобок. C>У них пока нет синтаксиса без скобок.
Дык, потому и нет.
Это рубийное решение. Только вместо { a, b | ... } используется { a, b => ... }
C>>>Абсолютно аналогично в С: VD>>Причем тут С? Мы кажется о лямбдах речь вели. C>Про то как можно разрешить проблему со скобочным синтаксисом.
Это проблема не скобок, а приоритетов. Боюсь, что тут так просто ничего не решить. Они не даром выбрали именно такой синтаксис.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, avpavlov, Вы писали:
A>На самом деле нет ни одной причины не объявить Tree как case class. Так что на мой взгляд он просто привередничает
Одна есть — класс может быть библиотечным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, avpavlov, Вы писали:
M>>Можно пример из Kotlin, где left, right не теряются?
A>В Котлин не нужен враппер, поэтому сохраняется исходный тип, как если бы в Скале был case class.
Что-то я не пойму как тип сохраняется. Можно пример матчинга для класса не имеющего дефолтного конструктора?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Это действительно проблема, но Котлин разве её решает?. Точнее решает так же как и Скала — за счёт доп. кода, только называется это здесь decomposer, а в Скале будет implicit def
VD>Что-то я не пойму как тип сохраняется. Можно пример матчинга для класса не имеющего дефолтного конструктора?
Имеется ввиду, что там матчинг можно делать для любого класса с конструктором определённого вида, а в Скала — только для case класса. Соответственно, если есть аллергия на case class, то придётся имплисит ковертор в тупл делать с потерей исходного типа.
В Котле этого якобы не надо — за что он Сайбераксу понравился.
Ну а я считаю, что хочешь делать п.матчинг — ну и поставь case class, делов-то.
А библиотечные Java-классы, которые трогать нельзя и там и там придётся оборачивать вспомогательным кодом, который пишется один раз и всё — тоже не вижу проблемы.
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, Kernan, Вы писали: K>>Какую конкретно нишу?
QL>The language way simpler than the most mature competitor – Scala.
Такая меня мысль посетила — сам язык ДжетБрэйну без надобности. Писали значит от скуки — есть ресурсы, есть деньги, давайте из интереса язык напишем.
Соответственно, если язык написан от скуки, то они будут его дописывать и дописывать. А значит он будет стремиться к Скале, теряя свою простоту
Здравствуйте, Cyberax, Вы писали:
M>>Почему Option уродский? Почему нельзя нормально использовать для паттерн-матчинга? C>Option уродский из-за того, что "Some(4)==4" будет false. Без всяких ошибок во время компиляции.
О, как? Это конечно уродство.
C>Это объясняется тем, что Option'ы могут быть вложены друг в друга (абсолютно теоретическая вещь, на практике используется крайне изредка), так что авторазвёртывание Option'ов не стали делать.
Не нужно никакое авторазвертывание. Это был бы еще тот баг в дизайне. А вот выражение "Some(4)==4"
должно давать ошибку времени компиляции, а не false.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, avpavlov, Вы писали:
A>Имеется ввиду, что там матчинг можно делать для любого класса с конструктором определённого вида, а в Скала — только для case класса. Соответственно, если есть аллергия на case class, то придётся имплисит ковертор в тупл делать с потерей исходного типа.
Ну, это какая-то вкусовщина. Считай что Колтиновские классы с дефолтным конструктором все являются кэйс-классами. Вот и все.
Технически для реализации ПМ нужно не бирка "кэйс", а информация о соответствии параметров конструктора (можно даже выдуманного) полям/свойствам типа (даже классом быть не обязательно). Это нужно так как в ПМ образец описывает объект через его конструктор. Так что нужна любая форма задания этого соответственно. Дефолтный конструктор прекрасно решает эту задачу для описываемых вновь типов.
A>В Котле этого якобы не надо — за что он Сайбераксу понравился.
На мой взгляд без разницы. Все равно МП возможен только для определенного рода типов. По типам Явы он точно будет невозможен.
A>Ну а я считаю, что хочешь делать п.матчинг — ну и поставь case class, делов-то.
Согласен. Хотя лучше было бы предусмотреть возможность делать ПМ по любому типу. В Немрле это возможно, например.
A>А библиотечные Java-классы, которые трогать нельзя и там и там придётся оборачивать вспомогательным кодом, который пишется один раз и всё — тоже не вижу проблемы.
При оборачивании будут потери в скорости и качестве контроля со стороны компилятора. Только для замкнутых кейс-классов (они же варианты немерла или ограниченные объединения МЛ-я) можно обеспечить контроль компилятора. А без этого будет много граблей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, avpavlov, Вы писали:
A>Такая меня мысль посетила — сам язык ДжетБрэйну без надобности. Писали значит от скуки — есть ресурсы, есть деньги, давайте из интереса язык напишем.
Ошибочная мысль. Они же свою Идею на Яве пишут. Надоело им она. Вот и решили упростить себе и другим
жизнь.
A>Соответственно, если язык написан от скуки, то они будут его дописывать и дописывать. А значит он будет стремиться к Скале, теряя свою простоту
Там отправные посылки — сделать язык мощнее Явы, похожий на Скалу, но не такой сложный как Скала и с отличной поддержкой ИДЕ (читай Идеи). Так что этого не должно случиться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Ошибочная мысль. Они же свою Идею на Яве пишут. Надоело им она. Вот и решили упростить себе и другим VD>жизнь.
Ну не знаю, не знаю. Я вот не в курсе к сожалению, Студию переписали на дотНет?
Да и вообще, целиком переписать — долго.
A>>Соответственно, если язык написан от скуки, то они будут его дописывать и дописывать. А значит он будет стремиться к Скале, теряя свою простоту
VD>но не такой сложный как Скала и с отличной поддержкой ИДЕ (читай Идеи).
Сомневаюсь, что удержатся они на позициях простоты. Когда есть умения и желание и хочется их куда-то приложить, трудно удержаться
Здравствуйте, avpavlov, Вы писали:
A>Здравствуйте, QrystaL, Вы писали:
QL>>Здравствуйте, Kernan, Вы писали: K>>>Какую конкретно нишу?
QL>>The language way simpler than the most mature competitor – Scala.
A>Такая меня мысль посетила — сам язык ДжетБрэйну без надобности. Писали значит от скуки — есть ресурсы, есть деньги, давайте из интереса язык напишем.
Если ты читал ссылку заглавную, то там написано, что JetBrains 200 мегобайт сорцов на джаве. 200 СОРЦОВ. Это безумная цифра, на самом деле. Скорее всего их реально за№@%ла жаба. ПРи таком кол-ве сорцов и людей, которые более менее в теме языков прог-ния(а сам понимаешь, в компании, которая делает IDE специалистов по ЯП достаточно) написать новый ЯП под туже платформу — это не самая глупая идея.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>Влад, откуда ты взял про интерпретацию? "hello world".size must be equalTo(11) — это вполне себе компилируемый кусок кода, а строка выше это описание тесткейса.
VD>Большинство интерпретаторов — это вполне себе компилируемые программы. Только от этого гни интерпретаторами быть не перестают.
[cut]
По-моему ты на не на мой вопрос отвечаешь, задам тогда попроще: Scala — интерпретатор? (Specs, код для которой был приведён — библиотека на Scala, если что)
Здравствуйте, avpavlov, Вы писали:
A>Здравствуйте, QrystaL, Вы писали:
QL>>Здравствуйте, Kernan, Вы писали: K>>>Какую конкретно нишу?
QL>>The language way simpler than the most mature competitor – Scala.
A>Такая меня мысль посетила — сам язык ДжетБрэйну без надобности. Писали значит от скуки — есть ресурсы, есть деньги, давайте из интереса язык напишем.
A>Соответственно, если язык написан от скуки, то они будут его дописывать и дописывать. А значит он будет стремиться к Скале, теряя свою простоту
Мы хотим писать идею на котлине сразу же, как только котлин хоть как-то задышит...
Здравствуйте, avpavlov, Вы писали:
VD>>Ошибочная мысль. Они же свою Идею на Яве пишут. Надоело им она. Вот и решили упростить себе и другим VD>>жизнь.
A>Да и вообще, целиком переписать — долго.
Долго? Это гмм скорее вопрос написания конвертера исходников Java -> Kotlin.
Здравствуйте, VladD2, Вы писали:
M>>>Почему Option уродский? Почему нельзя нормально использовать для паттерн-матчинга? C>>Option уродский из-за того, что "Some(4)==4" будет false. Без всяких ошибок во время компиляции. VD>О, как? Это конечно уродство.
Ага. Я на этой ошибке уже кучу отладочного времени потратил.
C>>Это объясняется тем, что Option'ы могут быть вложены друг в друга (абсолютно теоретическая вещь, на практике используется крайне изредка), так что авторазвёртывание Option'ов не стали делать. VD>Не нужно никакое авторазвертывание.
Почему же? Авторазвёртывание вполне определено и удобно, с семантикой как в SQL'е. В Kotlin'е сделали всё правильно.
А ошибку компиляции здесь сделать трудно, так как equals() обязан работать с объектами разного типа.
