https://ru.wikipedia.org/wiki/Haskell#.D0.90.D0.BB.D1.8C.D1.82.D0.B5.D1.80.D0.BD.D0.B0.D1.82.D0.B8.D0.B2.D0.BD.D1.8B.D0.B5_.D1.86.D0.B5.D0.BB.D0.B5.D0.B2.D1.8B.D0.B5_.D0.BF.D0.BB.D0.B0.D1.82.D1.84.D0.BE.D1.80.D0.BC.D1.8B да простят меня за ссылку на вики, но

frege - не совсем Haskell. а вот eta это прям настоящий GHC для JVM, с поддержкой современных прагм, и последнее время делает большие успехи

ага, у меня примерно такие же ощущения были насчет frege. А что за успехи делает eta?

всё субъективно конечно, но во-первых в списке вещей, которые работают на ETA (http://eta-lang.org/playground.html) есть много библиотек, которые работают на продвинутых GHC прагмах и используют всякую магию. во-вторых, документация, по-моему очень исчерпывающая и удобная. в-третьих, платформа ведь очень-очень молодая, и за этот промежуток они добились несравнимо большего хайпа чем тот же frege. ну и в-четвертых собственно хайп. опять очень субъективно, но я часто вижу в твиттере как разные люди нахваливают эту штуку

Привет, ребята. Я хочу запустить библиотеку хаскель из си++ кода, использую Repa и хочу чтобы она использовала все ядра. Конкретнее, как передать флаги +RTS -N4 внутри си кода?

frege - не совсем Haskell. а вот eta это прям настоящий GHC для JVM, с поддержкой современных прагм, и последнее время делает большие успехи

eta можно забыть, когда они решили форкать и жить на 7.10

Привет, ребята. Я хочу запустить библиотеку хаскель из си++ кода, использую Repa и хочу чтобы она использовала все ядра. Конкретнее, как передать флаги +RTS -N4 внутри си кода?

ну там hs_init принимает же сточку с параметрами?

/* Like hs_init(), but allows rtsopts. For more complicated usage, * use hs_init_ghc. */ extern void hs_init_with_rtsopts (int *argc, char **argv[]);

вот туда и передать, через argv

вот туда и передать, через argv

Ок. Спасибо. Сейчас будем пробовать. :)

всё субъективно конечно, но во-первых в списке вещей, которые работают на ETA (http://eta-lang.org/playground.html) есть много библиотек, которые работают на продвинутых GHC прагмах и используют всякую магию. во-вторых, документация, по-моему очень исчерпывающая и удобная. в-третьих, платформа ведь очень-очень молодая, и за этот промежуток они добились несравнимо большего хайпа чем тот же frege. ну и в-четвертых собственно хайп. опять очень субъективно, но я часто вижу в твиттере как разные люди нахваливают эту штуку

Насколько понял с их сайта они под интеграцию с ЕЕ метят, а чокак с ведроидом у них?

Насчет ведроида - понятия не имею. Думаю, ещё очень рано о таких вещах говорить. Им бы хотя бы первую публичную версию выпустить

очень вовремя вопрос про ведроид был: https://twitter.com/rahulmutt/status/856485328449875969

я не понимаю как про ету можно серьезно говорить..

я не понимаю как про ету можно серьезно говорить..

поясните

eta не развивается в месте с гхц, в которого вкладывается труд большого числа людей

если этого не делать то прыгнуть на другой релиз будет совсем не реально

они зафризились на 7.10 и будут там вечно торчать без шансов развития

если случайно не появится очень жирный инвестор

в этом отношении ghcjs гораздо правильнее

в этом отношении ghcjs гораздо правильнее

как-то странное сравнение. разные целевые платформы и разная ситуация ghcjs кажется одна команда с ghc или нет?

почему странное? и то и другое проекты основанные на ghc еомпилирующие под другую пратформу

ghcjs один luite

eta - один, не помню его имя

ну + контрибьюторы

ghcjs принято решение распространять и развивать с ghc

eta принято решение форкнуться в произвольном моменте

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

ghcjs один luite

ну тогда ладно.

мне сложно оценить сколько труда требуется для того чтобы перевести ETA с 7.10 на 8, полагаю что правда очень много. но ведь и портировать 7.10 на JVM тоже не мало

на сайте написано что переход будет осуществляться постепенно

для меня это все равно гораздо лучше чем frege, который вовсе не хаскель и не хочет им быть

я не то чтоб хотел кого-то убедить в том что ETA это хорошо. просто вот так со счетов тоже по-моему неправильно сбрасывать

http://eta-lang.org/docs/html/faq.html#will-eta-be-compatible-with-ghc-8

ну он форкнул когда ему не хватило сил держаться в темпе развития ghc

возможно. возможно это даже было не лучшее решение и у него была альтернатива получше, мы это вряд ли узнаем. но это не отменяет того что у ETA есть все шансы стать лучшим способом писать хаскель на JVM, поднять денег и развивать платформу

для меня сейчас лучший способ писать хаскель на jvm это scalaz. что далеко не так круто как ghc 7.10

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

в жвм наоборот приятно не иметь статическую систему типов

https://www.youtube.com/watch?v=TS1lpKBMkgg

лучше обмазывайтесь кложей

ну что вам эта скала

да я вот на кложе паразитирую

она не сделает никого счастливым

в жвм наоборот приятно не иметь статическую систему типов

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

в идеале бы создавать систему типов под задачу

Работа с большим количеством связанных типов без потери модульности при разработке больших систем – задача очень трудная, и в этой области сейчас ведется много исследований - (с) SICP Взято отсюда https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-18.html#%_sec_2.5.2

If the data types in our system can be naturally arranged in a tower, this greatly simplifies the problems of dealing with generic operations on different types, as we have seen. Unfortunately, this is usually not the case. Figure 2.26 illustrates a more complex arrangement of mixed types, this one showing relations among different types of geometric figures. We see that, in general, a type may have more than one subtype. Triangles and quadrilaterals, for instance, are both subtypes of polygons. In addition, a type may have more than one supertype. For example, an isosceles right triangle may be regarded either as an isosceles triangle or as a right triangle. This multiple-supertypes issue is particularly thorny, since it means that there is no unique way to `raise'' a type in the hierarchy. Finding the `correct'' supertype in which to apply an operation to an object may involve considerable searching through the entire type network on the part of a procedure such as apply-generic. Since there generally are multiple subtypes for a type, there is a similar problem in coercing a value ``down'' the type hierarchy. Dealing with large numbers of interrelated types while still preserving modularity in the design of large systems is very difficult, and is an area of much current research.

ПЕРЕВОД ИЗ Русскоязычного издания Если типы данных в нашей системе естественным образом выстраиваются вбашню, это сильно упрощает задачу работы с обобщенными операциями над различными типами, как мы только что видели. К сожалению, обычно это не так. На рисунке 2.26 показано более сложное устройство набора типов, а именно отношения между различными типами геометрических фигур. Мы видим, что в общем случае у типа может быть более одного подтипа. Например, и треугольники, и четырехугольники являются разновидностями многоугольников. В дополнение к этому, у типа может быть более одного надтипа. Например, равнобедренный прямоугольный треугольник можно рассматривать и как равнобедренный, и как прямоугольный. Вопрос с множественными надтипами особенно болезнен, поскольку из-за него теряется единый способ «поднять» тип по иерархии. Нахождение «правильного» надтипа, в котором требуется применить операцию к объекту, может потребовать долгого поиска по всей сети типов внутри процедуры вроде apply-generic. Поскольку в общем случае у типа несколько подтипов, существует подобная проблема и в сдвиге значения «вниз» по иерархии. Работа с большим количеством связанных типов без потери модульности при разработке больших систем – задача очень трудная, и в этой области сейчас ведется много исследований

хотя книжка старая.. но вот кажется что: А воз и ныне там

лучше обмазывайтесь кложей

а кложа на бекенде жива?

я имею в виду, что я заглянул в гитхаб репу и там как-то мёртвенько

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

Я развею

1. Пол рассказывает не о принципиальных проблемах scala, а об ошибках в дизайне стандартной библиотеки. Для большинства вещей и так есть альтернативы, остальное давно переписывается.

Таких видео от скалистов есть много, с даже более глубокой критикой типа https://www.youtube.com/shared?ci=0eIxalwSQ6k

я имею в виду, что я заглянул в гитхаб репу и там как-то мёртвенько

в какую?

https://github.com/clojure/clojure/commits/master

ну и вообще эта полузакрытая модель разработки в интересах одной компании, не есть хорошо

2. Приведённая система типов несложно моделируется и trait ами в scala и bounded полиморфизмом в haskell

3. Не вижу проблем задрачивать и Haskell, и scala, и clojure, и Racket и Idris и можно без хлеба

4. Все мажорные версии скалы типа 2.10, 2.11, 2.12, 2.13 бинарно несовместимы. Что такое "первая версия" скалы никто не знает

https://github.com/clojure/clojure/commits/master

бывает же, что софт просто работает и не нуждается в том, чтобы его постоянно чинили? и бывает же, что проект не страдает feature creep, что вообще-то совершенно нормально?

5. онтология, таки, развеет

бывает же, что софт просто работает и не нуждается в том, чтобы его постоянно чинили? и бывает же, что проект не страдает feature creep, что вообще-то совершенно нормально?

как по мне, это не совсем применимо к ЯП. Если ЯП не развивается, то рано или поздно он протухает. А это не та вещь, которую можно легко сменить.

как по мне, это не совсем применимо к ЯП. Если ЯП не развивается, то рано или поздно он протухает. А это не та вещь, которую можно легко сменить.

может развиваться не сама кложа, а её экосистема. ну честно, что там в самом языке не так?

А я не говорил, что что-то не так :) Я просто спросил есть там какая-то жизнь сейчас или нет. Пару лет назад я следил, а сейчас забросил

)))

Не так там то, что они внутри что-то там пилят-вертят, а потом ставят комьюнити перед фактом. Помню недавно бурлило на эту тему у кого-то. Сейчас поищу.

https://danielcompton.net/2017/03/31/clojure-nil-predicates

а кложа на бекенде жива?

я бы сказал что на фронте что на бэкэнде, привосхитительно прям - и доставляет то что и там и там один язык и почти полная совместимость типов

можно даже писать либы которые одновременно будут и для фронта и для бэка компилиться

и все на одном языке

может развиваться не сама кложа, а её экосистема. ну честно, что там в самом языке не так?

кложа отлично развивается... в новой версии все ждем spec.

https://clojure.org/about/spec

это core.typed сделанный "правильно"?

нет. это больше к датацентричности

как бы так

и валидации

если вы про spec

если это nixos, то запуская сначала nix-shell, а потом emacs, открывая в нём .hs файл, ghc говорит что зависимости не установлены, то есть она не видит shell.nix для данной директории

в никсосе вообще девелопит кто-нибудь?

я пытался, но после этих бесконечных манипуляций с nix-shell устал и забил

+1

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

в смысле устал еще на старте

концепция там конечно красивая

конь-цепции в нем вроде правильные. но блин надо же так сделать всё

но (((опередила своё время)))

мы к этому ещё не готовы

да могли бы менее угребищный кли сделать

и может быть всползло бы

они же вроде и не на хаскеле уже всё пишут

кли там ужасен

уж лучше докерные контейнеры, чем ЭТО

на хаскеле был бы optparse-applicative и было бы норм

докерные контейнеры плохи только сетью

остальное там вполне ок