если не знаешь - нельзя

ясно

в json можно всегда

т.е. ты можешь писать "<tag1>" *> blah <* "</tag1>" <|> ...

но написать someTag >>= \tag не можешь

в json "все теги известны" =)

максимально неграмотная фраза, но идея надеюсь понятна

т.е если бы в xml были только теги object,key, array, value, int, float

да, теперь понятно

это было бы просто суперскучно

бесплатный!

мобильных... хаскель... всё правильно, Карина. получи бан во всех чатах, куда ты это написала.

когда же они наконец поймут как правильно рекламироваться в телеграмных чатах?

Зря замочил?

А разве хаскель не умеют в JVM ?

Нет

Я же находил какие-то попытки. Сейчас кину ссыль.

я помню 2 попытки: https://github.com/typelead/eta и https://github.com/Frege/frege

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

http://foswiki.cs.uu.nl/foswiki/Ehc/UhcUserDocumentation#A_6.6.2_61jazy_61:_Core_based_Java_44_no_whole_program_analysis

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 бинарно несовместимы. Что такое "первая версия" скалы никто не знает