Scala, красиво инициализировать массив

val x = Array.ofDim(10)
(0 until x.length) foreach(x(_)=5)

?

Хотя тот же самый цикл

Уупс

val x = Array.ofDim[Int](10)
(0 until x.length) foreach(x(_)=5)

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

Мне тут не нравится x.length. Как то бы выкинуть это, тоесть просто пройтись по всему массиву

Да вроде без цикла тут никак. Вот если бы не нужно было в условии использовать существующий массив, то все было бы проще:

Array.fill(10)(5)

val a = (for (x <- 1 until 10) yield 5).toArray ?

Хз насчет красоты, пишу на Scala недавно.

А, все понял, не то. Тебе в существующий нужно.

Closure бы сюда, ибо рендом не работает. Но да, оно не в сущестующий

Array.fill(10)(java.lang.Math.random)

?

Работает, но не в существующем массиве

Ну тогда, как уже упоминал theos, только цикл. Ну или менять условия задачи чтоб функциональщину во все поля :-)

да и по эффективности лучше уж тогда просто новый массив создать.

почему?

>> да и по эффективности лучше уж тогда просто новый массив создать.

почему?

Да потому что он и так создается - так чегоже добру зря пропадать :)

У меня в цикле 100500 раз

arr.map(_ => Random.nextInt).copyToArray(arr)

5 баллов! блин выкрутились круто, одобряю.

Но по сути вопроса не подходит ибо внутри будет создан все равно список, почему бы просто не создать новый и так. Я хочу экономить на new

Ещё можно так:

arr.indices.foreach(arr(_) = Random.nextInt)

А хотите экономить пишите на Си )

Божественно, спасибо.

>> arr.indices.foreach(arr(_) = Random.nextInt)

Божественно

А чем это отличается от цикла?

Нет уродливых length и _теоретически_ не обязуется исполняться последовательно насколько я понял. А если так, то возможен параллелизм. Естественно теоретически, ибо автоматический параллелизм где не надо - не очень торт

> Нет уродливых length и _теоретически_ не обязуется исполняться последовательно насколько я понял.

Т.е. от первого же представленного варианта, (0 until x.length) foreach(x(_)=5), это отличается только тем, что length спрятан в indices?

Вообще да ) Они все не идеальны. Идеалом был бы какой нибудь a.foreach(_=rnd), но упоротые сделали переменную в foreach immutable

Ну ещё лучшей читаемостью и меньшим пространством для ошибки. Например нет шансов написать to вместо until, 1 вместо 0, меньше возможности перепутать массивы

меньше возможности перепутать массивы

вообще можно

кхе-кхе... а у Random.nextInt как насчет распараллеливания?

> но упоротые сделали переменную в foreach immutable

По-моему ты фигней страдаешь :)

Лучше бы Common Lisp подучил. Наверняка, там такое можно сварганить :)

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

Думаю да, наверное можно. Мощный язык, но к большому несчастью не нужен

Добавлю, _уже_. Вклад внес гигантский в развитие IT

Оптимизировать Scala еще очень есть куда, обьектами сорит ужасно

Не согласен. В лиспе еще есть вещи, которых нет в других языках/платформах. Не все использовали. Взяли только то, что могли.

Кстати, мне лично нужен. Жаль только, что лисп с возможностью делать приложения с красивым GUI стоит денег. Я имею ввиду LispWorks.

Что касается скалы, она не только жручая до памяти, но и ужасно монструозная. Я понимаю, классы типов через имплисыты - это клево, но выглядит это жутковато. Да, и отсутствие TCO делает недавно введенные продолжения почти бесполезными. Плюс, for-comprehension выглядят непродуманной вещью по сравнению с computation expressions из F#: тогда не надо было бы, вообще, писать плагин к компилятору скалы для поддержки продолжений. Анбоксинг тоже не самая лучшая штука, если пишешь в функциональном стиле, но это как и TCO камни в огород JVM.

Ну, еще что-то мне не понравилось. Хотя не безрыбье скала очень хороша. Конечно, если не дают писать на Common Lisp :)

> Жаль только, что лисп с возможностью делать приложения с красивым GUI стоит денег. Я имею ввиду LispWorks.

сейчас должен прийти Архимаг и объяснить тебе, что красивый современный GUI запросто делается на JS (а CL в качестве «сервера приложений»)

Там же есть оптимизация TCO и аннотация @tailrec

@tailrec гарантирует, что либо рекурсивный код будет преобразован в цикл, либо будет ошибка компиляции. То есть, гарантия того, что все прошло нормально.

Но это не все TCO. Хвостовые вызовы еще должны оптимизироваться на уровне среды исполнения. Здесь это виртуальная машина JVM. Поскольку далеко не любой код, полагающийся на TCO, может быть преобразован к циклам. Пример - продолжения.

> сейчас должен прийти Архимаг и объяснить тебе, что красивый современный GUI запросто делается на JS (а CL в качестве «сервера приложений»)

А его что-то давно не видно :)

Веб - stateless. Апликуха же обычно stateful. И никак это противоречие нельзя победить. Существующие попытки тщетны. Например, ASP.NET передает состояние в скрытых полях, но это же никуда не годится!

А вы scalaz смотрели, конкретнее к примеру state monad. (В целом, библиотека классная, требует конечно определенных знаний). Считай на каждое изменение состояние создается экземпляр типа Tuple2[_,_]. Так что да - на объектах не экономим в угоду, удобству, выразительности и чистоте.

Но я так понял что это для pure functional, и скала потому и хороша, что не pure functional, так как оно не нужно

Т.к. не знаю что такое computation expression в F# - можно краткий экскурс? Что бы уж понять что не так с for-comprehension в scala.

+1

Кстати, удобный случай пропробовать исходя из вашего задания - есть изменяемый массив, так, как говориться for fun :)

Попробую

Синтаксический сахар для монад и моноидов. Более общий, чем for-comprension в скале или do-синтаксис в хаскеле. Например, там поддерживаются for, while, use, try. Последние преобразуются в функциональную форму.

В общем, получается так, что можно внутри вычислительного выражения (computation expression) писать обычный или почти обычный код на f#, который затем будет преобразован (интерпретирован) в функциональное выражение, соответствующее той или иной монаде или моноиду. Конечно, есть аналог flatMap.

В качестве примера можно взять f# sequence expression, который позволяет красиво задавать последовательности, разбавляя почти обычный код в нужных местах конструкциями yield и yield!, через которые собственно и формируется возвращаемая последовательность.

Посылка в том, что вычислительные выражения сделали бы излишним написание плагина к компилятору скалы для поддержки продолжений. Похожая на продолжения вещь в f# называется async worklflow, и она полностью определена на самом f# без дополнительной поддержки со стороны компилятора. Кстати, в async три продолжения используются вместо одного.

За дополнительной информацией лучше обратиться к учебникам.

Хм, почему неэффективно? Один вызов foreach, одна функция f: A => B применяемая для каждого элемента последовательности и тот же цикл с tail/head.

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

>Хм, почему неэффективно?

Потому-что скорее всего создаётся отдельный класс (та самая функция), это раз, потом создаётся объект этого класса, это два, потом происходит динамический вызов (или не дай бог виртуальный вызов), это три. Хотя если в foreach вписывается конкретный код, а не подставляется именно сторонняя функция, кто запрещает всё заинлайнить?

Что в вашей терминологии виртуальный и что такое динамический?

>Что в вашей терминологии виртуальный и что такое динамический?

угу, сморозил, имелось в виду invokevirtual и invokeinterface

хотя якобы после энного количества вычислений данного кода VM может сообразить, что класс только один, и «остатичить» его, а то и заинлайнить. Но это зависит от многих прочих...

foreach это higher-order функция, поэтому про вписывание конкретного код не совсем ясно, впрочем как и про создание отдельного класса.